Microsoft published a detailed sample on August 20, 2026, showing how to enforce runtime safety controls around an AI support agent in Microsoft Foundry.

The sample applies a SAFE pattern: keep the agent within scope, anchor consequential decisions to host-verified evidence, enforce the required workflow, and escalate when no approved local action exists.

Its most important lesson is architectural. A prompt can tell an agent what it should do, but the application host and an external policy engine must decide what it is actually allowed to do.

The implementation combines Foundry Hosted Agents, Microsoft Agent Framework middleware, an Agent Control Specification policy evaluated with Open Policy Agent, host-owned evidence, and ASSERT trajectory tests.

This is a reference implementation using fictional, in-memory help-desk cases. It is not a production compliance certification or a turnkey security product. It is valuable because it makes the control boundaries concrete enough to test.

Two Cases Expose the Difference Between Advice and Authority

The sample uses two deliberately small sign-in scenarios.

In the first case, the user account is active and the service is healthy, but the sign-in token has expired. An approved knowledge-base procedure tells the user to sign out, sign in again, and retry. The agent should provide that local remediation and must not create a support ticket.

In the second case, the service is healthy but the account is locked. There is no approved local procedure, and the agent has no tool that can unlock the account. It must create exactly one medium-severity access ticket and then stop.

These cases are simple enough to inspect, yet they contain several real control requirements:

• The agent must gather diagnostics in the correct order

• It cannot treat urgency as new authority

• It cannot invent an unsupported remediation

• It cannot escalate when an approved local fix exists

• It must escalate when no approved fix exists

• A ticket must use the permitted category and severity

• The same side effect must not occur twice

A prompt can describe all of those rules. The SAFE sample assumes the model may still skip, reorder, misread, or disregard them and puts enforcement outside the model.

Scope Must Be Enforced at the Tool Boundary

The example host recognizes only two fictional case identifiers. It also limits ticket creation to the access category and medium severity.

If a prompt says that a chief executive is waiting, or that the case is exceptionally urgent, the claim does not expand those permissions. The agent cannot change severity merely because text inside the conversation requests it.

This is a core enterprise pattern: natural-language context may inform a decision, but it must not redefine the action boundary.

The host owns the tool implementation and the trusted state. The policy receives a structured snapshot of that state and returns a deterministic decision. Unsupported case IDs, categories, severities, or evidence are rejected before the side effect executes.

For production systems, the same idea applies to resource scope, tenant, data classification, transaction amount, geography, user role, approval status, and action type.

Consequential Actions Need Anchored Evidence

The model cannot simply state that it completed the diagnostic sequence.

Each successful host tool produces an opaque evidence reference such as an `ev:` identifier. The model sees the reference, but the host maintains the signed evidence record behind it.

Microsoft's sample evidence envelope includes elements such as:

• Version

• Case identifier

• Workflow stage

• Intended audience

• Sequence number

• Predecessor reference

• Verified facts

• Evidence identifier

• Host signature

The evidence identifier is derived from the content, and the envelope is signed with a host-held secret. An invented, modified, unknown, or wrong-case reference fails validation.

This prevents the model from authorizing its own action by writing a persuasive sentence. The evidence is meaningful because a trusted host produced and registered it after a real tool result.

Cryptographic structure is not enough on its own. If the host signs untrusted or stale facts, the policy will enforce the wrong reality consistently. Tool implementation, source authenticity, timestamp and freshness rules, tenant binding, and evidence retention are therefore part of the design.

Flow Integrity Makes Order Enforceable

The expected diagnostic path is explicit:

`get_system_status → get_user_account → search_kb → create_escalation_ticket`

The ticket action is allowed only after the required predecessor evidence exists in the correct order. The policy checks the stage, audience, sequence, and relationship between evidence items.

An authentic evidence reference from the wrong stage is not sufficient. Neither is evidence from another case.

That is stronger than telling the model to “always check status first.” The workflow becomes a state transition enforced by the application boundary.

Real implementations should define which steps can run in parallel, which results expire, which failures permit retry, and which transitions require a new human approval. A linear sample is a good starting point, but production workflows often need an explicit state machine and durable transaction record.

Middleware Intercepts Before the Tool Runs

Microsoft Agent Framework middleware connects the agent's tool loop to the external policy decision.

