Approvals and risk appetite
Risk classification is only useful if something acts on it. In FYAI that's the policy engine: when an agent is built for a chat or a workflow run, the engine decides, for each tool the agent is given, one of three effects:
| Effect | What happens |
|---|---|
| Allowed | The tool runs when the agent calls it. |
| Approval required | Each call waits for a person to approve it. |
| Denied | The tool isn't given to the agent at all. |
This page explains how that decision is made and the settings that shape it. To see the decisions after the fact, use Policy.
How a decision is made
The engine works through the same chain for every tool, top to bottom. The first rule that applies decides.
1. Deny overrides
The tool is denied if any of these hold, checked in this order:
- Your organisation's gateway access is contained.
- A kill switch is active for the tool or its server.
- The calling agent identity isn't registered with the MCP gateway, or is quarantined or killed.
- The MCP server isn't one this project has registered, or the identity hasn't been granted the server or tool.
- The server changed the tools it advertises and nobody has acknowledged the change.
- The tool isn't on the execution environment's allowlist for this caller.
- The caller's role doesn't permit it.
- Your organisation's built-in tool policy disables the built-in.
- The agent isn't granted the sub-agent it's trying to call.
- Untrusted content has entered the context and this tool must not run after that.
Most of these are managed in the MCP Gateway, execution environments and built-in tools settings.
2. Approval pins
If the tool isn't denied, the engine looks for an explicit Approval Override pin. The first one set wins, in this order:
- the team's pin,
- the agent's pin,
- the function's own pin.
A pin of Always require (pin) means approval is required. A pin of Never require (pin) means the call is allowed — with one exception, the critical guard: if the combined risk of the agent and tool is Critical, approval is still required unless the effective risk appetite is Bypass all.
Some in-app tooltips describe function pins as taking priority over agent and team pins. The order above — team, then agent, then function — is the order the platform applies.
3. Unclassified tools
With no pin set, the engine needs a risk level. It uses the tool's own level (raised to High if it carries an escalating risk category — see Risk classification), or the agent's level when the tool has none. If neither has a level, approval is required — unless the appetite is Bypass all. Unclassified fails closed.
4. The risk appetite gate
Otherwise the risk level is compared with the effective risk appetite:
| Risk appetite | Label in the app | Approval required for |
|---|---|---|
bypass_all | Bypass all | Nothing, even Critical. |
critical_only | Critical only | Critical. |
balanced | Balanced (default) | High and Critical. |
cautious | Cautious | Medium, High and Critical. |
Untrusted context
Separately from approval, any tool whose combined risk (the higher of the agent's and the tool's level, including the escalating-category floor) is High or Critical is marked as not accepting untrusted content. Once content the platform labels untrusted has entered the conversation, those tools are refused.
Where risk appetite is set
The effective appetite for a run is resolved from the most specific setting that exists:
workflow override → your personal override → project override → organisation default → Balanced
(API only) (clamped, see below)
| Level | Where | Who |
|---|---|---|
| Organisation default | Set by FYAI platform administrators. Balanced unless changed. | FYAI platform administrators |
| Project override | Settings → Risk Appetite (under Project). The page is headed Project Settings; choose a tier in Risk appetite override, or Inherit organisation default. Clear override, inherit organisation default removes it. | Project Admin, or organisation Owner/Admin |
| Personal override | Settings → Account → Risk Appetite. Choose a tier, or Use project/organisation default. | Every user, for themselves, per project |
| Workflow override | API only: PUT /workflows/{workflow_id}/risk-appetite. | Project Admin |
Personal overrides are clamped
Your personal setting can always make approvals stricter. It can only make them looser than the project or organisation baseline if your organisation allows individuals to loosen it. If it doesn't, the app tells you "Your organisation does not allow individuals to loosen this beyond the project default", and if you pick a looser tier it's saved but capped — you'll see a message saying what your organisation caps it at. Your choice applies automatically if the cap is lifted later.
The project-level "allow loosening" setting is available through the API (allow_user_loosen on PUT /project-settings); the app's project page only sets the tier.
Workflow overrides are not clamped
A workflow override is an admin's deliberate decision about one automated pipeline. It takes precedence over the triggering user's own setting for the whole run, and isn't capped. Most workflow runs are unattended, so there's usually no user to defer to.
Setting an approval pin
The Approval Override field appears on agents, teams and functions:
| Option | Effect |
|---|---|
| Inherit from risk appetite | No pin. The risk appetite gate decides. This is the recommended default. |
| Always require (pin) | Every call needs approval, regardless of risk level. |
| Never require (pin) | Calls never need approval — except Critical risk, unless the appetite is Bypass all. |
A pin on a team applies to every tool its agents use while running as that team. Pins bypass the risk appetite completely, so the more pins you have, the less your appetite setting reaches.
Execution environments have their own list of tools that always require approval; that list is checked again when each call is made. See Execution environments.
What "approval required" looks like
- In chat, the run pauses and shows you an approval request for the call. Approving or rejecting it is recorded as an oversight record with your name, the time, the risk level at the time and a digest of the arguments (never the arguments themselves).
- In a run with nobody to ask (an autonomous or unattended run), the call is refused rather than approved on anyone's behalf.
- In workflows, approvals follow the workflow's approval gates. See Using approval gates.
If the machinery that asks a person isn't available, or the request times out, that's recorded with its own reason code and raises an alert under the default alert rules. See Reason codes and Alerts.
Related
- Risk classification
- Policy — the record of every decision
- Reason codes