Risk classification
Every agent, team and function in FYAI carries a risk classification. The classification is what the policy engine reads when it decides whether a tool call needs approval, what the Control Library checks, and what the assurance pack reports. Integrations carry the same fields.
Risk levels
| Level | Meaning in practice |
|---|---|
| Critical | Always requires a person to approve each call, whatever an object's approval pin says — unless your risk appetite is Bypass all. |
| High | Requires approval under the default Balanced risk appetite. Tools at this level also won't run after untrusted content has entered the conversation. |
| Medium | Requires approval only under the Cautious appetite. |
| Low | Never requires approval through the appetite gate. |
| Informational | Never requires approval through the appetite gate. Built-in tools are proposed at this level. |
An object with no risk level is treated as requiring approval (unless the appetite is Bypass all). Leaving something unclassified never buys it a free pass. See Approvals and risk appetite.
How a level is proposed
When you create an agent, team or function, the platform fills in any classification fields you left empty with a proposal derived from what the object can do. A proposal is marked Proposed and has no review date. It stays that way until a person confirms it.
Functions
| Function type | Proposed level | Categories added |
|---|---|---|
| Local (Python) with code | Medium | code-execution |
| Local (Python) with no code | Low | — |
| MCP Stdio (Subprocess) | High | process-spawn |
| MCP HTTP (SSE) | Medium | network-egress, value-chain-opacity |
| Runner tool (runs on a customer-hosted runner) | High | code-execution |
| Skill (SKILL.md) | Low | — |
| Built-in tool | Informational | — |
| Reference to another agent | Medium | autonomous-delegation |
| Any type the platform doesn't recognise | Medium | value-chain-opacity |
A function's declared integration operations then raise it further:
- If any allowed operation name looks state-changing (contains words such as create, update, delete, send, merge, approve, deploy, execute, run, upload), the level is raised to at least High and
external-writeis added. - Otherwise, if it has any allowed integration operations, the level is raised to at least Medium and
data-leakageis added.
Agents
An agent's proposed level is the highest level among its tools (using each tool's own stored level where one has been set, otherwise its proposal), starting from Low. In addition:
- An agent bound to an execution environment is raised to at least High (
code-execution). - An agent with integration overrides gains
unbounded-capability. - An agent with memory enabled gains
data-leakage.
Teams
A team's proposed level is the highest level among its member agents, starting from Low. A team with more than one agent gains autonomous-delegation.
When capability changes
If you add a tool to an agent, or an agent to a team, and the new proposal is higher than the stored level, the platform raises the stored level automatically — but only while nobody has reviewed it. A reviewed classification is never overwritten. Instead, if the stored level falls below what the object's capabilities now derive to, it shows as Understated.
Review states
The badge next to a risk level shows where it stands:
| Badge | Meaning |
|---|---|
| Unrated | No risk level has been set. |
| Proposed | The level was derived from what this can do. Nobody has reviewed it. |
| Reviewed | A person reviewed this rating. |
| Understated | The stored level is below the level derived from what this can do. |
To move an object from Proposed to Reviewed, accept it in the Review Queue or use Mark as Reviewed on its Risk tab.
Risk categories
Categories describe why something is risky. They're free text, but the platform proposes values from a vocabulary based on the NIST AI 600-1 Generative AI Profile so they're comparable across projects: code-execution, process-spawn, network-egress, data-leakage, external-write, unbounded-capability, autonomous-delegation, confabulation, harmful-bias, prompt-injection, over-reliance, value-chain-opacity.
Some categories raise a tool's effective risk to at least High when approval is decided, whatever level is stored on it: process-spawn, network-egress, data-leakage, external-write and unbounded-capability. Older spellings such as external-network, data-exfiltration, data-deletion, filesystem-write, privilege-escalation, credential-access and financial-transaction have the same effect. Matching ignores case and treats underscores and spaces as hyphens. code-execution deliberately does not raise the floor.
The Risk tab
Agents, teams, functions and integrations each have a Risk tab under Build or Resources. You need the Editor role or above to save changes.
| Field | Values | Notes |
|---|---|---|
| Risk Level | None, Critical, High, Medium, Low, Informational | Drives approval decisions. |
| Data Classification | None, Restricted, Confidential, Internal, Public | Recorded and reported. It doesn't currently change any approval or routing decision. |
| Risk Owner | Free text, for example an email address | Counted in the assurance pack; checked by some controls. |
| Risk Categories | Comma-separated list | See the vocabulary above. |
| Compliance Tags | Comma-separated list, for example SOC2, GDPR | Free-form labels for your own frameworks. |
| Risk Notes | Free text | Automatic proposals write their rationale here, ending "Pending review." |
| Require justification before starting a session | Checkbox | Recorded and reported in the risk registry and assurance pack. The chat doesn't currently prompt for a justification. |
Buttons:
- Update saves the fields.
- Mark as Reviewed records that a person has reviewed the classification and moves it to Reviewed. The line under the form shows when it was last reviewed.
The approval behaviour of an agent, team or function is set separately, with the Approval Override field on its main settings. See Approvals and risk appetite.
The risk registry
The risk registry is the flat list of every agent, team and function in the project with its classification, the level its capabilities derive to, and whether it's understated. You see it through:
- the Review Queue, which shows the unreviewed part of it;
- the Risk Register section of the assurance pack;
- the API (
GET /risk-registryandGET /risk-registry/summary) and the platform MCP server's risk registry tools — see Governance API.
The Risk Registry page under Settings is only available to FYAI platform administrators.