OWASP’s 2026 Agent Control Standard: What Enterprises Need Beyond LLM Guardrails

Conceptual illustration of an AI agent moving from model-only safeguards to runtime identity, authorization, approval, and audit controls

OWASP’s September 2026 release of the 2026 Top 10 for LLM Applications and the new Agent Control Standard (ACS) confirms a change that enterprise teams can no longer ignore: AI security is moving beyond model behavior and into enforceable control over what agents are allowed to do.

LLM guardrails still matter. They do not answer every operational question. When an agent calls a tool, accesses a system of record, changes a business record, or triggers an approval, you need controls that identify the agent, evaluate the requested action, enforce policy before execution, and produce evidence afterward. That is the difference between content safety and runtime AI security.

What does OWASP’s Agent Control Standard signal?

The ACS provides an open foundation for making AI agents inspectable, traceable, and instrumentable. It defines how agent platforms can expose middleware hooks and how declarative policies can be enforced through those hooks at runtime.

The 2026 OWASP announcement does not treat the Agent Control Standard as another risk list. The 2026 Top 10 identifies what can go wrong. ACS addresses the control layer needed to govern agent behavior in production.

  • Model security asks what the model might generate.
  • Agent security asks what the agent might access and execute.
  • Runtime governance decides whether a specific action is authorized before it occurs.

Visibility alone is not governance. An enterprise agent may produce a harmless-looking explanation and then use a connected tool to update a customer record, approve an invoice, or retrieve regulated data. The security question is no longer limited to whether the output contains unsafe content. The question is: who is acting, what action is being attempted, which policy applies, and does the action proceed?

LLM guardrails are not runtime authorization

LLM guardrails generally inspect prompts, responses, retrieved context, or generated content. They can classify content, detect prohibited topics, identify sensitive information, and block unsafe outputs. Those controls govern the content layer. They do not automatically govern the action layer.

Control category What it evaluates When it acts What it produces
Content or prompt guardrail Prompt, response, context, or generated content Before or after model generation A classification, warning, redaction, or content block
Identity and access control Agent, user, credential, or connection When access is requested A connection-level allow or deny
Runtime action authorization Specific tool operation, parameters, context, policy, and risk Immediately before execution ALLOW, BLOCK, or ESCALATE with evidence

A content guardrail may identify a risky instruction. It does not necessarily stop an otherwise valid API call. An identity system may confirm that an agent can connect to an ERP system. It does not necessarily determine whether the agent may create a vendor, change a payment account, or approve a transaction. A runtime authorization layer evaluates the exact operation at the point where the action becomes real. Not after the fact. Before execution.

Why excessive agency requires a control point

The 2026 OWASP LLM Top 10 places Excessive Agency at number three. That ranking reflects the operational risk created when an application gives an agent too much functionality, permission, or autonomy.

The problem is not simply that an agent can make a mistake. The problem is that the agent has a path from generated reasoning to business impact. Your procurement workflow may allow an agent to search supplier records, create or modify supplier data, submit a purchase request, and approve a payment. Those capabilities should not automatically share one permission boundary. A user who initiates a transaction should not become the approver through the agent. A tool connection should not become blanket authorization for every operation exposed by that tool.

This is where operation-level authorization differs from connection-level access. The agent may be connected to the system. The requested operation may still be unauthorized. The action must be evaluated against:

  • Agent identity: which agent is acting?
  • Delegated identity: who is the agent acting for?
  • Operation scope: what exact tool function is being called?
  • Data scope: which records or fields are involved?
  • Business context: what workflow and purpose apply?
  • Policy state: which authorization, segregation-of-duties, or compliance rule governs the action?
  • Risk threshold: should the system allow, block, or escalate?

If those questions are answered only in an incident review, the control arrived too late.

ACS points toward three runtime requirements

Conceptual vector diagram showing agent identity, pre-execution authorization, and audit evidence as three connected runtime control stages

The ACS language around inspectability, traceability, and instrumentation translates into three practical enterprise requirements.

1. Inspectability: map what the agent can do

You cannot govern an action surface you have not discovered. At design time, you need an inventory of the agent’s models, tools, data sources, connectors, and exposed operations. You also need to classify those capabilities against business controls such as Segregation of Duties (SoD), privacy requirements, regulated systems, and approval thresholds.

The OWASP ACS resource references an Agent Bill of Materials, or AgBOM, to make an agent’s components and dependencies inspectable.

LangGuard SCOPE-MCP applies the same operational principle to connected tools and MCP environments. It maps the complete action surface: every connected tool, every operation exposed by each tool, every system of record the agent can reach, and every capability that crosses a policy or compliance boundary.

The output is not a generic inventory. It is a control map. You need to know whether an agent can read a record, modify it, approve it, export it, or trigger a downstream workflow. Those are different actions with different control requirements.

2. Instrumentation: observe the action and its context

An event record should explain more than the fact that a tool was called. It should identify the agent and version, the human or service identity represented, the tool and operation, the data or record involved, the workflow and purpose, the policy evaluated, the decision returned, and the timestamp and execution state.

