Microsoft ACS·ASSERT Commentary: Why AI agent governance should anchor runtime policy manifests and execution evaluations before prompts

Agent Control Specification (ACS) and ASSERT from Microsoft Build 2026 change the agent operation standards one step further. The key is not to have longer system prompts, but to plug in policies and evaluations at each point where the agent receives input, calls a model, runs a tool, and emits results.

1. One-line problem definition

Key line: When an AI agent starts executing real tools, the security question changes from “What should I make it say?” to “At what point do I block an action, and how do I justify it?”

Chatbots generally generate sentences. However, coding agents, business automation agents, and in-house operations agents read files, run shells, send mail, modify tickets, and call external APIs. In this case, simply writing “Don’t do anything dangerous” at the system prompt is not enough.

This article is intended for platform teams, security teams, and development productivity teams that operate agent products. The scope is how to design runtime policies, tool call blocking, audit logs, and regression evaluation based on Microsoft's ACS and ASSERT. It does not cover specific Microsoft cloud product purchase recommendations or simple model performance comparisons.

2. First, conclusion

Key one-liners: To put agents into production, you need to move policies into manifests, not prompts, and quality checks into actionable assessments, not sentiments.

ACS is an attempt to apply the same policy manifest no matter what the agent framework is. Evaluates policies on input, before and after model calls, before and after tool calls, on final output, at start and end points, and returns standard decisions such as allow, warn, deny, and escalate.

ASSERT is a tool that turns natural language requirements such as “Our agent should behave like this” into test cases, execution logs, and scorecards. It is important to evaluate whether the agent followed the policy by not only looking at the final response, but also recording tool calls and intermediate actions.

Teams that need to be reviewed right now are organizations that entrust agents with actual actions such as shell execution, file modification, customer data access, mail sending, and distribution. Conversely, if it's a low-risk tool that a person always executes last, such as internal document retrieval or draft generation, you can start with a simpler approval UI and log than the full ACS stack.

3. Decomposition of core structure

Key one line: ACS is a checkpoint in the agent loop, and ASSERT is a device that iterates over whether that checkpoint actually works.

1. Policy Manifest: Which policy to evaluate at which life cycle point is stored in a declarative file such as YAML. The key is to make policies a reviewable artifact rather than hiding them deep in code.
2. 8 intervention points: ACS defines agent_startup, input, pre_model_call, post_model_call, pre_tool_call, post_tool_call, output, agent_shutdown as policy evaluation points:
3. Standard input shape:The policy engine takes structured input such as tool name, arguments, session snapshot, user role, previous tool invocations, and classifier results.
4. Policy engine and evidence collection: Policy languages ​​such as Rego, DLP, classifiers, LLM judges, and external security services provide evidence for policy judgments.
5. Standard verdict: Policy results are normalized to common verdicts such as allow, warning, deny, and approve escalation. In case of failure, fail-closed processing, i.e. closing to safety, is also a design target.
6. ASSERT evaluation loop: Turns natural language policies into behavioral taxonomies, generates test cases, runs real agents, and scores them, including tool calls and intermediate states.

Compared to the standards of a novice developer, ACS is “a security gate just before execution,” and ASSERT is “an automatic test paper that checks whether the security gate is closed at the moment when it is really needed.”

4. Description of design intent

Key one-liner: The problem Microsoft is targeting is not the lack of guardrails in a specific framework, but the lack of a standard agreement to reuse and audit policies across the organization.

Existing methods are largely scattered. Some teams put prohibition statements in the system prompt, some put checking code in LangChain callbacks, and some teams use Semantic Kernel filters or their own API middleware. Although each method is partially useful, it is difficult for security teams to see at a glance “where the enterprise agent policy is and what version is applied.”

The design intent of

ACS is to change this point. It takes policies out of the framework's internal code and establishes common intervention points, input structures, and decision formats. This reduces the need to rewrite policies used in Python services when moving them to a Node sidecar or .NET host.

The intent of

ASSERT is similar. Requirements such as “Refunds are automatically approved only for amounts under 100,000 won,” “Confidential documents must not be sent to external recipients,” and “Malicious instructions within search results must not be followed” are usually found only in documents. ASSERT turns these statements into evaluation data and execution logs to run like a regression test.

