Agent control standard v0.1.0 exposes the runtime governance gap

At a glance

What this is: This is an analysis of the Agent Control Standard v0.1.0 and its attempt to standardize runtime governance for AI agents across trust boundaries.

Why it matters: It matters because IAM, NHI, and security teams need controls that follow agent identity across tools, sessions, and execution surfaces instead of staying pinned to one product boundary.

👉 Read Pillar Security's analysis of the Agent Control Standard and runtime governance for AI agents

Context

Agentic AI creates a governance problem that traditional perimeter controls were never built to solve. The core issue is not just that agents use tools, but that their effective identity can shift as they move between IDEs, MCP servers, build runners, and SaaS systems.

ACS v0.1.0 tries to address that gap by defining a common runtime control plane for agent behaviour. The article frames this as a response to fragmented security enforcement, where each vendor can only govern the agent while it remains inside its own environment.

Key questions

Q: How should security teams govern AI agents that move across multiple trust boundaries?

A: They need runtime controls that follow the agent rather than staying attached to one platform. The practical test is whether enforcement, telemetry, and inventory remain consistent as the agent moves from IDEs to MCP servers to downstream SaaS actions. If the control breaks at the boundary, governance is incomplete.

Q: Why do existing IAM controls struggle with agentic AI workflows?

A: Because IAM controls usually assume a stable identity, a clear request boundary, and a predictable access path. Agentic workflows can change tools, spawn subagents, and shift context mid-session, which makes static entitlements and periodic reviews too slow to capture the real exposure.

Q: How can organisations tell whether agent telemetry is actually useful for investigations?

A: Telemetry is useful when it can be correlated in the SIEM or XDR with identity changes, tool calls, and downstream system effects. If the events stay inside a vendor console or lack enough context to reconstruct the action chain, they will not support incident response.

Q: What should teams do when an agent can spawn subagents or add tools at runtime?

A: Treat runtime composition as a control issue, not a deployment detail. Teams should require live inventory of the agent’s components and define which additions need approval, because each new tool or subagent expands the effective attack surface and changes what the agent can do next.

Technical breakdown

Runtime hooks for agent actions

ACS uses hooks that fire before an agent action executes, giving a control point with context such as the tool, arguments, prior turns, and identity state. That is different from post-event logging because the decision can be permitted, denied, modified, deferred, or sent for confirmation before execution. The control plane is therefore runtime-native rather than policy-after-the-fact. In agentic systems, that matters because a single session may include tool calls, memory writes, subagent spawn events, and output to external systems. The standard is trying to make those intervention points portable across hosts.

Practical implication: security teams should design approval and enforcement logic for pre-execution intervention, not just audit trails.

OpenTelemetry and OCSF for agent observability

ACS maps agent activity into OpenTelemetry and OCSF so events can land in SIEM and XDR pipelines already operated by defenders. The point is not telemetry for its own sake. It is to make agent decisions visible in the same operational systems used for detection, investigation, and correlation. That is important because agent behaviour is distributed across multiple surfaces and may not be meaningful if captured only within one application. Standardised telemetry also supports consistent incident reconstruction when an agent has touched multiple tools or spawned subordinate actions.

Practical implication: teams should verify that agent telemetry is normalised into existing security pipelines, not trapped inside product-specific dashboards.

Dynamic agent bill of materials

ACS treats the agent inventory as live rather than static. The Agent Bill of Materials tracks models, MCP servers, tools, memory stores, and knowledge sources as they change at runtime. That differs from traditional SBOM thinking, which assumes a mostly stable software composition. For agents, the relevant question is not only what was deployed at build time, but what the agent could access or combine during execution. This runtime inventory model is central to understanding exposure, especially when the agent can add tools, read memory, or spawn subagents mid-session.

Practical implication: security and governance teams should require runtime component inventory, not rely on build-time artefacts alone.

NHI Mgmt Group analysis

Runtime governance is becoming a control-plane problem, not a point-solution problem. ACS matters because the article identifies a real gap: agent controls today do not follow the actor across environments. That leaves defenders with local enforcement in a world where the agent crosses local boundaries by design. The implication is that agent governance will increasingly be judged by whether controls are portable, not whether they exist inside one platform.

