system: OPERATIONAL
← back to all hacks
AGENTS MEDIUM NEW

Runtime governance for AI agents: the five-plane reference architecture

A June 2026 paper argues agent risk now lives inside the workflow, not at the data boundary, and proposes a five-plane architecture: adjudicate intent once, enforce it across four planes.

2026-07-05 // 7 min affects: ai-agents, mcp-connectors, enterprise-agent-platforms, tool-using-llms

What is this?

On June 10, 2026, a paper titled A Five-Plane Reference Architecture for Runtime Governance of Production AI Agents (arXiv:2606.12320) laid out a design for controlling what an agent does, not what it says. Its starting observation is that enterprise security was built to govern data boundaries: access control, DLP and perimeter inspection all watch data crossing a line. A production agent dissolves that assumption. It reads context, calls tools, invokes connectors and modifies systems of record on the business’s behalf, so risk moves inside the workflow, into sequences of individually-permitted actions that can transform a business process nobody authorized.

The paper is squarely a systems-security contribution, and it is explicit about scope: it governs delegated action, not model behaviour. Hallucination, alignment and text-level jailbreaks are out of frame. It fits the dominant theme of mid-2026 agent security, echoed in the July 2026 Adversa roundup: treat agents as insider threats and put cryptographically verifiable, runtime-enforced guardrails around their authority.

How it works

The architecture is built from four composable primitives.

The first is the five-plane decomposition. One reasoning plane is the only layer with full visibility into the decision context and the only one allowed to issue a verdict; it evaluates the acting principal, the current plan, session state and decision history, then emits a decision projection. Four enforcement planes realize that single decision in parallel: network (which endpoints may talk, under what crypto posture and rate), identity (who is acting and under what scope, via short-lived credentials that reflect the attenuated authority), endpoint (the runtime posture in which the action executes), and data (which records the action may touch — turned from a post-hoc filter into a pre-retrieval gate). Policy is composed once and enforced everywhere, rather than federated across disagreeing engines.

The second primitive is stop-anywhere mediation. The governor is present at seven points along the agent loop — plan formation, context retrieval, tool selection, argument generation, action commit, output return and audit emission. Its output vocabulary is six interruption primitives that generalize allow/deny: Pause, Escalate, Narrow, Modify, Defer, Rollback. Plain allow and deny become the two degenerate cases.

The third is composite principals with capability attenuation: the principal is a delegation chain, not a record. Effective authority is the intersection of capability sets along the chain, restricted to unexpired capabilities and cryptographically bound to it. Every delegation hop can only remove authority, and time-to-live is first class.

The fourth is audit as a structured evidence substrate — every decision produces a tamper-evident, reconstructable record, distinct from logging-as-audit, feeding existing SIEM/OpenTelemetry pipelines.

Why it matters

The paper’s sharpest point is why today’s policy engines do not stretch to agents: they are request-gated rather than plan-aware, assume atomic principals rather than delegation chains, express absolute rather than attenuated authority, are stateless, and return a Boolean. Agentic workflows break all five assumptions at once.

Against that backdrop the authors enumerate seven production-agent threats the architecture is meant to foreclose, including indirect prompt injection arriving through tool outputs, the read-then-exfiltrate tool-chain abuse familiar from the “lethal trifecta”, connector overreach from coarse-grained OAuth or MCP scopes, approval evasion, delegation-chain exploitation, audit opacity and workflow-integrity loss. Each maps to specific mediation points and primitives rather than a generic “add a guardrail.”

Defenses

The paper is itself a defensive blueprint; the practical takeaways generalize even if you never adopt the full stack.

  • Move the decision to intent, and enforce it in the boring places. Adjudicate a plan once against full context, then let network, identity, endpoint and data controls you already run realize that verdict. You likely own four of the five planes already.
  • Make data a pre-retrieval gate, not a post-hoc filter. Constrain the candidate set an agent can retrieve before retrieval, so untrusted content never enters context in the first place.
  • Model the principal as an attenuating chain. Issue short-lived, scoped credentials per delegation hop; authority should only ever shrink, and expire on a timer. Coarse connector scopes are where overreach hides.
  • Give yourself more verbs than allow/deny. Narrow, Modify, Defer and Rollback preserve utility where a hard block would break the task and a hard allow would be unsafe.
  • Treat audit as evidence, not logs. A tamper-evident, reconstructable decision record is what lets you answer “who authorized this action, and under what attenuated authority?” after the fact.

Status

ItemValue
SourcearXiv:2606.12320v1, posted June 10, 2026
TypeReference architecture (defensive), single author
ScopeGoverns delegated action; excludes model behaviour, hardware attestation, side-channels, DoS
ProvenReference policy-engine core: attenuation correctness and evidence reconstructability held on every trial; adjudication in single-digit microseconds; tamper-evidence as designed
Not provenInvariants argued structurally, not formally; no full-system evaluation against a live agent benchmark yet
Benchmark anchorAgentDojo adopted as the attack corpus for the proposed evaluation framework

Key date: June 10, 2026 — paper posted to arXiv. The authors frame full-system evaluation against a live agent benchmark as the invited next step, so treat the microsecond-latency and correctness numbers as validation of the architecture’s internal claims rather than an end-to-end production result.

Sources