The trade-off is clear. This structure is heavier than a simple prompt guard. You need to create policy inputs, attach evidence collectors, and manage test sets. But when agents actually exercise power, this complexity becomes less of a choice and more of an operating cost.

5. Evidence and Comparison

Key line: ACS and ASSERT are not a proposal to abandon existing guardrails, but rather to bundle scattered controls into executable operating contracts.

Approach	What you're good at	Vulnerable point	Recommendation status
System Prompt Rules	Quick start, suggests model action direction	Enforcement is weak as it is mixed in the same stream as user input, search results, and tool output	Draft creation, low-risk chatbot
Framework-specific callbacks/guardrails	You can actually inspect before and after calling the tool	Needs to be rewritten for each framework and difficult to audit by security team	Single app, single runtime
General Policy Engine	Strong in structured authority judgments	There is no standard for which state to pass to at which point in the agent loop	Team with existing IAM/OPA experience
ACS + ASSERT	Intervention points, input shapes, judgments, and regression evaluations can be designed together	Initial design and observability investment required	Tool executable agent, multi-framework operation, audit request organization

The official Microsoft ACS article notes that traditional access controls answer “Can these credentials call this resource?” but are weak on “Is calling this tool safe, given the sensitive documents this agent has read so far and the current state of the conversation?”

The Microsoft Agent Framework announcement revealed production environment patterns such as Agent Harness, Hosted Agents, CodeAct, and Handoff orchestration. In particular, Hosted Agents emphasizes session state, autoscaling, observability, and isolated sessions. This fits into the context of the need for ACS. The longer an agent runs and maintains state, the more policies should look at the entire life cycle, not just a one-time filter.

ASSERT announcement is also important evidence. Microsoft explains that ASSERT covers about 1.2 times more of the action space than direct generation, reveals about 1.5 times more cases worth checking, and increases the separation of strong and weak systems by more than 4 times. The more important message than the numbers themselves is that assessment quality comes from the structuring of behavioral definitions, not from a single line of prompts.

6. Actual operation flow / step-by-step execution method

Key line: Rather than creating an enterprise standard from scratch, it is more realistic to select a risky tool such as sending external mail or deploying to production and pilot it.

1. Create a tool inventory. Tabulate the tool names, arguments, writing permissions, and access to sensitive data that can be called by the agent.
2. Choose one high-risk tool For example, send_email, deploy_prod, run_shell, refund_payment first. Covered.
3. Creates a pre_tool_call policy. Checks user role, recipient domain, access to sensitive documents, and authorization status just before tool execution.
4. Attach the post_tool_call policy. Tool results are checked for secrets, errors, and external directives before being put back into the model context.
5. Create a regression evaluation with ASSERT. Create a test set containing tool results that are a mixture of normal requests, alert requests, malicious requests, and prompt injection.
6. View results as operational indicators. Weekly review of block rate, false positive rate, approval waiting time, reasons for policy failure, and judge rationale.

agent_control_specification_version: "0.3.1-beta"
metadata:
  name: "internal-email-agent"
policies:
  email_policy:
    type: rego
    bundle: ./policy
    query: data.email_agent.verdict
intervention_points:
  pre_tool_call:
    policy_target: "$.tool_call.args"
    policy_target_kind: tool_args
    tool_name_from: "$.tool_call.name"
    policy:
      id: email_policy
tools:
  send_email:
    type: Tool
    id: send_email
    clearance: internal

package email_agent

verdict := {"decision": "deny", "reason": "external recipient blocked"} if {
  input.tool.name == "send_email"
  endswith(input.policy_target.value.to, "@external.example")
}

verdict := {"decision": "allow"} if {
  input.tool.name == "send_email"
  endswith(input.policy_target.value.to, "@company.example")
}

The example above is simple, but the direction is clear. A policy should not be a statement asking the model, but rather a contract that is evaluated on the same input shape just before tool execution.

7. Pitfalls

Key line: Failure usually occurs when “you create a policy but do not pass enough agent status and execution logs”

1. Trap: Only check the final answer.
   Prevention: Attach policy to pre_tool_call and post_tool_call to check before and after actual action. View:
   Recovery: Reconstruct tool call order and arguments from past incident logs, and add the same pattern as an ASSERT case.
2. Pitfall: No session state in policy input.
   Prevention: Sensitivity of previously read documents, user role, authorization status, previous tool results Put in snapshot:
   Recover: Add missing fields that the policy did not determine to the standard input schema.
