Agentic governance - tools & A2A

Model calls are only part of what an agent does. It also calls tools (over MCP) and delegates to other agents (A2A). aigw governs both the same way it governs model calls: point the agent at the gateway, and every tool call and delegation is checked against your policy and written to the audit log before it leaves your tenant.

Two registries in the console drive this: Tools (MCP servers) and Agents (A2A endpoints). Agents reach them at gateway.aigw.app/mcp/<name> and gateway.aigw.app/a2a/<name>.

Discovery

Register an MCP server (or an A2A agent) once. The gateway introspects it - tools/list for an MCP server, the well-known agent card for an A2A agent - and shows the actual tools and their argument schemas (or the agent’s advertised skills) in the console. You write rules against what is really there, not blind guesses.

Argument-level guardrails

The risk in a tool is rarely its name - it is the arguments. fetch_url is fine; fetch_url to your internal admin host is not. So rules govern what a call is made with, not just whether the tool exists.

A rule is ordered allow/deny over tool (or agent) name globs, optionally scoped to caller tags, plus optional argument constraints: an argument path, an operator (matches / not_matches), and a glob. First match wins.

• Deny fetch_url where url matches *internal*
• Allow run_sql only where query matches SELECT*
• Deny delegation where the target matches *.internal

A matching call that violates a guardrail is blocked at the gateway and recorded (status blocked) so it shows in Logs.

Approvals - human in the loop

Set a rule’s effect to Require approval and a matching call pauses at the gateway while a human decides. Pending requests land in the Approvals queue (caller, tool/agent, arguments, expires-in) with Approve / Deny. The gateway holds the call briefly; if approved in time it proceeds, otherwise the caller retries once a reviewer approves. It is fail-closed (any failure denies), and a recent approval of the same call is reused so repeats and retries do not re-prompt.

Use it for the calls that warrant a second pair of eyes - send_email, delete, a payment tool, or delegation to an external agent.

Result and response scanning

A tool result or a sub-agent response can leak secrets or PII just as easily as a model response. The same DLP / exfil scanner you run on model output now also scans MCP tool results and A2A responses, applying your tenant’s mode (flag / redact / block). Findings surface in the Logs Security column as “tool result exfil” or “agent response exfil”.

Rate limits

Any tool or delegation rule can carry a rate limit - a count per window (per second, minute, or hour), scoped per caller. Over-limit calls are blocked and audited, so a runaway or abusive agent cannot hammer a tool or a downstream agent.

A2A parity

Everything above applies to agent-to-agent delegation as well as tool calls: agent-card discovery, task-level guardrails on the delegation parameters, Require-approval on delegation, response scanning, and rate limits. Delegation is governed as deeply as a tool call, and the whole chain (agent -> sub-agent -> tool / model) is visible on the Map.

What this depends on

aigw governs only what is routed through it. The moat is credential custody: your agents hold scoped aigw virtual keys, while aigw holds the real provider, tool, and agent secrets and injects them at request time. Pair that with an egress lock (the agent can only reach aigw) and destinations that trust only aigw, and there is no path around the gateway.