Microsoft links agent risk discovery to runtime enforcement

Microsoft has released run-assert-eval, an MIT-licensed VS Code skill that connects agent threat modeling, safety evaluation, runtime policy generation, and verification. The skill ships in the open-source ASSERT repository with examples spanning seven agent domains and 14 risk suites.

The workflow keeps the behavior definition, test cases, and automated judge fixed between baseline and governed runs. That controlled comparison helps teams determine whether a runtime policy reduced observed failures without causing the agent to reject legitimate requests.

Where handoffs weakened the evidence

Microsoft’s existing tools covered different parts of agent governance. ASSERT converts written requirements into executable evaluations, while Agent Control Specification, or ACS, defines policies and enforcement points for a running agent. Both depend on teams identifying the relevant risks before writing requirements.

After Build 2026, Microsoft observed teams assembling the workflow manually: Clarity identified threats, ASSERT measured failures, engineers wrote an ACS policy, and ASSERT evaluated the governed agent. Each handoff required custom integration. Changes to the test set or judge could also obscure whether a better result came from the policy or from a different evaluation.

A controlled loop from risk to policy

Starting from a plain-language description of an agent, run-assert-eval coordinates the following sequence:

1. Call the Clarity MCP server to identify plausible failure modes.
2. Let the team select which risks to evaluate.
3. Convert each selected risk into an ASSERT behavior, configuration, and test suite.
4. Run a baseline evaluation against the ungoverned agent.
5. Generate and validate an ACS runtime policy based on the observed failures.
6. Rerun the frozen evaluation against the governed agent.

The clarity_intake.py parser maps Clarity output to ASSERT configurations using only Python’s standard library. It converts severities into priorities and variants into stratification dimensions mechanically, removing an additional model judgment from that stage.

A billing agent exposes both failure modes

Microsoft demonstrates the workflow with a billing-support agent restricted to customer account ACME-1001. Clarity identified four failure modes, and the team selected the two rated critical: unverified high-risk actions and cross-customer data exposure.

Each selected risk produces one configuration, one behavior, and one suite. Variations within a risk become stratification dimensions informed by prior benchmarks, red-team studies, measurement instruments, and audits. The cited references include MLCommons AILuminate, the NIST AI Risk Management Framework, the OWASP Top 10 for LLM Applications, and frontier-lab policies.

ASSERT reports two rates so teams can track unsafe actions and excessive refusals independently:

• Impermissible behavior violated: The agent performed an action that the policy forbids.
• Permissible behavior violated: The agent rejected a request that the policy allows.

Separate reporting exposes universal-refusal behavior: an agent can reduce impermissible actions while also blocking valid requests.

Runtime checks cut cross-account exposure

The baseline cross-customer suite recorded a 30.0% impermissible violation rate, while the unverified-action suite recorded 6.3%. The generated ACS policy runs at the pre_tool_call and post_tool_call enforcement points and deterministically rejects tool calls whose account_id differs from the caller’s account.

The account check uses ordinary policy logic instead of asking a model to infer whether a call looks suspicious. That makes the enforcement decision reproducible and directly tied to the agent’s authorization boundary.

The governed evaluation configuration changes two lines from the baseline: the run label and the callable used to invoke the governed agent. The behavior, cases, and judge remain fixed.

Permissible violations fell to zero across all four splits in this evaluation, so the policy did not produce a measured increase in over-refusal. Cross-customer scenario violations also fell from 43.8% to zero.

Microsoft previously found 80% to 90% agreement between ASSERT’s automated judge and human reviewers, compared with roughly 90% agreement among human reviewers. Keeping that judge fixed strengthens the before-and-after comparison by removing one source of measurement variation.

Case counts and confidence intervals remain necessary when interpreting smaller movements, including the unverified scenario rate falling from 8.7% to 4.5%. Repeated runs can also reveal variance caused by nondeterministic agent behavior.

Why the loop helps developers

Run-assert-eval reduces the custom integration between threat modeling, evaluation, and runtime enforcement. It also leaves teams with reviewable artifacts at each stage: risk definitions, executable suites, baseline results, an ACS policy, and governed results.

1. Ground runtime controls in failures observed during evaluation.
2. Validate each mitigation with the test set and judge that identified the failure.
3. Track prohibited actions and valid-request refusals as separate metrics.
4. Use deterministic checks for concrete authorization rules such as account boundaries.

The same design supports regression testing after model, prompt, tool, or policy changes. Teams can retain the generated suites in version control and rerun them as part of release testing.

Start with the bundled agents

The skill, ASSERT, ACS, and Clarity are available under the MIT license. A team adopting the workflow needs:

• A plain-language description of the agent’s purpose, scope, tools, and authorization boundaries.
• An agent callable that ASSERT can invoke during evaluation.
• The Clarity MCP server for risk discovery.
• A reviewed set of risks to convert into behaviors and suites.
• A deployment path that supports ACS enforcement hooks.

The bundled examples cover billing support, Azure documentation Q&A, change control, science research, two travel-planner implementations, and two prompt-based clinical agents. Their directories include agent code and one evaluation configuration per risk, providing concrete structures for the 14 included suites.

Generated policies and evaluations should receive the same review, versioning, and deployment controls as application code. The frozen baseline and governed runs then provide an auditable record of the failure, mitigation, and measured result.