Gateway. Guardrails.
Deterministic enforcement.
One platform.
Runtime AI governance infrastructure to trust and control AI usage across the enterprise
Orchestrate IT, Security, Cost, and Compliance guardrails
Map and enforce action surface; route and attribute every model and MCP call
Enriched context-graph trace and record of every agent action
Evaluate scope and authorize every agent action before it executes
What is an agent control plane?
An agent control plane is the governance layer between your AI agents and the systems they act on. For every action an agent attempts it makes a deterministic decision, in the path of the action and before it executes, on whether that action is allowed: which identity the agent runs as, which data it may touch, and whether a person must approve it first.
What does a neutral control plane mean in plain English?
Neutral means it is not tied to one model vendor, agent framework, or MCP server. Policy is written once and enforced the same way whether the agent runs on OpenAI, Anthropic, Bedrock, or something built in house. Without that, every agent platform gets its own incompatible rules, and nobody can answer what your agents are collectively allowed to do.
How does an agent control plane actually work?
In three layers. At design time the agent's action surface is mapped and classified, so you know what it could do before it ships. At runtime every action is authorized against that scope before it executes, with the agent's identity and the requesting human both attached. Every decision, allowed or denied, is recorded as evidence rather than as a log line.
Why does enforcement have to happen at runtime?
Because an agent decides what to do while it is running, not when it ships. The action it takes depends on the prompt it was given, the data it just read, and what the model made of both, none of which exist at review time. Design-time analysis tells you what an agent could do; only a runtime check can rule on what it is about to do. It is also why detection is not a substitute: a log saying an agent deleted a production record is evidence, not a control.
Why does the decision have to be deterministic?
Because an authorization decision has to be reproducible and explainable, and a probabilistic one is neither. If the thing deciding whether an agent may move money is itself a model, you have added a second system that can be wrong in unpredictable ways to govern the first. Segregation of Duties is a rule, not a pattern: whether the agent that raised a purchase order is now approving it is a fact you evaluate, not a likelihood you score. The same action against the same policy must produce the same answer today and in a March audit.
Why does governance sit outside the agent's execution loop?
Because an agent that is behaving unpredictably cannot be the thing that decides whether its own behaviour is acceptable. Forrester makes this the defining property of the category: oversight has to remain possible precisely when the agent is doing something you did not expect. Controls that live inside the agent fail in the case they exist for.
Is a control plane the same as an AI gateway or an AI firewall?
No. A gateway governs the request path: routing, keys, rate limits, and which model answers. A firewall inspects content for prompts and data it considers unsafe. A control plane governs the decision to permit the action at all, which is a different question and the one an auditor asks. Most enterprises end up running a gateway and a control plane together.
For the analyst framing behind the category, including Gartner's AI TRiSM and Forrester's Agent Control Plane market, read the full explainer.
Category comparison
Control plane, gateway, or guardrail?
The three are often described interchangeably and govern different things at different moments. Most enterprises end up running all three; only one of them answers the question an auditor asks.
| AI gateway | AI firewall / guardrail | Agent control plane | |
|---|---|---|---|
| What it governs | The request path: routing, keys, quotas, and which model answers. | The content: prompts and responses screened for injection, toxicity, or leaked data. | The action: whether the agent may do the thing it has just decided to do. |
| When it acts | Before the model is called. | Around the model call, on the way in and on the way out. | After the agent reasons, before the tool call executes. |
| How it decides | Configuration: routing and rate-limit rules. | A classifier score against a confidence threshold — probabilistic. | Policy evaluated against the agent's mapped scope — deterministic. |
| What it produces | Traffic, latency, and cost telemetry. | Content flagged, redacted, or refused, with a confidence score. | An authorization decision — allow, block, or escalate — recorded as evidence. |
| Example tools | LiteLLM, Portkey, Kong AI Gateway | NVIDIA NeMo Guardrails, Llama Guard, Lakera | LangGuard |
| Answers “who authorized this action?” | No — it can show the call was routed. | No — it can show the content was screened. | Yes — which agent, acting for whom, against which policy, and who approved it. |
A gateway and a guardrail leave the same gap: they can show that a call happened and that its content looked acceptable, but neither ruled on whether the agent was permitted to take the action. LangGuard ships gateway and pre-reasoning guardrail layers of its own — see Why one platform, not three point solutions below — but the control-plane column is the one nothing else in the stack covers. For the guardrail category on its own terms, see AI guardrails.
How It Works
Every agent action moves through three layers before it ever acts on your enterprise systems: a single control plane connecting AI agents to the systems they touch.
Full lifecycle governance
From design to production
Governance that exists only at runtime cannot tell you what an agent was ever allowed to do. Governance that exists only at design time cannot stop it. LangGuard covers both ends in three stages, on one policy model and one evidence trail.
Design time
Map — SCOPE
Before an agent ships, SCOPE-MCP enumerates its complete action surface: every tool connected, every operation exposed, every system of record reachable. Each operation is classified against Segregation of Duties rules and regulatory regimes. The agent's authorized scope becomes a written artifact before its first call, not an assumption.
Runtime
Enforce — Arbiter
In production, Arbiter evaluates every action against that scope after the agent reasons and before the tool call executes. Safe actions clear with no added latency. Actions that cross an SoD boundary or a policy threshold are blocked, or held and routed to a named approver. The decision is deterministic: the same action against the same policy returns the same result every time.
Continuous
Record — GRAIL
Governance AI Runtime Links (GRAIL) records every one of those decisions as a linked context graph rather than a flat log line, tying each action back to the agent, the person it was acting for, and the policy it was judged against. Evidence is a by-product of enforcement, so there is nothing to reconstruct at audit time.
What a GRAIL record contains
- Which agent attempted the action, and which person or workflow it was acting for.
- The action itself: the tool, the operation, the parameters, and the system of record it targeted.
- The policy that was evaluated, and the mapped scope it was evaluated against.
- The decision returned — allow, block, or escalate — and the moment it was made.
- The named approver, their decision and their timestamp, wherever an action was escalated.
- The upstream path: which model, gateway, and agent harness the action moved through.
Those six facts are what an auditor is asking for when they ask who authorized an action. Because the record is written at the moment of the decision rather than assembled from logs afterwards, it holds up as evidence rather than as a reconstruction.
More depth: the AI governance lifecycle and provable, transparent authorization.
Why one platform, not three point solutions
Point solutions cover one layer of the agent lifecycle. LangGuard covers all three, on shared policy and a shared audit trail.
| Layer | What it governs | LangGuard |
|---|---|---|
| MCP & Agent Gateways | Routes and authenticates every model and MCP call; meters cost | Built-in |
| Guardrails pre-reasoning | Screens intent before the agent reasons; maps to security, compliance, and operational risks | SCOPE-MCP |
| Deterministic enforcement post-reasoning | Evaluates the planned action itself and allows, escalates, or blocks it before it executes | Arbiter |
Already running a gateway? Arbiter works alongside what you have. Deterministic enforcement is the layer worth adding regardless of what sits underneath it. See how Arbiter works →
Four Pillars of AI Governance
The foundational capabilities every enterprise needs to govern AI agents at scale
Accountability
"What are the approved AI assets in use?"
Gain visibility into AI assets that previously have no system of record
Traceability
"How is the approved AI agent behaving in use?"
Provision and approve AI assets, not just code or infrastructure
Auditability
"Is the AI agent behaving as intended?"
Provide immutable evidence of AI agent decisions and behaviors
Enforcement
"Is the AI agent action authorized?"
The only layer that stops an unsafe action before it happens, not after
Forward-Deployed Engineering
Don’t just buy the platform. Ship a governed agent.
LangGuard embeds forward-deployed engineers with your team to move a priority agent into trusted production: fixed scope, tied to production milestones, in four to six weeks. Compliance-ready for SOC 2, PCI, HIPAA, ISO, and more from day one. You keep the agents, policies, and implementation.
Foundation
Weeks 1–2
Scope locked around one priority agent or workflow. The runtime governance harness is deployed across your gateways, tools, models, and runtimes.
Policies & Integrations
Weeks 3–4
Identities, trusted paths, and human authority controls wired in. Policies authored for what Arbiter should allow, escalate, or block.
Production Cutover
Weeks 5–6
Monitoring, audit, and containment live. Runbooks handed off. The agent runs governed in production, on a foundation your next agent reuses.
Integrates with your stack
LangGuard sits above your existing infrastructure, not inside it. It integrates with the tools you already use for routing and identity, and governs the actions your agents take on top of them.
Recognized need by Industry Analysts
Leading analysts recognize the AI Control Plane as critical enterprise infrastructure
Forrester
An agent control plane is an enterprise control plane that inventories, governs, orchestrates, and assures heterogeneous AI agents across vendors and domains.
Gartner
As enterprises move to AI agents that take action, the control plane serves as the "missing" infrastructure for ensuring observability.
Opus Research
AI agent control plane as the shared brain and rulebook that sits above experience and applications.
Gartner AI TRiSM
AI TRiSM — AI Trust, Risk and Security Management — is Gartner’s framework for the controls an enterprise needs around AI systems it has put into production, covering governance, runtime enforcement, and information governance rather than model quality alone. Gartner estimates that through 2026 roughly 80% of unauthorized AI transactions will come from internal policy violations — oversharing, or an agent acting outside what it was meant to do — rather than external attack, and that organizations operationalizing TRiSM will see a 50% improvement in AI adoption and business goal attainment. LangGuard sits in the runtime enforcement part of that framework: it is the layer that decides whether an agent’s action is within policy, blocks it or routes it to a named approver when it is not, and records the decision. Internal policy violation is precisely the failure mode a deterministic authorization check catches and a detection tool reports after the fact.
Forrester Agent Control Plane
Forrester has formalized the Agent Control Plane as a market category: an enterprise control plane that inventories, governs, orchestrates, and assures heterogeneous AI agents across vendors and domains. Its defining property, in analyst Leslie Joseph’s framing, is that oversight lives outside the agent’s execution loop, so monitoring and intervention remain possible even when an agent behaves unpredictably. LangGuard is built to that shape. SCOPE-MCP provides the inventory and classification, Arbiter provides the assurance as a decision in the path of each action, and GRAIL provides the record — none of which depend on the agent, its framework, or its model vendor cooperating. A control that lives inside the agent fails in exactly the case it exists for.
Capabilities
How LangGuard works, in detail
What is MCP Authorization and how does LangGuard handle it?
The Model Context Protocol standardizes how an agent connects to a tool server. It settles authentication — which agent may connect to which server, with which credential — but not authorization of the individual call, which is where the risk actually sits. LangGuard treats every MCP tool call as an authorization decision. SCOPE-MCP classifies the operations a server exposes before an agent is permitted to reach it, and Arbiter evaluates the specific call at runtime: this tool, this operation, these parameters, this agent, acting for this person. It returns allow, block, or escalate before the call reaches the server. Connection-level trust is not sufficient on its own, because an agent legitimately connected to a finance server must still be prevented from approving the invoice it raised.
How does LangGuard enforce least-privilege agent permissions?
In two places, because for an agent one is not enough. At design time SCOPE-MCP maps the agent's complete action surface and classifies each operation, which turns least privilege from an intention into a written scope. At runtime Arbiter enforces that scope on every call: an operation outside it is not a violation to review later, it is a call that does not execute. The distinction from user least privilege matters. A person holds the permissions their role was granted; an agent inherits the entire reach of every tool it is connected to, whether or not its task needs it, so the boundary has to be drawn per operation rather than per system. An agent authorized to read invoices cannot approve them, even though both operations live behind the same connection.
What does provable authorization mean, and what evidence does LangGuard produce?
Provable means you can demonstrate afterwards that a specific action was permitted by a specific rule, not that it looked normal at the time. That requires two things: the decision has to be deterministic, so it can be reproduced, and it has to be recorded at the moment it was made rather than inferred from logs later. Probabilistic detection satisfies neither, because a confidence score is not a rule and cannot be re-run to the same answer. LangGuard records each decision through GRAIL: the agent, the person it acted for, the tool and operation attempted, the policy evaluated, the allow, block or escalate returned, the named approver where one was involved, and the timestamps for each. Replay the same action against the same policy and you get the same decision.
How does LangGuard support full lifecycle governance from design to production?
Three stages on one policy model: map, enforce, record. SCOPE-MCP maps and classifies an agent's action surface at design time, so the scope exists as an artifact before the agent ships. Arbiter enforces that scope at runtime, evaluating every action after the agent reasons and before the tool call executes. GRAIL records each decision as evidence as it is made. The stages share one policy definition, which is what makes the lifecycle coherent: the scope an agent is reviewed against before deployment is the same scope it is held to in production and the same scope cited in the audit record. Design-time review alone tells you what an agent could do; runtime enforcement alone cannot tell you what it was ever supposed to do.
What AI guardrails does LangGuard provide?
Guardrails at two points in the agent's loop, plus cost. Before the agent reasons, SCOPE-MCP screens the surface it is permitted to reach and flags operations that carry security, compliance, or Segregation of Duties risk. After it reasons and before the tool call executes, Arbiter evaluates the planned action itself and returns allow, block, or escalate. Alongside both, per-workflow token budgets are enforced in real time so a runaway workflow is stopped rather than invoiced. The difference from conventional guardrails is where the decision is made and how: content guardrails score prompts and responses probabilistically, while LangGuard's enforcement guardrail evaluates the action against a rule and returns the same answer every time. Most enterprises run both.
Each of these has a fuller explainer: MCP authorization, least privilege, provable authorization, lifecycle governance, and AI guardrails.