AI agents: how to prove a runtime policy works

A team can red-team its agent, discover that it reads the wrong account, and add an instruction telling it not to repeat the behavior. That sequence produces activity, but it still does not produce evidence. The original test may have changed, the judge may be different, the new prompt may reject legitimate requests, and the tool call may still happen before the model apologizes. Without a controlled comparison, the team knows it changed the system, not that it reduced risk.

Microsoft introduced run-assert-eval on September 24, 2026. The skill connects Clarity for failure-mode discovery, ASSERT for measurement, and Agent Control Specification for generating a policy enforced at runtime; it then repeats the evaluation. This article is published three Lima calendar days later. We did not run the example or reproduce its rates: the billing-agent figures are provider observations from that sample, not a transferable benchmark.

The loop starts before a policy is written. Clarity produces candidate risks and causal chains; a person chooses which ones matter. ASSERT turns each selected risk into a narrow behavior, generates scenarios, and runs the agent while recording responses and traces. ACS expresses the policy decision and the lifecycle point where it should apply. The second run preserves the definition, cases, and judge so the intervention is the deliberately changed variable.

The useful idea is not that one skill can automate everything. It is that a release artifact should link a concrete threat to reproducible measurement, an executable barrier, and an interpretable comparison. The ASSERT repository supports hosted models, callables, and OpenTelemetry-instrumented agents while writing local artifacts. It also states limits: an agent that is only a prompt over a hosted endpoint exposes no wrappable tools for ACS enforcement; in that case there is measurement, but not the same kind of control.

A label such as data security mixes too many questions. Does the agent read another account, expose a sensitive field, write without confirmation, or combine data across tenants? Each case needs different inputs, evidence, and a different barrier. Define one behavior per suite, with an explicit permissible boundary. That way, a violation rate identifies which contract failed rather than merely showing that something undesirable happened in a broad test.

Hypothetical example: a procurement agent may inspect orders for the active tenant and propose a correction, but it may not change a supplier or bank account without approval. Separate cross-tenant reading, supplier modification, and execution without approval. Stratify each suite by direct access, authority pretext, multi-turn drift, and incomplete tool response. Variety belongs inside one behavior; it should not turn three independent failures into an opaque metric.

Version the definition, cases, stratification factors, judge, its model and configuration, mocked tools, and the agent commit. Preserve baseline results and every conversation identifier. If you regenerate cases or replace the judge during the second run, you get another measurement rather than a clean counterfactual. You can expand coverage later, but first you need to know what changed under the same instrument.

Freezing does not mean believing the instrument is perfect. Have people who understand the policy review a sample, document disagreements, and verify that permissible cases truly should be allowed. Run repetitions when the model or judge is variable, and report counts alongside percentages. Improving two cases in a small sample can be useful for debugging, but it does not by itself justify a general safety claim.

A system instruction tries to influence the model's decision; a runtime policy decides whether the action may execute. For the procurement example, the control should inspect tenant, operation, resource, and approval before calling the writing tool. If a response could also leak data retrieved by mistake, add a post-call control that prevents the result from returning to context. The defense should live at the trust boundary, not only in persuasive language.

Choose the intervention point according to the harm's semantics: before a tool to prevent the effect, after it to contain a response, when persisting memory to protect data, or when delegating to limit capability. Keep the decision deterministic when it depends on identity, roles, or IDs. Microsoft's announcement shows Rego and eight ACS interception points, but the principle is product-independent: the orchestrator should deny, record, and explain an action without asking the same model to audit itself.

An agent that refuses everything can look safe if the only metric counts forbidden actions. ASSERT therefore separates impermissible-behavior violations from permissible-behavior violations. The first asks whether the agent did what it should not; the second asks whether it failed to help when it could. A release needs thresholds for both. Reducing leaks by blocking every valid query from the correct tenant is not an acceptable fix.

Also add operational metrics the policy may degrade: task latency, retries, escalations, cost, and accepted-completion rate. Do not combine everything into one score that hides what worsened. Define in advance what constitutes a blocking regression and what requires observation. Preserve failed examples from both sides, because a green average does not reveal whether a critical path remains open or the application now penalizes a legitimate segment.

The pipeline should produce a traceable package: selected threat, behavior contract, frozen dataset, baseline, reviewed policy, governed run, delta, and exceptions. Tie that package to code and configuration versions. In CI, prevent a change from overwriting the approved baseline; create a new candidate and require review to promote it. Artifacts may remain local or live in controlled storage, but they must outlast the chat in which the agent generated them.

Do not let the same automation author the policy, change the agent, choose the acceptable result, and approve production without separation of duties. A person should confirm the risk and permissible boundary; a separate rule should control high-impact changes. Start in shadow mode or with simulated tools, then use a limited cohort and a tested kill switch. Runtime policy reduces one class of failure; it does not replace least-privilege identity, sandboxing, observability, or incident response.

An approved policy can become stale when tools, schemas, permissions, prompts, or models change. Trigger the affected suite whenever the contract changes and periodically run an exploratory sweep with new cases to discover uncovered paths. Keep the frozen regression set separate from the exploratory set: the first preserves comparability; the second looks for failures you do not yet know. When one appears, turn it into an atomic behavior and repeat the cycle.

The decision for a CTO is not to install this skill immediately. It is to adopt the evidence standard: the same risk, the same instrument, one reviewable intervention, and separate safety and usefulness outcomes. If your agent does not allow controls at its boundaries, that finding may require redesigning the runtime before expanding autonomy. Wasyra can help turn a real workflow into a pilot with permissions, golden cases, and release gates; that custom service is distinct from the Agents product at agents.wasyra.com.