Microsoft ACS: Agent Controls Move Into the Runtime

Microsoft announced the Agent Control Specification (ACS) at Build 2026 on June 2. ACS is an open, fail-closed policy runtime that evaluates an agent at 8 intervention points and returns 1 of 5 verdicts: allow, warn, deny, escalate, transform. It moves agent approval from install time to call time.

Updated September 2026: ACS is now vendored into Microsoft’s Agent Governance Toolkit as the AGT 5.0 policy layer, still marked Public Preview, and the toolkit publishes alignment mappings for the NSA MCP guidance and the OWASP MCP Top 10. The runtime contract described below is unchanged.

Key figures

Figure	What it measures	Source
8	intervention points ACS evaluates, from agent_startup to agent_shutdown	Agent Governance Toolkit
5	verdict types: allow, warn, deny, escalate, transform	Agent Governance Toolkit
4	policy backends: rego, cedar, test, custom	Agent Governance Toolkit
4	language SDKs shipped: Python, Node.js, .NET, Rust	Agent Governance Toolkit
8	top-level blocks in an ACS policy manifest	Agent Governance Toolkit
3	runtime properties the spec guarantees: stateless, deterministic, fail-closed	Agent Governance Toolkit
7	agent frameworks with launch plug-ins, including LangChain, CrewAI and AutoGen	TechCrunch
6	MCP servers in one practitioner’s production agent stack	Reddit
~180	tools those 6 servers exposed to a single agent	Reddit

The launch picked up mainstream developer coverage from TechCrunch and governance-focused coverage from WinBuzzer. At the same time, practitioners were arguing in public about the operational side of MCP: a Reddit thread from someone shipping agents in production described 6 MCP servers, roughly 180 tools, stale OAuth ownership, oversized tool descriptions, wrong tool selection, and the need for a gateway layer.

Those are not separate conversations. They are the same pressure showing up from two directions: agents now have too many ways to act, and teams need policy that can follow those actions at runtime.

What ACS Actually Adds

ACS is part of Microsoft’s Agent Governance Toolkit (AGT), which describes the runtime in one sentence:

Agent Control Specification, or ACS, is AGT’s stateless, deterministic, fail-closed policy decision runtime. At each intervention point, a host sends a policy manifest and complete snapshot to ACS. ACS returns a normalized verdict; the host enforces it.

— Microsoft, Agent Governance Toolkit docs

Microsoft’s Build post summarizes the lifecycle as input, LLM call, state, tool execution and output. The specification is more precise: ACS evaluates 8 named intervention points — agent_startup, input, pre_model_call, post_model_call, pre_tool_call, post_tool_call, output and agent_shutdown. Each call carries the complete snapshot for that point, because the runtime retains no state that could influence a later verdict.

Figure: ACS turns 8 points in the agent loop into 1 policy call each. The runtime is stateless, so the host must supply the full snapshot every time, and a runtime error returns deny.

Determinism is what makes a policy testable in CI: the same manifest, snapshot, mode and dispatcher output produce the same verdict every time. Fail-closed is what makes it safe to deploy: a runtime error returns deny with a reserved reason code and applies no transform.

The verdicts are also broader than allow/deny. escalate routes an action to an approval backend and fails closed if none is configured. transform hands the host a modified policy target — redacted output, for example — to apply instead of the original.

The important part is not the exact number of hooks. It is the shape of the control. ACS is not another system prompt telling the model to behave. It is not a one-off if statement buried in one LangChain app. It is policy-as-code that can be versioned, reviewed, tested and attached to agent behavior across frameworks — and per TechCrunch, it shipped with plug-ins for LangChain, the OpenAI Agents SDK, the Anthropic Agents SDK, AutoGen, CrewAI, Semantic Kernel and Microsoft.Extensions.AI.

That is why TechCrunch’s detail about packaging policies as single files matters. If a policy can travel with an agent, then security review can move closer to the thing being deployed. If the runtime can enforce the policy at tool-call time, then approval is no longer a static checkbox at install.

Why Tool-Call Runtime Matters

Skill and plugin supply-chain risk has a time dimension.

The first question is whether the artifact is safe before install. Does the skill contain hidden instructions? Does the plugin touch ~/.claude, .cursor, MCP config, shell history, SSH keys, browser sessions, or package-manager credentials? Does an MCP server declare one set of tools while quietly exposing another? That is the scanning and provenance layer, and it is what our MCP security guide covers.

