The Academic Case for the AI Agent Control Plane

In 2025, two independent research groups set out to solve the same problem: how do you enforce governance on AI agents that make their own decisions at runtime?

One group, based in Finland, simulated external policy enforcement across multi-agent systems using open-source language models. The other, a security research team, designed a Kubernetes-native governance platform aligned to NIST AI RMF.

Neither group coordinated with the other. Both arrived at the same architectural pattern: runtime policy enforcement, sitting outside the agent, deployed as infrastructure.

When independent researchers reach the same conclusion from different starting points, it stops being a vendor opinion and starts being an engineering consensus. This article breaks down what both papers found, how the pattern maps to production systems, and what it means for teams governing agents today.

For Guild's working definition and operational model, see AI Agent Governance. For the full control plane category, see What Is an AI Agent Control Plane?.

Traditional access control assumes a human on the other end of every request: stable identity, predictable workflows, decisions made at human speed.

Agents break every one of those assumptions. Their identities are ephemeral — spun up in minutes, deprecated without an offboarding process. Their decisions emerge at runtime; the developer didn't write the specific API call the agent chose to make. And a misconfigured agent can execute hundreds of actions per minute, not hundreds per day.

The numbers reflect this. Astrix reports that 80% of companies running agents in production have already experienced unintended actions — unauthorized system access, data leaks, calls to systems no one authorized. Prefactor's research finds that 95% of AI agent projects never reach production at all, often because organizations can't answer the basic question: who is responsible when something goes wrong?

The question isn't whether agents need governance. It's what architecture governance should take. That's the question both papers answer — and they answer it the same way.

Gaurav, Heikkonen, and Chaudhary (2025) — *Governance-as-a-Service: A Multi-Agent Framework for AI System Compliance and Policy Enforcement* is a simulation study that tests whether external runtime enforcement actually works for multi-agent AI systems.

The researchers ran three multi-agent scenarios using open-source language models. An external governance layer sat between the agents and their target systems, evaluating every action against policy before allowing it through. The headline finding: external runtime enforcement "reliably blocks or redirects high-risk behaviors while preserving throughput."

Two mechanisms from the paper stand out.

Trust factor scoring. Each agent accumulates a compliance score based on its behavior history. Agents with high trust factors get lighter enforcement; agents with low trust factors get heavier scrutiny. This is per-agent reputation — proportional controls, not blanket policy applied uniformly to every agent regardless of track record.

Graduated enforcement. The paper proposes three intervention tiers: coercive (hard blocks on prohibited actions), normative (policy nudges that steer behavior), and adaptive (dynamic adjustment based on real-time context and trust level). The system escalates or de-escalates based on both the trust factor and the severity of the attempted action.

The practical implication: governance doesn't have to be binary — allow everything or block everything. A well-designed enforcement layer applies proportional controls based on what the agent is doing, how much it's been trusted to do it, and whether the specific action crosses a policy boundary.

Huang et al. (2025) — *AAGATE: A NIST AI RMF-Aligned Governance Platform for Agentic AI* takes a different approach — theoretical architecture rather than simulation — and arrives at the same conclusion.

AAGATE (Agentic AI Governance Assurance & Trust Engine) is described explicitly as a "Kubernetes-native control plane for agentic AI." The architecture integrates four layers:

• Zero-trust service mesh — every agent interaction is authenticated and authorized at the network level, not just at the application layer. No agent is trusted by default, regardless of where it runs.
• NIST AI RMF alignment — the platform maps directly to NIST's four functions (Govern, Map, Measure, Manage), making it auditable against the framework enterprises and regulators are already converging on.
• OWASP AIVSS integration — AI vulnerability scoring embedded in the governance layer, classifying risks by severity and attack surface.
• MAESTRO threat modeling — a structured threat analysis framework specific to multi-agent systems, addressing the combinatorial risk of agents invoking other agents.

