Access rules for tools and agents
Decide who may call each MCP tool and A2A agent.
Access rules decide which callers may use which MCP tools and A2A agents. Owners and admins manage them in Governance › Policies › Access rules. Every caller is identified by its CoreValue key, never by a header it sends.
Access rules are available on plans that include them. See Billing, plans and credits.
A rule
Each rule has three parts:
- Effect: deny or allow.
- Who: a team, a member, an API key, an A2A agent (the keys it calls with), or anyone.
- What: one MCP tool, every tool on an MCP server, or an A2A agent. For one tool, give the tool's own name, as the server lists it.
For an A2A agent, its own Who may call it setting in Gateway › Agents is checked first; access rules apply to the callers it lets through.
Audit, then enforce
A new rule starts in audit. A call it would deny is still served, and is recorded as would-deny, naming the rule. The rule list shows, for each rule, how many calls it refused and how many it would have refused over the last seven days. When the record shows the rule does what you meant, switch it to enforce. Only an enforced deny refuses a call. You can switch a rule back to audit at any time.
The same holds for allow rules: an allow rule in audit grants nothing until it is enforced.
When rules disagree
A deny overrides an allow. Several rules can match one call; if any enforced rule denies it, the call is refused, whatever other rules allow it. The order the rules were written in never changes the outcome.
Default deny
With no rules, every caller in the organisation reaches every server, tool and agent it can see. Turn on default deny (audit) changes what happens to a call no rule matches: it is served, and recorded as would-deny unless an allow rule covers it. Enforce default deny then refuses those calls.
Default deny covers every MCP tool call and every A2A call, platform tools included. Before enforcing it, add allow rules for the callers who need access, enforce them, and check that the would-deny count has stopped growing.
A2A loop limit
The loop limit caps how many times one agent may call another within one task. Only message sends count, not polls. It also starts in audit, recording calls past the limit as would-deny, and refuses them only when enforced. An agent can set its own limit in Gateway › Agents, which applies instead of the organisation's. The limit counts only calls between agents that pass the task trace on.
What a refused caller sees
- MCP tool call. An enforced deny is answered as if the tool did not exist: JSON-RPC error
-32602 Unknown tool, so a client cannot tell a denied tool from an absent one. On a server's own endpoint, a batch that contains one denied tool call is refused whole. - Tool lists. On the unified endpoint,
/mcp, a tool an enforced rule denies is left out oftools/list. On a server's own endpoint,/mcp/<server-id>, the server'stools/listis passed through as it is, so a denied tool still appears there; calling it is refused. - A2A call. HTTP 403 with a JSON-RPC error whose
data.reasonisaccess_rule. The agent card is refused to that caller too. See Call an agent.
Every decision, refused or would-deny, is recorded on the call's row with the rule that made it, in tool-call activity and in agent traffic.
When changes apply
Changes to rules, the default and the loop limit reach the gateway within a minute.