3. Trap: Only deny, no escalate.
   Prevention: Gray zone requests are sent to the human approval queue rather than unconditionally blocked. Leave.
   Recovery: Collect normal operations blocked by false positives and separate approval policies and exception conditions.
4. Pitfall: Create a test set once and leave it alone.
   Prevention: Perform ASSERT evaluation when models, tools, policies, and customer data ranges change. Run again.
   Recovery: Reflect 10 actual failures in taxonomy and fix with regression test.
5. Pitfall: Keep policy in one framework.
   Prevention: Separate policy manifest and policy bundle from app code, Changes are reviewed as PRs.
   Repair: Separate common policies and runtime adapters to ensure the same results for other language services.

8. Strengths and Limitations

Key one-liners: The strength of ACS and ASSERT is that they are auditable operational standards; their limitation is that responsibility for maintaining policies and evaluations remains with the organization.

There are three strengths. First, the policy remains in the manifest rather than being scattered around the prompt or app code. Second, you can see before and after the tool runs, so you can catch failures such as “the final answer is okay, but you did something dangerous in the middle.” Third, because ASSERT turns requirements into tests and scorecards, regression verification is possible when changing models or adding tools.

The limitations are also clear. ACS is not an agent framework. Responsibility for running loops, running tools, and managing memory still lies with the host and framework. Also, a good snapshot is needed for the policy engine to make good decisions. If you don't pass on important context, your judgment will be poor even if you have standards.

ASSERT also does not automatically guarantee a correct answer. Judge model stability, test set quality, and policy expert review are required. Therefore, you should initially spend time reading failure traces and refining the taxonomy rather than the aggregate score.

Counterexample: If the agent only reads and summarizes the internal wiki and has no external writing permissions, introducing a full ACS may be excessive. In this case, it is better to start by reviewing data access logs, user consent, and output.

9. Points to study more deeply

Key single line: The next learning path is to look at MCP security principles, Agent Framework execution structure, ACS policy input, and ASSERT trace evaluation in that order.

• Microsoft Command Line - Introducing Agent Control Specification: Portable runtime governance for AI Agents (Confirmed date: 2026-07-05): You can check the concept of ACS's eight intervention points, standard input, and fail-closed processing. There is
• Microsoft Command Line - Turn specs into evals for any agent with ASSERT (Confirmation date: 2026-07-05): You can see the flow of changing natural language policies to taxonomy, test set, trace, and scorecard.
• Microsoft Agent Framework at BUILD 2026: Agent Harness, Hosted Agents, CodeAct, and more (Published date: 2026-06-03): Operating context of long-running agents, Hosted Agents, CodeAct, and Handoff orchestration. Provided.
• Microsoft Foundry - A Developer’s Guide to Managing Models, Cost and Quality (Verified date: 2026-07-05): Provides a perspective on model selection, evaluation, cost, and operation in one surface.
• Model Context Protocol Specification 2025-06-18 (Confirmation date: 2026-07-05): Check MCP’s user consent, data privacy, tool safety, and sampling control principles.

10. Action Checklist + Author's Perspective

Key line: The first completion criterion for agent governance is not “there is a policy document” but “the same failure is caught again in automatic evaluation”

• Have you tabulated all tools and write permissions that the agent can call
• Does one or more high-risk tools have the pre_tool_call policy attached?
• Is post_tool_call checked before the tool result enters the model context
• Does the policy input snapshot contain user roles, approval status, and previous sensitive data access records
• Do you distinguish between allow, warn, deny, and escalate and leave them visible to the operator
• Are normal, borderline, and malicious scenarios executed in every release using ASSERT or equivalent
• Are actual failures or false positive cases reflected in taxonomy and regression tests
• Does policy manifest change leave a record of PR review, approval, and rollback

Definition of Done: One high-risk tool is blocked before execution with an ACS-type policy, and normal, false positive, and malicious cases of the same policy leave traces and rationales in ASSERT-type regression evaluation. If policy changes can be audited with PR, the first introduction is Completed.

Author's Perspective: I see ACS and ASSERT as broader signals than “Microsoft ecosystem capabilities”. As soon as agents take on real action, governance cannot reside within model documentation or system prompts. Policies should be independent artifacts, evaluations should look at execution logs, and failures should be relegated to the next test. It would be better for teams creating agent platforms to quickly adopt this direction.