The paper's contribution isn't a running system — it's that security researchers independently reached for the same architectural pattern that the GaaS simulation validated from the other direction. External enforcement. Infrastructure-layer deployment. Framework alignment. The conclusions are structurally identical.

Two countries. Different methodologies. Independent author groups. Three shared conclusions:

1. Governance must be external to the agent.

Neither paper suggests building governance into the agent's code. Both place enforcement in an infrastructure layer the agent has no choice but to flow through. The reasoning is structural: if the agent can choose whether to follow policy, it's a suggestion, not enforcement. This mirrors the pattern that worked for Kubernetes (control plane separated from data plane), API gateways (auth external to services), and service meshes (security at the proxy layer, not in application code).

2. Governance must align with established frameworks.

Huang et al. explicitly maps to NIST AI RMF. Gaurav et al. aligns with compliance and policy enforcement principles that predate AI agents. Neither paper invents a parallel governance vocabulary. That matters practically — the EU AI Act, Singapore FEAT, SOC2 auditors, and Forrester's emerging Agent Control Plane evaluation are all referencing NIST AI RMF as the operational vocabulary. A governance platform that doesn't speak NIST is going to spend the next five years translating.

3. Agents require their own identity model.

Both papers treat agents as non-human entities requiring per-agent identity, scoped permissions, and decision-level audit trails. Human IAM patterns — stable roles, predictable workflows, manager-approved access — don't transfer cleanly. Prefactor calls this Know Your Agent: every agent gets a unique ID, an explicit human owner, and an audit lineage. Without per-agent identity, there's no attribution, no scoping, and no revocation that doesn't break every other agent sharing the same credentials.

For engineering teams aligning to NIST AI RMF — which is most U.S. enterprises running agents in 2026 — here's the operational translation:

Govern — Policy boundary per agent. Define who owns the agent and what it can touch. In production, this looks like a workspace or container holding the agent's configuration, triggers, and credential policies. Without a defined boundary, there's nothing to enforce.

Map — Complete inventory of every agent, with risk classification by tool exposure and data sensitivity. Most enterprises discover significantly more agents in production than leadership realizes. Without inventory, governance is guesswork — you can't secure what you can't enumerate.

Measure — Continuous logging of every input, tool call, decision, and output. Sampled logs miss the runtime decisions that matter. Non-deterministic systems require complete audit trails because you cannot rerun the agent and expect the same output. The session log is the only ground truth.

Manage — Real-time revocation, kill switches that execute in seconds, scoped permissions that adjust to risk level. When something goes wrong at 3am, the response time is measured in seconds, not in deploy cycles.

These four functions also support compliance with Singapore FEAT (accountability requires identity + audit), the EU AI Act (high-risk obligations require risk management + human oversight + post-market monitoring), and OWASP AIVSS (security requires permission scoping + audit + revocation). One operational layer supports multiple frameworks because the frameworks converge on the same underlying capabilities.

Guild's control plane implements these four functions through Workspaces (Govern), agent registry (Map), Sessions (Measure), and Credentials + Triggers (Manage). For a deeper look at how agent permissions fit this model, see AI Agent Permissions.

Regardless of which tooling you use. Walk through these for any agent running in your environment:

1. Can you produce a complete inventory of every AI agent running in production, with named human owners? 2. Are credentials scoped per-agent, or are agents sharing long-lived API keys? 3. Can you reconstruct every tool call and decision for any agent action in the last 30 days? 4. If an agent goes off-script in production right now, how long does revoking its access take? 5. Do you have per-agent cost attribution — or is agent spend one opaque line item? 6. What happens to an agent's access when its owner leaves the company? 7. Can you map your current setup to NIST AI RMF and produce evidence for an auditor? 8. Is your governance layer tied to a single cloud or single model vendor?

If you can't answer six of these confidently, you have governance gaps. The academic research says those gaps widen, not close, as agent count scales — and Uber's CTO publicly confirmed that the company exhausted its 2026 AI coding budget by April. Ungoverned agents don't just create security risk. They create uncontrolled spend.