Standardizing the Control Plane for AI Agents: Pillar's Role in ACS v0.1.0

Ariel Fogel

and

June 2, 2026

min read

The Agent Control Standard (ACS) went public at v0.1.0 on May 27, 2026. ACS is the first open, MIT-licensed spec for runtime governance of AI agents. Pillar is one of its founding contributors. This blog post explains what ACS is for, why it matters now, and how Pillar is adopting it across our platform.

Why a Standard for Agent Control

Every agentic workflow in production today crosses trust boundaries throughout its lifecycle. An agent may start in an IDE, call an MCP server, run in a build runner, and write to a SaaS app on the way out. Its identity may change hands at every step, but its controls don't currently follow.

The world of Agentic AI has been necessarily adopting new standards: MCP and A2A standardized how agents talk. The OWASP Top 10 for Agentic Applications catalogs how agents fail. To date, however, there is no standardized method to enable how a defender intervenes. This is the gap ACS exists to close. Without it, every security vendor builds runtime controls inside its own perimeter, and those controls can't follow an agent as it crosses from one product to the next. The threats agents introduce keep slipping through the seams: prompt injection, identity laundering across tool boundaries, silent capability hot-swaps, ungoverned memory writes.

The agent threat model requires rethinking some of the traditional security perimeters that aren’t suited to handle the autonomy, speed, and capability that agentic systems work at. Identity in particular is a first-class problem: an agent's effective identity at any given moment depends on which surface it's acting through, what tools it's invoking, and which subagent it just spawned. The defender's stop button has to ride along with that identity, not stay pinned to one host.

What ACS Is

The Agent Control Standard is a flexible, vendor-neutral specification for the agent control plane. This initiative is analogous to what OpenTelemetry did across industry. In fact, ACS uses OpenTelemetry directly for its observability surface. Where OpenTelemetry standardized how every vendor emits telemetry about their software, ACS standardizes how security vendors expose and enforce runtime controls over agents. While the implementation is dictated by each security vendor, the interface to support each control plane is shared.

The mechanism is the hook: a callback the agent's host runs before an action executes, with enough context (e.g., tool, arguments, identity, prior turns) for a separate Guardian Agent to permit, deny, modify, ask about, or defer that action. Hooks already exist across IDEs, coding agents, MCP servers, and most agent frameworks; ACS turns the ad-hoc collection into a common contract.

The spec rests on three capabilities, each covering the agent lifecycle end to end:

Instrument — Runtime hooks across every step of the agent's life: session start, user message, tool call, memory read and write, knowledge retrieval, subagent spawn, response, session end. The full lifecycle, not just the request/response edge.
Trace — Structured observability for every agent decision, emitted in OpenTelemetry and OCSF, so the events land in the SIEM and XDR pipelines security teams already operate.
Inspect — A dynamic Agent Bill of Materials that tracks the agent's components — models, MCP servers, tools, memory stores, knowledge sources — as they change at runtime. Static SBOMs miss the point of agents; the inventory has to be live.

Together they answer the three questions every security team needs answered about an agent in production: what did you do, what can you do, and who said you could do it?

ACS is built to be adopted in layers. The simplest deployment, like a single IDE harness, implements a small mandatory core and stops there. A more demanding deployment switches on additional layers for observability, a live component inventory, data-lineage tracking, and post-quantum-safe signatures, all over the same wire format. Each layer is a profile a deployment opts into, so teams adopt only what they need rather than all of ACS at once.

How to Engage

The spec lives at agentcontrolstandard.ai; the working group develops it in the open at github.com/Agent-Control-Standard/ACS. To see how Pillar's runtime guardrails work in a production deployment, request a demo.

FAQs

What is the Agent Control Standard (ACS) and why was it created?

The Agent Control Standard (ACS) is an open, MIT-licensed specification for runtime governance of AI agents, published at v0.1.0 on May 27, 2026. It was created to close a critical gap: while MCP and A2A standardized how agents communicate, no standardized method existed for how defenders intervene. Without ACS, runtime controls stay siloed inside individual vendor perimeters and cannot follow an agent across trust boundaries.

How does ACS handle AI agent identity and control across trust boundaries?

ACS addresses agent identity as a first-class security problem by attaching the defender's controls to the agent's identity rather than to a fixed host. Because an agent's effective identity shifts depending on which surface it acts through, which tools it invokes, and which subagents it spawns, the stop button must travel with that identity across every boundary — from IDE to MCP server to SaaS output.

What are the three core capabilities defined in the ACS specification?

ACS is built on three capabilities: Instrument, which places runtime hooks at every lifecycle stage including session start, tool calls, memory reads and writes, and subagent spawns; Trace, which emits structured observability data in OpenTelemetry and OCSF format for existing SIEM and XDR pipelines; and Inspect, which maintains a dynamic Agent Bill of Materials tracking models, tools, and memory stores as they change at runtime.

How does ACS use OpenTelemetry for AI agent observability?

ACS uses OpenTelemetry directly for its observability surface, emitting structured events for every agent decision in both OpenTelemetry and OCSF formats. This design ensures agent activity data lands natively in the SIEM and XDR pipelines security teams already operate, rather than requiring new tooling. The approach mirrors what OpenTelemetry did for general software telemetry, applied specifically to the agent control plane.

How is Pillar Security involved in the Agent Control Standard?

Pillar Security is a founding contributor to the Agent Control Standard and is adopting ACS across its platform. Pillar's involvement reflects its focus on runtime protection for AI agents and the recognized need for vendor-neutral controls that can follow agents across environments. The ACS hook mechanism — which allows a Guardian Agent to permit, deny, modify, or defer actions before execution — aligns directly with Pillar's runtime guardrails approach.