Foundry Agent Governance: Assign Authority Before Expanding Autonomy

An enterprise may know who owns its customer database and still struggle to name the owner of an agent that reads it, calls a pricing service, and prepares a customer offer. The agent crosses several teams’ boundaries in one task. Governance has to connect those responsibilities.

The first control I would establish is a clear answer to three questions: who owns the outcome, whose authority the agent uses, and who can stop its actions. A product inventory helps, but an entry in a catalogue is not an operating agreement.

Production hosting changes the operating obligation

Microsoft’s July 9 Foundry announcement identifies hosted agents as generally available alongside new models and deployment capabilities. Microsoft also reports that more than 100,000 organizations are building on Foundry. That is a vendor-reported adoption figure, not a measure of successful deployments or proof of governance maturity.

A managed hosting milestone can remove infrastructure work. It does not remove the application owner’s responsibility for incorrect quotes, unauthorized access, or unfinished transactions. Review the agent as a business application with delegated authority.

The April developer announcement and June hosted-agent update provide background on runtimes, identity, and controls. Read feature-specific maturity and deployment requirements rather than carrying a general GA label across every related capability.

Define the business action before the tool

Consider a hypothetical sales-support agent that assembles a renewal proposal. Its read operations retrieve contract terms and approved price information. Its write operations might save an internal draft or submit an offer for review. Sending the offer to the customer is a separate business action.

These operations have different consequences and should have separate authorization rules. A broad tool called “manage renewal” makes it difficult to distinguish harmless preparation from an external commitment.

Create narrow operations with explicit targets and validated arguments. The application should resolve the customer account from authenticated context and verified records. An instruction embedded in a document must not select a different tenant, customer, recipient, or authority.

Establish an owner for each control

The business owner defines permitted outcomes, escalation rules, and materiality. The application owner implements transaction validation and recovery. Identity teams establish access and credential lifecycle. Platform teams own deployment, monitoring, and configuration distribution.

Security teams should assess abuse paths, but they should not become the default owner of every unresolved application decision. A policy requiring approval is ineffective unless an application team implements it and a business team supplies authorized reviewers.

Record who can change prompts, tools, model deployments, and policy configuration. Treat those changes as application releases. A small configuration update can increase authority without changing the repository’s main code path.

Use adversarial research to improve test design

The 2024 AgentDojo study created 97 realistic tasks and 629 security test cases for agents operating on untrusted tool data. Those counts describe benchmark coverage, not the probability that a Foundry agent will be compromised. The study’s value here is its stateful testing approach.

A renewal agent should encounter a supplier document containing instructions to send information elsewhere, a tool response claiming that approval is unnecessary, and a retrieved note that conflicts with current policy. Score whether the agent completes the legitimate task and whether the application blocks prohibited actions.

Microsoft’s AI Red Teaming Agent announcement describes preview testing for risks including sensitive-data leakage and prohibited actions. Treat such tools as part of a wider evaluation programme. Confirm that the chosen tests reflect the actual tools and permissions of the application.

Keep policy enforcement outside model persuasion

Prompts should explain expected behaviour. Deterministic controls should enforce resource scope, recipient restrictions, financial bounds, and required approvals. A model-generated justification must not grant an exception.

Where a tool accepts a record identifier, validate that the caller may act on that record. Where it accepts an external destination, restrict that destination according to application policy. These checks remain necessary even when the agent usually chooses correct parameters.

Do not give every tool the same credential. Narrow identities make the effect of a compromised component easier to contain and investigate. Confirm the selected hosting path’s actual identity behaviour before assuming a deployment supplies the intended separation.

Plan for changes in authority

An agent that begins with read-only access can accumulate privileges through normal product development. Review new tools against the original task boundary. Adding an API may create a new disclosure route or business commitment.

Maintain an inventory of active agent versions, tool definitions, policy versions, and approved deployment destinations. Include dependencies outside Foundry where they participate in the workflow. The governance boundary should follow the business action across services.

Test removal of access as well as addition. A revoked role or disabled connection should lead to a clear failure or escalation. It should not cause the agent to search for a broader credential or alternate route.

Make stopping and recovery operational

Define how to stop new work, prevent pending writes, and reconcile actions already submitted. A deployment rollback does not reverse an offer that was sent or a customer record that was changed.

The runbook should identify the authoritative transaction log and the operator who can determine what happened. Preserve operation identifiers so incident responders can distinguish an attempted action from a completed one.

Exercise this process with a controlled failure. The test should show how unfinished work is located, how the customer impact is assessed, and how service resumes. Record the evidence rather than accepting a diagram as proof.

Give leaders a useful governance report

Report agents by business owner and permitted action scope. Include failed authorization tests, overdue remediation, unresolved transaction outcomes, and changes that increased autonomy. Separate these from general traffic and token usage.

For the renewal example, pair technical measures with incorrectly scoped proposals, review corrections, and confirmed customer impact. A dashboard with many successful model responses can still conceal a serious authority problem.

Begin expansion only when the current boundary is understood and tested. Foundry can provide useful hosting and governance building blocks. Enterprise control comes from connecting those capabilities to named owners, enforceable authority, and evidence about the resulting business actions.

References

Microsoft: July 9, 2026 Foundry announcement

Microsoft: Developer journey and identity foundations, April 22, 2026

Microsoft: Hosted-agent controls, June 2, 2026

Microsoft: AI Red Teaming Agent, November 2025

Debenedetti and colleagues: AgentDojo, 2024

Leave a Reply