Short answers to the questions that come up in every design review.
One authoritative policy system, yes. One physical pipe, no. Routing every model, agent, tool and data call through a single process creates a throughput bottleneck, an availability risk and a trust boundary that is hard to reason about, and some enforcement can only happen where the resource lives anyway. Keep the policy singular, distribute the enforcement points, and prove with conformance tests that they all evaluate the same bundle.
Partly. Identity, network, secrets, change management and logging all transfer. What does not transfer is the decision layer. Traditional controls check whether a call is permitted. Agent governance also has to check whether the call makes sense given the task the agent was given. That check is new and it belongs in the gateway.
Prompt instructions help the model behave. They do not stop it. Anything that must not happen belongs in code on the enforcement path, where an injected instruction cannot reach it. Treat prompt-level rules as steering and gateway rules as brakes.
Buy the model gateway, the tracing and the identity layer. Build the registry, the tier model, the policy set and the evals, because they encode decisions specific to your business. Most organizations get this backwards and build plumbing while outsourcing judgment.
Measure it rather than assume it. Deterministic policy evaluation against cached facts is usually small next to a multi-second model call; model-based output screening is the part that can dominate, because it is another inference. Set a latency SLO per workload from what that workload can actually tolerate, publish it so the platform team owns it, and watch p95 rather than the average. If the governed path is slow enough to be worth avoiding, teams will avoid it.
Only within an explicit scope with an owner. Shared memory across agents is the fastest route to poisoning and cross-tenant leakage, because a single bad write becomes every agent's trusted fact. Default to task-scoped memory and promote entries deliberately.
The registry is the allow-list and the gateway enforces it. Add automatic expiry, orphan detection when an owner leaves, and a quarterly portfolio review that retires agents which are not earning their keep. Sprawl is a lifecycle problem.
Not model interpretability. It means reconstructing the run: what the agent was asked, what it retrieved, what it decided at each step, which policy applied, and what it changed. If the trace answers those five questions months later, the agent is explainable enough for most regulators.
At the trust boundary between agents. One agent treats another's output as verified fact, and an error propagates with growing confidence. Sign inter-agent messages, propagate the original user scope, set confidence thresholds, and circuit-break on repeated handoffs.
Coverage is the criterion, not count. Every failure mode you have already seen in production, every one your threat model predicts, and enough volume in the classes that matter for the result to carry a usable confidence interval. Weight toward edge cases and adversarial inputs rather than the happy path, and weight by severity so a rare critical failure cannot be averaged away by common easy passes. A number someone else published is not evidence about your workload.
Usually no. Extend the boards you have. Architecture review covers design, change advisory covers release, risk committee covers tier promotion above R2. A separate board tends to become a queue, and queues are what teams route around.
If you are standing up an agent platform, tightening the controls on one you already have, or preparing for an audit that now includes agents, I am happy to look at it with you.
Tell me where you are with agents and what you are trying to make safe. I reply to every enquiry within two business days.