The second question is whether the action is safe at the moment it runs. A skill that was benign at install can still steer an agent into a risky tool chain. A legitimate MCP server can be used with unsafe arguments. A tool description can change after review. A human can approve “GitHub access” and later discover that the agent used that token to rewrite repository settings, invite a user, or open a release pipeline.

ACS is aimed at that second question. So is the rest of the field: OWASP now publishes an MCP Security Cheat Sheet built around exactly this split between what a server is and what a call does, and the MCP specification’s own security best practices make confused-deputy and token-passthrough problems normative concerns rather than implementation trivia.

This is especially important for MCP because MCP turns tool metadata into model context. We covered the same underlying risk in MCP tool poisoning: descriptions and schemas are not just documentation. They influence agent behavior. Invariant Labs, which named the class, showed that a single poisoned tool description is enough to make an agent read files the user never mentioned.

The Reddit thread this week made the non-malicious version of the same point. A long Slack search description beat a Stripe invoice tool because the model saw “find” more often in the wrong place. That is not exfiltration, but it is still a control failure.

When tool descriptions are prompt material, tool selection becomes a security and reliability boundary.

Static Approval Is Too Weak

A lot of agent products still treat approval as an install-time event:

• install this MCP server
• add this plugin
• trust this skill
• connect this OAuth account
• allow this workspace connector

That model is easy to understand, but it is too coarse for agent workflows. It approves a bundle, not a behavior.

The risky behavior usually appears later:

• a tool adds a write action after the original review
• an agent calls the right tool with dangerous parameters
• one server poisons another server’s tool use
• a skill changes the agent’s intent before a privileged call
• a connector receives broader OAuth scopes than the task needs
• a contractor-owned token becomes part of the production path
• a benign tool description grows into a 1,200-token steering prompt

That is why Microsoft’s ACS launch matters even for teams that do not use Microsoft Foundry. It signals that agent governance is moving toward runtime checkpoints: inspect the current request, current state, selected tool, arguments, output, and approval path before letting the action continue.

This is the same pattern security teams already know from API gateways, admission controllers, CI policy engines, and infrastructure-as-code review. The agent-specific difference is that the model sits between intent and execution. You need to evaluate both the human request and the model-selected action.

The Supply Chain Layer Still Comes First

Runtime controls do not replace supply-chain verification. They depend on it.

If a policy says “allow this skill to call the GitHub issue search tool,” the runtime still needs to know which skill was installed, who published it, which version was scanned, and whether the consumer received the same bytes that were reviewed. If a policy says “deny tools that write outside the project workspace,” the scanner still needs to catch skills that quietly rewrite agent memory, install persistence, or modify MCP configs before runtime policy ever sees a call.

Figure: Gate 1 decides whether a capability enters the agent’s trusted set. Gate 2 decides whether a specific action proceeds. Scanning cannot predict runtime arguments; policy cannot read an instruction nobody scanned.

That is the gap SkillSafe is built around. Dual-side verification gives publishers and consumers a way to compare the reviewed artifact against the artifact that actually arrives before install.

The agent ecosystem now has several artifact types that behave like software dependencies:

• skills that change agent behavior
• plugins that bundle commands, prompts, tools, and install logic
• MCP servers that expose tool schemas and credentials
• connector manifests that grant account access
• marketplace listings that route users toward trusted-looking packages
• runtime-discovered tool definitions that can drift after approval

Each artifact needs provenance and inspection before trust. Runtime policy answers “should this action proceed right now?” Supply-chain scanning answers “should this capability have entered the agent’s trusted set at all?”

You need both. Snyk’s ToxicSkills audit is the blunt argument for the first gate: 1,467 of 3,984 published skills — 36.82% — carried at least one security flaw, a population no runtime policy can reason about if it never saw the file. We broke the numbers down in the first skill-ecosystem audit.

Practical Defenses After ACS

Treat Microsoft’s announcement as a useful direction, not a magic shield. The immediate work is still basic and concrete, and most of it is already written down as 12 checks across four phases.