Agent identity now behaves like an execution path, not a static account. The article shows that an agent’s effective identity changes with the surface it is using, the tools it invokes, and the subagents it spawns. That breaks the usual assumption that a security team can define a single identity boundary for the session. Practitioners should treat this as a governance shift from stable account control to runtime identity continuity.

Dynamic tool use creates an identity laundering risk across trust boundaries. When an agent can move from IDE to MCP to SaaS, the trust context changes even if the user intent has not. ACS is relevant because it tries to make those transitions inspectable and governable before the action occurs. The field implication is that control failures will increasingly come from boundary drift, not just from bad prompts or weak authentication.

Autonomous identity assumptions are collapsing because least privilege is no longer fully knowable at provisioning time. Least privilege was designed for conditions where access intent is mostly stable and reviewable. That assumption fails when an agent can decide which tool to call, when to call it, and whether to spawn a subagent mid-session. The implication is that governance programmes must rethink static entitlement thinking for actors whose effective scope changes during execution.

Agent control standard is a useful named concept because it captures the emerging need for portable runtime intervention across the agent lifecycle. The article’s value is not the specific hook mechanism alone, but the move toward a common contract for what defenders can see and stop. That concept will matter wherever multiple vendors, tools, and runtimes share responsibility for the same agent behaviour. Practitioners should treat runtime standardisation as a governance prerequisite, not a feature request.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader view of agent risk patterns, see OWASP Agentic AI Top 10 for the control failures that commonly appear when agents misuse tools or cross trust boundaries.

What this signals

Agent Control Standard: the category is moving toward shared runtime intervention rather than isolated product guardrails. With 92% of organisations agreeing that governing AI agents is critical to enterprise security but only 44% having implemented any policies, the gap is now operational rather than conceptual. Teams should prepare for governance models that combine runtime hooks, telemetry, and component inventory in one control story.

The next maturity step is not simply better logging. It is proving that agent actions can be governed across every trust boundary where execution can continue, and that evidence can be reconstructed after the fact without relying on a single vendor’s console.

For teams building their programme now, the strategic question is whether the agent can be stopped, traced, and inventoried after it changes tools or context. If not, the control plane still belongs to the platform, not to the defender.

For practitioners

• Map where agent control is currently trapped inside one vendor perimeter Inventory every place your agent can act across IDEs, build runners, MCP servers, and SaaS applications, then identify where enforcement disappears at each boundary. Prioritise the seams where the same agent can keep working without a shared control plane.
• Require pre-execution intervention points for high-risk agent actions Define which actions must be permitted, denied, modified, or deferred before execution, especially for tool calls, memory writes, and subagent spawn events. Treat post-action logging as insufficient for containment.
• Normalise agent telemetry into your existing security stack Ensure agent events are emitted in formats your SIEM and XDR pipelines can already parse, so investigations can correlate tool use, identity changes, and downstream effects without vendor-specific parsing.
• Demand a live inventory of models, tools, and memory stores Replace static build-time inventories with runtime component visibility, because agent exposure changes when tools are added, memory is written, or new knowledge sources become available during a session.

Key takeaways

• ACS v0.1.0 addresses a real governance gap by trying to standardise runtime control for agents that move across tools, hosts, and vendors.
• Agent governance is already a high-risk operational problem, not a future-state concern, because current deployments are showing rogue behaviour and visibility gaps.
• Practitioners should focus on portable enforcement, runtime inventory, and security telemetry that survives trust-boundary changes.

Key terms

• Agent Control Standard: A shared specification for runtime governance of AI agents. It defines how defenders can intervene before actions execute, so controls can move with the agent across tools, hosts, and trust boundaries instead of remaining locked inside one product.
• Runtime Hook: A callback that fires before an agent action runs. In practice, it gives security teams a decision point with enough context to permit, deny, modify, ask about, or defer execution before the action reaches another system.
• Dynamic Agent Bill of Materials: A live inventory of the components an agent can use, including models, tools, memory stores, and knowledge sources. Unlike a static software bill of materials, it reflects runtime changes that alter the agent's effective exposure during a session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Pillar Security: Standardizing the Control Plane for AI Agents: Pillar's Role in ACS v0.1.0. Read the original.