Microsoft ACS: Agent Controls Move Into the Runtime

The agent security story this week is shifting from “what can go wrong?” to “where do we enforce the decision?”

On June 2, Microsoft used Build 2026 to announce the Agent Control Specification (ACS), an open specification for placing deterministic safety and security controls at checkpoints inside agent workflows. Microsoft framed ACS as the governance equivalent of MCP and A2A: MCP standardizes how agents connect to tools, A2A standardizes how agents communicate with each other, and ACS tries to standardize where policy decisions happen.

That made it the most relevant agent-tooling story to SkillSafe this week. The launch picked up mainstream developer coverage from TechCrunch and security/governance coverage from WinBuzzer. At the same time, practitioners were arguing in public about the operational side of MCP: a fresh Reddit thread from someone shipping agents in production described six 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. The toolkit describes ACS as a stateless, deterministic, fail-closed policy decision runtime for agent security. In plain language: the agent reaches a checkpoint, ACS receives a normalized snapshot of what is about to happen, policy evaluates that snapshot, and the runtime gets back a verdict.

Microsoft’s Build post describes five lifecycle checkpoints:

• input
• LLM call
• state
• tool execution
• output

The docs and follow-on coverage describe the same idea in more granular terms: startup, inbound requests, model-call stages, tool-call stages, output, shutdown, evidence gathering, and normalized verdicts such as allow, warn, deny, escalate, or transform.

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.

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.

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.

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. 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.

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.

Practical Defenses After ACS

Treat Microsoft’s announcement as a useful direction, not a magic shield. The immediate work is still basic and concrete.

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.

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.

Make tool permission task-scoped. Do not load every MCP server into every agent session. Project-specific tools should live at project scope. High-risk write tools should be hidden until needed and gated by approval.

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.

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.

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.

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.

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.

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.

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.