1. Inventory agent capabilities. List every skill, plugin, MCP server, connector, marketplace install and custom tool your agents can reach. Include local developer configs, CI machines, desktop agents and cloud-hosted runtimes.
2. Attach ownership and provenance. For code-distributed artifacts, capture source URL, publisher, version, commit, hash, scan report and install path. For hosted MCP servers and connectors, capture operator, URL, auth model, exposed tools, expected scopes and data paths.
3. Make tool permission task-scoped. Do not load every MCP server into every agent session. One practitioner’s 6 servers and 180 tools is the failure mode: project-specific tools belong at project scope, and high-risk write tools should be hidden until needed.
4. Review tool descriptions as policy input. Long descriptions, hidden instructions, cross-tool references, credential-file references and undocumented side effects are not just quality issues. They change model behavior.
5. Put runtime checks around high-risk actions. Shell execution, filesystem writes, package publishing, repository administration, cloud changes, database mutation, messaging, customer-data export and credential access deserve explicit allow/deny/escalate logic.
6. Log the chain, not just the API call. Useful audit records need the user request, selected tool, arguments or argument hash, artifact identity, policy verdict, approval path and returned output. Without that chain, teams cannot tell whether the agent made a bad choice, a tool description steered it, or a skill instructed it.
7. Scan before install and re-scan on change. A runtime policy layer is strongest when the artifacts entering the runtime have already been checked for malicious instructions, hidden networking, persistence, config tampering and exfiltration patterns. Browse what you have installed against the SkillSafe registry and re-scan on every version bump.

Where This Leaves Agent Teams

ACS is interesting because it accepts a reality the agent ecosystem has been circling for months: system prompts are not enough, and install-time trust is not enough.

The strongest agent security architecture is layered:

1. Verify the source before the artifact enters the environment.
2. Scan the artifact for suspicious behavior and hidden instructions.
3. Scope the permissions the agent can use.
4. Enforce policy at runtime checkpoints.
5. Log the full decision chain.
6. Re-review when tools, scopes, descriptions, or versions change.

That model applies whether the artifact is a SkillSafe skill, a Claude Code plugin, a Cursor rule, an MCP server, a Copilot connector, or an internal agent marketplace package. It is also the same layering the NSA’s MCP guidance arrived at from the other direction, two weeks earlier.

Microsoft’s ACS does not solve the entire problem. No runtime policy layer can prove that every skill or plugin was safe to install. No scanner can predict every possible runtime argument. But together, provenance, scanning, scoped permissions, and deterministic runtime controls start to look like the right shape of defense.

Frequently Asked Questions

What is Microsoft’s Agent Control Specification?

ACS is an open specification and runtime for agent policy, announced at Build 2026 on June 2 and shipped inside Microsoft’s Agent Governance Toolkit. A host sends a policy manifest and a full snapshot at any of 8 intervention points; ACS returns 1 of 5 verdicts. The runtime is stateless, deterministic and fail-closed, with SDKs for Python, Node.js, .NET and Rust.

Does ACS replace scanning agent skills before install?

No. ACS evaluates an action at the moment it runs; it does not read the artifact that produced the action. A skill file carrying hidden instructions still has to be caught before install by provenance and content scanning. Snyk’s audit of 3,984 published skills found a security flaw in 1,467 of them — a population runtime policy never inspects.

Are MCP servers a security risk?

They are an unmanaged one. An MCP server is an integration layer that acts with whatever credentials it holds, so a compromised tool call is an action inside your environment, not just a bad model response. The OWASP MCP Security Cheat Sheet and the protocol’s own security best practices both treat inventory and scoped tokens as the baseline.

How is ACS different from a system-prompt guardrail?

A system prompt is advice the model may ignore, and it lives inside the thing being governed. ACS is a decision made outside the model: deterministic, versionable, testable in CI, and enforced by the host. The same manifest produces the same verdict every time, and a runtime error produces deny rather than a silent pass.

How many MCP tools are too many for one agent?

There is no hard limit, but tool descriptions are prompt material, so every added tool competes for model attention. One production report described 6 servers exposing roughly 180 tools, with the agent picking a Slack search over a Stripe invoice lookup because the word “find” appeared more often in the wrong description. Scope tools per task rather than loading them globally.

The useful lesson from this week’s discussion is simple: agent tools are not just integrations anymore. They are a supply chain and an execution surface. Treat them like both — scan what enters, and govern what runs.