Most AI governance programs I've come across assume a person is still in the loop between the model's answer and what happens next. Agents now call tools directly, read from internal systems, write to them, and hand work to other agents without a person in between. The standard way they do this is MCP (Model Context Protocol), and MCP is where governance either happens or quietly stops.
If you sell an AI product into a bank, an insurer, or a health system, the risk team will ask a fixed set of questions about your agent: who it is, what it is allowed to do, what happens when its tools change, what happens when it hands work to another agent, where the human sits, whether they can reconstruct what it did, and whether you can prove the controls still work after go-live. What I see separate the vendors who get through that review from the ones who stall is where their answers live. The ones that get through have an answer for each question sitting in the request path, where the examiner can watch it fire. Here is what each question means at the MCP layer, and how a proxy between the agent and its tools answers it.
01 · Identity
Who is the agent?
An MCP tool call carries no identity by default. The model asks, the server answers. Ask most agent stacks who read a customer record and the log says a service account did. A proxy has to attach an identity to every call: which agent, running which workflow, acting for which user. Without that, your logs show that "something" read the record, and an examiner will not accept "something" as an answer.
02 · Authority
What authority was delegated?
Reading, recommending, and executing are different acts and need different limits. A claims agent that can read a policy file is a different risk from one that can approve a payout, and the risk team will want the line between the two enforced somewhere they can inspect. At the MCP layer that means a per-agent tool grant: this agent may call these tools with these parameters, and nothing else. The proxy checks the grant on every request, long after the initial approval, and a tool outside the grant never reaches the server.
03 · Drift
What happens when the tools change?
An MCP server can change a tool's schema or description at any time, and the model will follow the new description without anyone noticing. The tool your security review approved in March may describe itself differently in June. The proxy notices when what the agent is offered no longer matches what was approved, and a changed tool waits for a person before the agent can use it. The same check covers the system prompt.
04 · Delegation
What about agent-to-agent delegation?
When agent A hands work to agent B, that hand-off is itself a call through the proxy. Agent B's calls carry the identity chain that started with agent A, and agent B can do no more than agent A could. Authority narrows as work moves downstream. A call that shows up with no chain is a hop that skipped the proxy, which is a deployment defect the audit record makes visible.
05 · Human in the loop
What does human in the loop mean?
"Human in the loop" means three different things depending on who says it: approving before execution, reviewing exceptions, or auditing afterwards. Each is a different control with a different evidence trail, and the risk team will ask which one you mean. Pick one per class of tool and enforce it. For high-consequence tools, the proxy holds the call until a named person approves. For everything else, the record has to be complete enough that review after the fact covers every call, not a sample.
06 · Reconstruct
Can you reconstruct what happened?
Two ways to get there. Your engineering team can build logging on every tool call, a check in front of every tool, a store nobody can edit after the fact, and a retention policy, then rebuild the lot each time the scope changes. Or a proxy that already sits on every call writes each event as it happens (request, tool, parameters, data returned, outcome) into a tamper-evident, hash-chained store with a retention floor. The second one holds up a year later without a team maintaining it.
07 · Prove
Can you prove the controls still work?
This is where documentation-based programs fail. SR 26-2 leaves generative and agentic AI out of scope, but the examiner will still ask. The EU AI Act has been enforceable for general-purpose models since August 2, and NIST is revising the AI Risk Management Framework with agents and traceability in view. None of them builds the mechanism that proves a control fired. A runtime proxy does, because the proof is a byproduct of enforcement: every allowed call and every blocked one is already in the chain, and the examination package is assembled from that chain, mapped to the controls the firm is examined against.
What actually matters, call by call, is whether it was permitted, whether it was checked, and whether you can produce the record for it. That record, pulled from the proxy that enforced the rule, is the answer a bank's risk team is looking for. Everything else is a policy binder they have already read.