ACS references standardized observability through technologies such as OpenTelemetry and the Open Cybersecurity Schema Framework. The implementation details will vary across enterprise environments, but the requirement is clear: agent activity must produce structured, usable telemetry.

A log line says that something happened. Evidence explains who acted, what they attempted, which policy applied, what decision the system made, and whether a human approved the exception.

3. Runtime control: enforce the decision before execution

Instrumentation without enforcement is observation. The missing control point is the moment between the agent’s request and the tool’s execution.

LangGuard Arbiter operates at that point. It evaluates each proposed action against deterministic runtime policies. Safe actions proceed automatically. Actions that exceed a threshold, cross an SoD boundary, access a regulated system, or violate a defined policy are blocked or routed to a named approver.

The available decisions are simple:

  • ALLOW: the action satisfies policy and proceeds.
  • BLOCK: the action violates policy and does not execute.
  • ESCALATE: the action remains on hold until an authorized person decides.

A practical enterprise checklist for ACS readiness

Conceptual vector illustration of an enterprise AI workflow passing through identity, scope, authorization, approval, monitoring, and evidence checkpoints

Use the following checklist to assess whether your AI governance platform controls the agent or merely observes it.

1. Identity

  • Does every deployed agent have a distinct identity?
  • Can you separate the agent identity from the user identity?
  • Can you identify who delegated the task?
  • Does the policy evaluate both identities before execution?

2. Capability and scope

  • Have you cataloged every connected tool?
  • Have you enumerated every operation exposed by each tool?
  • Can you identify the systems of record and data classes the agent can reach?
  • Have you applied least privilege at the operation level rather than only at the connection level?

3. Runtime authorization

  • Does a policy evaluate every consequential action before the tool call executes?
  • Can the policy consider parameters, data sensitivity, workflow, value, and business purpose?
  • Can the system block actions that exceed the agent’s authorized scope?
  • Can it distinguish a safe read from a high-impact write?

4. Human approval

  • Does a high-risk action route to a named approver?
  • Does the system hold the action until the approver allows or denies it?
  • Does the approval preserve the original action, context, policy, and approver identity?
  • Can the organization demonstrate that a human actually intervened?

5. Testing

  • Do pre-production tests cover prompt injection, excessive agency, tool misuse, and privilege escalation?
  • Do tests verify the enforcement path rather than only the model response?
  • Can you confirm that a denied action remains unexecuted?
  • Do policy changes trigger repeatable control tests?

6. Monitoring and evidence

  • Can operations trace an agent action across models, tools, systems, and workflows?
  • Can security identify unusual action sequences in real time?
  • Can audit replay the authorization decision?
  • Are allow, block, escalation, and approval records tamper-evident?

A checklist is useful only if each answer points to a mechanism, an owner, and evidence. “The agent is monitored” is not a control description. “Every payment-account change is evaluated before execution and escalated to a named finance approver” is.

What does this mean for enterprise AI compliance?

ACS does not make an organization compliant by itself. A standard, platform, or control catalog does not transfer accountability from the enterprise to the technology provider. It does establish a practical direction for enterprise AI compliance: map the system, constrain its actions, instrument its behavior, and preserve evidence.

That direction aligns with the operational expectations behind frameworks such as the NIST AI Risk Management Framework, ISO/IEC 42001, the EU AI Act, SOX, and SOC 2. The exact obligations differ. The control questions remain consistent:

  • What is the system capable of doing?
  • Who authorized the operation?
  • Which policy applied?
  • Was human oversight available at the point of impact?
  • Can the organization reconstruct the decision?

The LangGuard compliance governance approach maps those questions to discovery, authorization, human approval, monitoring, and audit evidence. SCOPE-MCP addresses design-time action-surface visibility. Arbiter enforces runtime decisions.

The distinction is important. Capability mapping supports governance; it is not certification. Evidence supports an audit; it does not replace control ownership.

The standard is moving from “what did the model say?” to “what did the system allow?”

Conceptual illustration of an inspectable, traceable, and instrumentable AI agent surrounded by inventory, telemetry, and enforcement controls

OWASP’s 2026 releases make the direction clear. LLM guardrails govern content. Identity systems govern access. Monitoring systems record activity. None of those capabilities, alone, provides deterministic authorization for a consequential agent action.

An enterprise AI governance platform must connect three layers:

  1. Inspect the agent’s identity, tools, data, and action surface.
  2. Authorize each consequential operation before execution.
  3. Prove what happened through named decisions, approvals, timestamps, and replay-ready evidence.

The agent can still move quickly. Safe actions proceed automatically. Risky actions stop or escalate. That is runtime AI security in operational terms.

The question is not whether your agents have guardrails. The question is whether your enterprise can stop an unauthorized action before it reaches the system of record and prove why the decision was made afterward.

Read the OWASP Agent Control Standard and see how LangGuard maps and governs the agent action layer.