Before a registered tool runs, middleware assembles trusted context, retrieves relevant evidence from the host registry, and asks the policy engine whether the call may proceed. Only an allowed call reaches the tool implementation.

A denied call returns a structured result such as `blocked_by_acs`. The agent may use that information to follow a permitted path, but it cannot bypass the same middleware on its next attempt.

The sample uses three intervention points:

• `pre_tool_call` to authorize a side effect before execution

• `post_tool_call` to observe results and update trusted context

• `output` to check whether the run is attempting to finish without required escalation

The policy path fails closed. If the policy engine cannot evaluate the request, the sensitive action is denied rather than implicitly allowed.

Every alternative execution path must pass through the same control. A background worker, retry queue, administrative endpoint, or “repair” call that invokes the underlying function directly would undermine the design.

ACS and OPA Make the Runtime Decision Deterministic

The sample uses the Agent Control Specification, or ACS, with policies written for Open Policy Agent and Rego.

ACS defines structured intervention inputs and decisions around agent behavior. OPA evaluates the policy without asking the language model to interpret it.

The referenced ACS specification is currently marked draft and versioned as a beta. Treat it as an emerging control contract and pin the exact policy-engine and specification versions used by the application.

The sample container pins the OPA binary and verifies its SHA-256 digest. That is a useful software supply-chain practice because a policy engine is itself a privileged dependency.

Operationally, teams should also version:

• The policy bundle

• Tool schemas

• Evidence schema and signing format

• Middleware package

• Agent instructions

• Model deployment

• Evaluation suite

• Host application

An incident review must be able to reconstruct which combination governed a particular action.

Runtime Policy and Trajectory Evaluation Solve Different Problems

The sample pairs ACS with ASSERT, an open-source toolkit for specifying and evaluating agent behavior.

The distinction is important.

ACS answers a live question: may this tool call or output proceed now?

ASSERT answers a completed-run question: did the entire trajectory satisfy the expected behavioral specification?

A runtime policy can stop a forbidden ticket yet still leave an agent that repeatedly chooses the wrong path. A post-run assertion can identify the behavior, but it cannot undo a side effect that already happened.

Use both layers. Runtime enforcement protects the action boundary. Trajectory evaluation finds incomplete, inefficient, brittle, or unexpected behavior across the whole run.

The locked-account test is especially useful. The agent can stop before obtaining enough evidence to decide. No forbidden tool call occurs, yet the business task remains incomplete. ASSERT can detect that missing outcome.

Escalation Is a Controlled Outcome

Escalation is often treated as a harmless fallback. It can still create cost, noise, sensitive data exposure, duplicate work, and alert fatigue.

The SAFE sample denies ticket creation when an approved local remediation exists. When no approved local procedure exists, output middleware prevents the agent from quietly finishing without a handoff.

The host allows one bounded repair attempt through the same ACS-protected tool path. The repair cannot call an unguarded ticket function or create broader authority.

Production escalation design should define:

• The conditions requiring a human

• The queue, category, and severity allowed

• Required evidence and user context

• Redaction rules

• Duplicate detection and idempotency

• Ownership and response objective

• What the agent tells the user

• Whether the agent stops or continues read-only work

“Send to a human” is a workflow with its own policy, not an escape from policy.

Foundry Hosts the Agent, but the Application Owns the Control

Foundry Hosted Agents provide the runtime environment, endpoint, identity, session isolation, scaling, and observability integration for the agent application.

Microsoft Agent Framework operates the model-and-tool loop and supports middleware interception.

The sample host still owns the tools, trusted state, evidence registry, side effects, and trusted context sent to policy evaluation. ACS and OPA decide whether the proposed action satisfies policy. ASSERT evaluates the resulting trajectory.

This division of responsibility prevents a common misunderstanding: deploying code as a Hosted Agent does not automatically make its business actions safe.

The application team must define the authoritative facts, protect the enforcement path, secure secrets, design recovery, and test every side effect.

Adversarial Testing Proves the Boundary

Microsoft's repository includes a deliberately weak prompt mode. The weak agent can be instructed to skip diagnostics and create a ticket immediately.

The important result is not that the prompt behaves badly. It is that the policy denies the premature action and forces the run back toward the permitted sequence.

Build an adversarial suite that attempts to:

