Runtime Governance Belongs at the Transport Layer
Oracle has just published two pieces (Runtime Budget Guardrails for Agentic AI and Runtime Governance for Enterprise Agentic AI) that together name a category most agent teams haven’t articulated yet: runtime governance. The framing is precise. Spend, in their telling, is “a runtime signal that must be governed during execution”. Not a metric audited after the fact. The governance question shifts from whether a model response was safe to whether the next specific action is authorised under current policy, identity, approval state, data boundaries, and budget.
Five pillars in their telling: an execution layer, an observability layer, a budget ledger, a policy layer that evaluates limits, and an interventions layer that fires deterministic remediations and records evidence (policy ID, version, trigger, observed values, decision, reason, outcome).
This is an accurate sketch of what every team running production agents will eventually need. The question Oracle’s posts leave open is where the layer runs.
The architectural assumption
Both posts tie governance to OCI’s execution surface: Oracle’s own runtime, Oracle’s own agents, Oracle’s own application stack. That’s coherent inside their world. Most agents in production don’t live there.
The agents teams ship today reach external systems through a single shared protocol. They authenticate to Stripe, GitHub, Postgres, Slack, AWS, and dozens of community-run MCP servers. Each server exposes its own tools, written in its own language, under its own auth model. None of them ships a governance layer the others recognise.
You can’t enforce policy inside systems you don’t control. You enforce it at the boundary.
The transport layer is the only neutral control point
Once you take that as the constraint, the framework collapses to a single architectural decision. Every tool call leaves the client, traverses the protocol, reaches the server. The only point that sits in front of every server, regardless of how it was built or who built it, is the protocol boundary itself.
That’s what PolicyLayer is. A hosted control plane that proxies MCP traffic. Every tool call is evaluated against deterministic policy before it forwards. Across every server you’ve registered, for every agent and every person you’ve issued access to.
The five pillars map naturally:
| Oracle’s framework | At the MCP boundary |
|---|---|
| Execution layer | Hosted MCP gateway proxy |
| Observability | Per-call event log, dashboard, denial reasons surfaced |
| Budget ledger | Stateful counters scoped to grant, policy, server, or global |
| Policy layer | Visual policy editor: per-tool conditions on any argument, multi-condition matching, hide tools entirely |
| Interventions | Allow, rate-limit, deny, hide, conditional. Versioned, hot-reloaded to running proxies |
Why “before it forwards” matters
Oracle’s framework insists on deterministic remediation. That insistence is correct. The model can reason around a prompt; it can’t reason around an action that physically doesn’t happen.
Pre-execution enforcement means the upstream call never leaves the proxy if policy denies it. Pre-execution evidence means the audit log is the decision log, not a reconstruction after the fact. This is the difference between governance and observation. Observability tells you what the agent did. Governance changes what it can do. PolicyLayer is the second.
What teams running production agents get
- One enforcement layer across every MCP server, hosted.
- Per-person access tokens, scoped, revocable without redeploying anything.
- Static API keys or managed OAuth handled at the gateway, never wired into clients.
- Visual policy editor with deterministic, stateful, conditional rules.
- A full audit trail of every tool call and the policy path that fired.
- Multi-client out of the box: Claude Code, Cursor, Windsurf, Codex, Gemini.
The category is real. The boundary matters.
Oracle’s framework is correct. Teams running production agents need runtime governance with the properties the posts describe: deterministic, evidence-backed, pre-execution. Most of those teams aren’t on OCI. They’re on Claude Code or Cursor, against Stripe and GitHub and Postgres and a stack of third-party servers nobody owns.
The transport layer is where governance has to run for them. That’s what we’ve built.
Control what your agents can do through MCP.
Get early access →. We’re rolling out invites in batches.
Browse the policy library →. Pre-classified tools across thousands of MCP servers.
Read the MCP security reference →. What the boundary looks like.