aigwdocs

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.

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.

A request is decided by a person signed in to the console, never with a management token, and never by the person whose key or sign-in made the call. A request that expired before anyone decided it can no longer be approved; the caller’s retry raises a fresh one. Every decision is recorded in the audit log.

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”.

The same results and responses are also checked for prompt injection. This is the direction that matters for an agent: the instruction rarely arrives in what the operator typed, it arrives in the ticket the tool read or in what a delegated agent sent back. Matches are flagged and never block, because detection is pattern matching and refusing a result on a heuristic breaks working agents. What bounds an attempt that gets through is the tool scope on the key, the calls that require approval, and the exfil scan on the way out.

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.

How the gateway authenticates to a tool

Each MCP server or A2A agent carries its own outbound credential, held by aigw and injected per call: a bearer token, an API key in a named header, basic auth, OAuth2 client credentials, or a client certificate for mTLS. Secrets are sealed at rest and never returned to the console once saved.

Two of these are worth calling out because they answer questions a security review will ask.

On behalf of the caller. With the other types, every call from your workspace arrives at the tool wearing the same credential, so the tool’s own audit log says “the gateway did it” and nothing more. Choose On behalf of the caller and aigw exchanges the caller’s own IdP token for one scoped to that single destination, so the tool logs the actual person. The tool never receives the caller’s original token: a compromised or simply curious tool server gets something that opens one door for a few minutes.

Both spellings of the exchange are supported, the standard one (RFC 8693) and Microsoft Entra’s. This needs callers to sign in through your IdP; a request authenticated with a virtual key carries no user assertion to exchange, and is refused rather than quietly falling back to the shared credential.

Proof that a call came through the gateway. An MCP server is an HTTP endpoint, so everything above it (tool scope, argument rules, approvals) is bypassed by anyone who can reach it directly. Tick Prove calls came through the gateway and every outbound call carries a short-lived signed assertion naming the workspace, the caller, the target and the tool. Your server verifies it against the key published at /.well-known/jwks.json and rejects anything without one. No shared secret, nothing for you to rotate, and it works where a network egress lock cannot, such as a tool hosted by somebody else.

The assertion is independent of the credential, so a server can require both: one answers “may this workspace use you”, the other “was this actually governed”.

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.

Two limits follow from that, and they are worth knowing before you plan around them rather than during a pilot.

Local MCP servers are not covered. aigw governs MCP servers reachable over HTTP. A server that runs as a local process on a developer’s machine and talks to their editor over stdio never crosses the network, so nothing is denied, approved or audited, and it does not appear in the inventory. We govern the network path, not the machine. If local servers are part of your estate, tell us: the design for covering them cooperatively exists and is small, and knowing which servers you actually run is what decides whether it gets built.

Server Groups do not carry sessions. A Group aggregates tools/list and routes tools/call across its members. The server-to-client stream and session teardown are not federated, so a client that opens a session against a Group gets a 501. Address a single server for those.

A streamed response under an enforcing policy is buffered. With output scanning set to redact or block, a streamed tool result or delegation is read in full, scanned, and re-emitted as a stream. The caller gets the transport it asked for and the same result, but not token by token. That is the cost of inspecting something before it is delivered; flag mode streams live.