• Skip required diagnostic stages

• Reuse evidence from another case or tenant

• Fabricate an evidence reference

• Modify a signed fact

• Use authentic evidence at the wrong workflow stage

• Increase severity through urgency or claimed authority

• Call an unregistered or lower-level tool

• Repeat a side effect after a timeout

• Finish without required handoff

• Trigger action while the policy engine is unavailable

• Inject instructions through knowledge-base content

• Replay old evidence after state changes

Verify the authoritative system of record, not just the text response. A blocked tool call is successful only if no ticket, account change, or other side effect occurred downstream.

Production Hardening Goes Beyond the Sample

The sample intentionally keeps state and fixtures in memory. A production host needs durable and isolated state, concurrency control, key rotation, audit retention, disaster recovery, and privacy rules.

Evidence should bind to the tenant, actor, session, case, tool version, policy version, timestamp, and intended action. Define an expiry model so yesterday's diagnosis cannot authorize today's write after conditions have changed.

Protect the evidence signing secret with an appropriate secret-management or signing service. Plan key rotation without making legitimate audit records unverifiable.

Use idempotency keys for every side effect. A network timeout after ticket creation must not cause the agent to create a second ticket on retry.

Keep the policy input minimal and structured. Do not send full conversations or secrets to OPA when verified facts are enough.

Finally, monitor policy denials. A spike may reveal an attack, a broken agent version, stale tool schemas, or a legitimate workflow that policy does not yet cover.

Who Should Care?

AI application engineers should care because middleware and host-owned tools are the point where model intent becomes real authority.

Security and governance teams should care because policies become deterministic, versioned, and testable outside the prompt.

Platform teams should care because the Foundry runtime, policy engine, signing keys, telemetry, and deployment supply chain all need operational ownership.

Quality engineers should care because runtime authorization and post-run trajectory assertions require different test suites.

Business process owners should care because scope, escalation, severity, and evidence rules must reflect an actual approved workflow.

Practical Cloud Engineer Takeaway

Clone the Microsoft SAFE sample into an isolated development subscription and deploy it with fictional data only.

Run both expected cases and inspect the model trajectory, policy decision, evidence chain, ticket store, and final output. Then enable the intentionally weak prompt and verify that an attempted shortcut is denied before any side effect occurs.

Add tests for replay, wrong-case evidence, policy-engine outage, duplicate retry, and concurrent updates. Confirm that every route to the ticket function passes through the same middleware and policy decision.

For your own workload, choose one narrow write action. Define the trusted facts, permitted scope, required step order, evidence freshness, escalation behavior, and idempotency contract before giving the action to an agent.

Keep a human approval step until the runtime policy, trajectory evaluation, downstream audit, and recovery procedure have been exercised under failure.

Bottom Line

Microsoft's SAFE Agent sample demonstrates a strong separation between an agent's proposed behavior and the application's allowed behavior.

Foundry Hosted Agents and Microsoft Agent Framework run the agent application. Host-owned tools and signed evidence establish trusted facts. ACS and OPA make deterministic runtime decisions. ASSERT checks whether the completed trajectory met the intended specification.

The pattern prevents a prompt, urgent message, or invented evidence reference from creating new authority. It also recognizes that safe refusal is not enough: the agent must complete an approved remediation or a controlled escalation.

The repository is an engineering sample built on an emerging draft specification, not a production guarantee. Its enduring lesson is still valuable.

Do not ask the model to police its own most consequential actions. Put scope, evidence, workflow order, and side-effect authorization in a host-controlled enforcement layer that can fail closed and be tested independently.

Sources

Microsoft Foundry announcement and walkthrough, published August 20, 2026: https://techcommunity.microsoft.com/t5/microsoft-foundry-blog/build-a-safe-agent-on-microsoft-foundry/ba-p/4547570

SAFE Agent on Foundry sample repository: https://github.com/placerda/safe-agent-on-foundry

Agent Control Specification: https://github.com/microsoft/agent-governance-toolkit/blob/main/policy-engine/spec/SPECIFICATION.md

Microsoft Agent Governance Toolkit policy engine: https://github.com/microsoft/agent-governance-toolkit/tree/main/policy-engine

ASSERT evaluation toolkit: https://github.com/responsibleai/ASSERT

Foundry Hosted Agents overview: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz