New Open Standard Puts AI Agents Under Runtime Control

The AI agent stack has a control problem. Teams have MCP for tool connections, half a dozen orchestration frameworks, and an industry's worth of benchmarks for measuring what agents can do. What they don't have is a shared way to govern what agents actually do once they start acting.

Every organization builds its own guardrails: system prompts here, custom classifiers there, framework-specific middleware bolted on as an afterthought. None of it's auditable across teams. None of it transfers between frameworks.

On May 27, Zenity launched the Agent Control Standard (ACS) at the AI Agent Security Summit in San Francisco. ACS is an Apache 2.0 open specification that defines middleware hooks for runtime policy enforcement across agent execution workflows - a control plane that sits between your agent framework and every action the agent takes.

The Problem It Solves

Agents running in production have access to email, databases, code repositories, and internal APIs. When one calls send_email or execute_sql, there's normally no shared mechanism to intercept that action and check it against policy before it executes. Each team writes their own. None of it is consistent.

A Cloud Security Alliance survey found that 68% of organizations can't distinguish AI agent activity from human activity in their logs. That gap isn't just an observability problem - it's a governance gap, and it grows as agent deployments scale. Researchers at Stanford and Harvard red-teamed enterprise agent deployments last year and found the attack surface was larger than most security teams realized.

The industry has addressed how agents communicate. It hasn't addressed what they're allowed to do.

Three Layers, One Specification

ACS defines three independent layers that together cover the full agent action lifecycle.

Instrument - The Hook Layer

The Instrument layer defines standardized middleware hooks that fire at seven decision points: when an agent receives input, selects which tools to use, calls a tool, transitions from planning to execution, stores a memory, executes code, or invokes a sub-agent.

At each hook, a Guardian Agent intercepts the proposed action, evaluates it against a declarative policy, and returns a verdict before execution. The verdict is one of three options: allow, deny, or modify.

policies:
  - name: block-pii-outbound
    trigger: tool_call
    filter:
      tool: email_send
    conditions:
      - field: args.body
        contains_pii: true
    action: deny
    reason: "PII detected in outbound message"

Policies are portable YAML files that travel with the agent across frameworks. A policy written for a LangChain agent can be applied to a CrewAI agent without changes.

Trace - The Observability Layer

Hook invocations produce events. The Trace layer defines how those events are structured, using extensions to OpenTelemetry and the Open Cybersecurity Schema Framework (OCSF) with agent-specific semantic conventions.

Every intercepted action creates a structured trace event that existing SIEM tools and observability stacks can consume. No custom instrumentation required.

Inspect - The Inventory Layer

The Inspect layer produces what ACS calls an Agent Bill of Materials, or AgBOM. It extends supply chain standards - CycloneDX, SPDX, and SWID - to track an agent's real-time capabilities, tool integrations, and active dependencies. When an agent loads a new plugin or spawns a sub-agent at runtime, the AgBOM updates automatically.

The AgBOM is ACS's answer to the "what is this agent actually capable of right now" question, which current deployments can't reliably answer.

The Decorator Pattern in Practice

The Python SDK wraps any tool function with a @control() decorator. No changes to the framework underneath:

from agent_control import control, Policy

policy = Policy.from_yaml("policies/prod.yaml")

@control(policy=policy)
def send_email(to: str, subject: str, body: str) -> dict:
    return email_client.send(to, subject, body)

When send_email is called, the decorator intercepts the arguments before execution, runs them through the Guardian Agent, and either passes through or raises PolicyViolation with the reason code and the triggering rule. The agent framework sees a standard exception and handles it according to its own error logic.

TypeScript support exists but lags the Python implementation.

The ACS decorator pattern wraps existing tool functions without requiring changes to the underlying agent framework code. Source: unsplash.com

Framework Compatibility

ACS currently has native extension point integrations for four frameworks. Everything else requires wrapper-based integration, which the community is building out.

The best-performing agent frameworks for production deployments currently span both columns - which means ACS adoption requires manual work for roughly half the ecosystem.

Where It Falls Short

ACS is early. The spec is solid; the tooling is thin.

The four natively supported frameworks are a reasonable start, but anything not on that list needs custom wrapper code - the same scattered custom logic ACS is trying to replace in the first place. Teams not using LangChain or CrewAI get a spec they can implement themselves, not a ready-made SDK.

The Guardian Agent pattern is only as strong as the policy engine's classifiers. ACS intercepts a send_email call, but if the PII detector misses an obfuscated phone number in the body, the policy doesn't fire. The spec doesn't mandate classifier implementations, leaving that to each team. This is intentional - it keeps ACS vendor-neutral - but it also means the hard part of making policies work is still on the implementer.

Credential and identity management sit outside ACS's scope. The CSA finding - that 68% of organizations can't distinguish agent from human activity - isn't solved by middleware hooks. Task-level permission scoping and agent identity remain separate problems.

ACS addresses what agents do at runtime, but credential management and identity scoping are handled separately. Source: pexels.com

Finally, the EU AI Act compliance mapping is aspirational. ACS covers the technical requirements for real-time intervention and human oversight. But no regulatory body has reviewed whether an ACS implementation satisfies the law. Enterprise buyers making procurement decisions today are on their own there.

The Fragmentation Risk

The agent governance space already has several products targeting the same gap. Microsoft's Agent Governance Toolkit shipped in April with seven modular packages under a MIT license. Cisco's DefenseClaw takes a gateway approach with a different architecture. Zenity runs its own commercial platform with the ACS contribution.

Ben Kliger, Zenity's CEO, said that when announcing the company's contextual security platform earlier this year. The same dynamic drives ACS: the current approach of ad hoc guardrails doesn't hold at enterprise scale.

ACS is an attempt to create shared vocabulary underneath the competing products - a common hook definition that any of them could implement, rather than each building to their own spec. Whether it works depends on whether major framework maintainers adopt ACS hooks natively, or continue building proprietary control layers.

The key signal to watch: LangGraph, AutoGen, and the OpenAI Agents SDK haven't committed to ACS. If one of them ships native integration in the next two quarters, the standard has traction. If none do, it stays a Zenity-adjacent spec with narrow adoption.

Sources:

• Agent Control Standard Launch - BriefGlance
• ACS Specification - agentcontrolstandard.ai
• Agent Control Standard Builder Guide - ChatForest
• Microsoft offers devs better agent control - TechCrunch
• Zenity contextual security for AI agents - Help Net Security
• AI Agent Security Summit 2026 - Zenity