Models & projects
Register the AI systems you are securing, group them into projects, and decide who works on what. Results attach to a model, so this is what makes findings land somewhere meaningful.
What a model is
A model is one AI system you are assessing. A chat assistant, a RAG pipeline, an agent. It is not the underlying foundation model: two products built on the same GPT-4o class model are two entries, because they carry different prompts, tools, and risk.
Registering one
- Open Models and choose New model.
- Name it the way your team refers to it. The name shows up in every finding and report.
- Record its environment, endpoint, and the project it belongs to.
- Set its criticality.
Criticality
Criticality is how much a problem here would actually matter. It weights the model in risk rollups and executive reporting, so a Medium finding on a critical system is not buried under a High finding on an internal prototype.
| Level | Typical of |
|---|---|
| Critical | Customer-facing, handles money, PII, or privileged actions. |
| High | Production, business-important, limited blast radius. |
| Medium | Internal production tooling. |
| Low | Prototypes and experiments with no real data. |
Org admins set criticality freely; security researchers can adjust it within limits. Executives see its effect throughout Risk and Compliance.
Set it honestly and early
Marking everything Critical is the same as marking nothing Critical. The ranking stops carrying information, and the first thing an executive summary loses is its ability to point anywhere.
Projects
A project groups related models. Usually a product, a team, or a business line. Projects are what developer scope is expressed in terms of, and what reports can be filtered to.
- Create and manage them under Projects. Admin only.
- A model belongs to one project.
- People are assigned to projects, and that is what determines what a developer sees.
Assigning who works on what
Developers only see the models and projects they are assigned. Their overview, scans, findings, and CLI activity are filtered the same way, so scope is set once and applies throughout.
Security researchers and org admins see the whole organisation; executives see it at summary level. Assign scope under Access.
How CLI runs attach
Scans upload against a model, which is how a terminal run becomes something the security team can see. Register the model before your first run and results land in the right place from the start.
Runs made with --no-upload stay local and never attach to anything. This is useful while experimenting because the runs are intentionally invisible to your organisation.
The model page
Opening a model gives you its full history in one place:
- Current posture and score trend.
- Open findings by severity.
- Scan history, with each run inspectable.
- Runtime events, where RUNTIME has been used.
- Reports generated for it.
Retiring a model
When a system is decommissioned, retire the model rather than deleting it. Its findings and reports stay available for audit, and it stops counting against your live posture.