The Azure AI agent decisions you cannot undo

Six networking traps, a disaster recovery plan that is reconstruction rather than restoration, and a five-boundary threat model that only holds if you got the first decision right.

You reach for the threat model and discover the mitigation you need is a decision you made wrong three months ago, when you created the account. Six networking traps, a disaster recovery plan that is reconstruction rather than restoration, and a five-boundary threat model that only holds if you got the first decision right.

In this article: You will learn why Microsoft Foundry networking is the section where most Azure agent deployments stall, which six hardening decisions are create-time only and therefore unfixable without recreating the account, what Foundry Agent Service disaster recovery actually gives you back (less than you think), and how a five-boundary agent threat model assembles from controls that each leave a different gap. By the end you will be able to sequence a production Foundry deployment in the order that keeps your options open.

There is a moment in every enterprise agent project where someone finally writes the threat model. It usually happens late, after the demo lands and before the security review, and it usually goes badly. Not because the threat model is wrong. Because halfway through writing it, the team discovers that the mitigation they want is a decision they already made, three months ago, in a Bicep file, on a day when nobody was thinking about prompt injection.

Production hardening on Microsoft Foundry has that shape. Most of the platform is reversible with a redeploy. A specific handful of it is not reversible at all, and the not-reversible parts are exactly the ones a threat model depends on.

This article therefore runs in the order a team actually has to work, not the order it is interesting to read. Provisioning first, because the shape of your deployment constrains everything after it. Then networking, because that is where the one-way doors live. Then keys and recovery, because those are what you owe the compliance reviewer. And only then the threat model, which is where all the earlier decisions get their bill.

Provisioning and deployment run on different clocks

Infrastructure as code stands up the durable resources. The agent lifecycle runs against them. Conflating the two is how a team ends up redeploying a Foundry account to change a prompt.

There are two clocks. The slow one moves in weeks: the Foundry account, its projects, the Cosmos DB and Storage and AI Search behind them, the virtual network, the container registry, Application Insights, Key Vault. Bicep or Terraform owns that clock. The fast one moves in hours: a new agent version, a prompt change, a toolbox promotion, a guardrail policy edit. azd and the REST API own that one.

Keep them apart in the repository and the split enforces itself. The infra/ directory that azd ai agent init scaffolds is standard azd Bicep that you own, and your changes persist across deployments. Put the durable resources there, and let azure.yaml carry only what changes at agent speed. The moment a prompt edit requires an azd provision, the split has broken.

The resource template documentation names four security controls worth building into a scaffolded template rather than bolting on later: private endpoints, customer-managed keys, role-based access control, and custom Azure Policy definitions for a security baseline across every Foundry resource the organization creates. Three of those four come back later in this article as things that are painful to add afterward.

Capability hosts decide where your agent's data actually lives

By default, your agent's conversations sit in Microsoft-managed storage. Moving them into your own subscription means a pair of sub-resources with a create-once lifecycle and no update path.

A capability host is a sub-resource configured at both the Foundry account scope and the project scope, and it tells Agent Service where to store and process agent data: conversation history, file uploads, and vector stores. Create none and Agent Service uses Microsoft-managed resources for all three, which is basic agent setup. Create both and your own resources hold the data, which is standard agent setup.

The mapping is three connections to three Azure services:

Project capability host property	What it stores	Azure resource
threadStorageConnections	Agent definitions and conversation history	Azure Cosmos DB
vectorStoreConnections	Vector storage for retrieval and search	Azure AI Search
storageConnections	File uploads and blob storage	Azure Storage
aiServicesConnections (optional)	Your own model deployments	Azure OpenAI

Each referenced connection needs four properties populated or Agent Service cannot resolve the resource at runtime: authType, category, target (the service endpoint URL, not the resource ID), and metadata.ResourceId. The last of those four is the trap, because a connection missing it looks correct in the portal and fails at runtime.

Four constraints decide how you script this, and every one of them is create-once:

• One capability host per scope. A second one with a different name at the same scope returns 409 Conflict.
• No updates. Changing configuration means deleting the host and recreating it, and deleting one cuts every agent that depends on it off from its files, conversations, and vector stores.
• The account host is a prerequisite. You cannot create a project capability host without an account-level one.
• No inheritance. Connections defined at the account level are inherited by new projects; the capability host configuration is not. Agent Service reads the project host, and if a connection is not named there, it is not used, whatever the account host says.

Capability hosts are managed through the REST API only. SDK support is not available. Both calls are ARM PUT operations:

az rest --method PUT \
  --url "https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}/projects/{project}/capabilityHosts/{name}?api-version=2025-06-01" \
  --body '{
    "properties": {
      "capabilityHostKind": "Agents",
      "threadStorageConnections": ["desk-cosmos-connection"],
      "vectorStoreConnections":  ["desk-search-connection"],
      "storageConnections":      ["desk-storage-connection"]
    }
  }'

Know the idempotency rules before you put that in a pipeline. Same name plus same configuration returns the existing resource with 200 OK, same name plus different configuration returns 400 Bad Request, and a different name returns 409 Conflict. A rerun is safe. A rename is not.

One sizing note that bites teams on the first deploy: the Cosmos DB account needs a total throughput limit of at least 3000 RU/s, because standard setup provisions five containers at 1000 RU/s each. Three of those five belong to the classic runtime. The new Foundry Agent Service uses agent-definitions-v1 and run-state-v1 and does not touch the older three. Provision for all five, read only the new two.

This section earns its length for one reason. Capability hosts are the single lever that decides whether Foundry's most-cited lock-in, the managed conversation store, is Microsoft's problem or yours. Point them at your own Cosmos DB and the conversation record lives in a database you can query, back up, and export with ordinary tools. What does not transfer is the schema and the semantics, which stay Foundry's. And changing your mind later means deleting a capability host and disconnecting every agent under it.

Versions are where rollback lives

Every runtime-affecting change creates a new agent version, and an agent endpoint routes to exactly one of them. Rollback is a single merge patch:

# ①
az rest --method PATCH \
  --url "${BASE_URL}/agents/${AGENT_NAME}?api-version=${API_VERSION}" \
  --resource "${RESOURCE}" \
  --headers "Content-Type=application/merge-patch+json" \
  --body '{
    "agent_endpoint": {
      "version_selector": {
        "version_selection_rules": [
          {"agent_version": "7", "traffic_percentage": 100, "type": "FixedRatio"}
        ]
      },
      "protocol_configuration": {"responses": {}}
    }
  }'  # ②

① The call is a JSON merge patch, declared by the application/merge-patch+json content type, so the body carries only the fields being changed and the rest of the agent definition is left alone. The agent is addressed by name and the api-version pins the contract, which is why this same command is safe to keep in a runbook.

② The whole routing decision is the one FixedRatio rule inside version_selection_rules. Change agent_version to the previous number and rerun, and that is the rollback. The protocol_configuration entry rides along in the same patch, naming the Responses protocol the endpoint serves.

Note: The full extracted listing at code/azure-foundry-hyperscaler/part-17-shipping-and-hardening/listings/01-pin-agent-version.sh shows the environment variables, the token resource, and the version override elided here.

It is fast, and it is all-or-nothing. Traffic splitting between agent versions is not supported: configure one FixedRatio rule with traffic_percentage set to 100, even though version_selection_rules is an array. An array that accepts exactly one element reads like a canary feature that is coming. Do not design a progressive rollout on it today.

Draft versions are the substitute, and they are preview with a subscription gate. A draft gets a draft-{timestamp} identifier rather than an incremented integer, stays out of default version listings unless you pass include_drafts=true, is never resolved as the latest version, and cannot be a traffic-routing target at all [PERISHABLE: preview, checked September 2026]. Note the failure mode the documentation states plainly: until draft creation is enabled for your subscription, a request with draft set to true creates a normal release version instead. A silent promotion to production is an expensive way to learn that a preview flag was not enabled.

Four diagnostics are worth knowing by name before you need them, and worth wiring into CI rather than saving for an incident:

• azd ai agent doctor runs local and remote checks and changes no state. Its exit codes are stable enough for CI: 0 when at least one check passed and none failed, 1 on any failure, and 2 when everything was skipped. A doctor step before azd up fails fast when the runner is missing a role assignment.
• azd ai inspector launch serves a browser UI on http://localhost:8087 that connects to a local agent on http://localhost:8088 and replays a specific run when you pass --conversation-id and --session-id. It targets only a local agent and does not proxy a deployed one.
• azd ai agent monitor streams production logs, with --type system for container starts, crashes, and restarts. Four patterns cover most incidents: Listening on 0.0.0.0:8088 means the agent started, AuthenticationError is a credential or RBAC problem, ModelNotFound means the deployment name does not match azure.yaml, and a container restart in system events is a crash loop.
• azd ai agent eval run resolves eval.yaml and does not regenerate datasets as a side effect, so azd ai agent eval generate has to have run first against a deployed agent.

One CI step is easy to miss and not optional: azd ext install microsoft.foundry has to run on the runner, because the runner image does not carry the extension. And pass --no-prompt on every azd ai command, because without it a missing required value hangs the job until the timeout, which is the worst possible CI failure: it costs runner minutes and tells you nothing.

Secrets stay out of both the image and the manifest. Values baked into a Dockerfile are fixed at build time and visible to anyone with access to the image, and azure.yaml is in your repository. The documented path is a Foundry project connection plus a ${{connections.<name>.credentials.<field>}} placeholder that the platform resolves at runtime.

Microsoft Foundry networking, where deployments actually stall

A networking configuration is two decisions, egress and ingress. The egress decision determines the ingress options, and you make the egress decision when you create the account.

The default is fully public on both sides. The Foundry endpoint is reachable over the public internet by any caller with a valid credential and the URL, agents reach your data over public networking and can reach only internet-accessible endpoints, and agent state uses Microsoft-managed storage. Nothing is private until you choose an option.

Bring-your-own means a dedicated subnet delegated to Microsoft.App/environments that cannot be shared by more than one Foundry resource, private endpoints and private DNS zones for the Foundry account and every data resource you bring, and the Foundry resource in the same region as the virtual network.

Subnet sizing is the part teams get wrong by exactly one order of magnitude. Hosted agents run in microVMs attached to the delegated subnet, each with its own network interface, so each consumes an address, and new revisions consume addresses temporarily during rollout when old and new run in parallel. Concurrent sessions and usable subnet IPs map 1:1 by default, and an Azure support request can raise that to 1:10. A /27 is the supported minimum and gives roughly twenty concurrent sessions. A /24 is the production recommendation and gives roughly 250. Stay below 80 percent subnet utilization, because platform upgrades run old and new infrastructure in parallel.

Two more numbers belong in a capacity document. A Foundry instance supports approximately 250 projects at low traffic and as few as about 25 under heavy traffic with many concurrent sessions, and when addresses are exhausted, new project provisioning fails.

And you get no warning. The Azure portal does not expose IP utilization for delegated subnets, and the platform does not proactively tell you when capacity is running low. The leading indicators are HTTP 5xx errors from the data proxy and HTTP 429 with code subnet_exhausted on session creation or resume. Alert on both, because the first symptom otherwise is a failed deploy.

The managed virtual network is the other door, and it trades control for not having to run a network. Microsoft creates the network in its own tenant, and three isolation modes govern outbound traffic: allow internet outbound, allow only approved outbound (service tags, private endpoints, and optional FQDN rules on ports 80 and 443 enforced by a managed Azure Firewall), and disabled. Managed private endpoints do not create customer-visible network interfaces, so nothing about them appears in your subscription. The Azure portal cannot create a managed network at all; the documented paths are az rest, the az cognitiveservices account managed-network command group, and the Bicep or Terraform templates. Assign the Foundry account's managed identity the Azure AI Enterprise Network Connection Approver role, role ID b556d68e-0be0-4f35-a333-ad7ee1ce17ea. Without that assignment, the required private endpoints are never approved.

Six traps, and five of them are one-way doors

These decisions are expensive to discover late because they cannot be undone without recreating the Foundry account.

1. Virtual network injection is create-time only. Set the virtual network configuration when you create the Foundry account. Network injection is part of the create-resource flow and cannot be added to an existing account. The configuration takes effect when you create the first hosted agent and cannot be changed afterward. The network isolation documentation says the same thing from the other direction: you cannot change a delegated subnet to a new one, and you cannot take an existing Foundry deployment and add outbound virtual network injection, so you must redeploy. The useMicrosoftManagedNetwork and subnetArmId fields sit inside networkInjections on the account create body, and all of them are create-time.

2. Managed network isolation cannot be turned off. You cannot disable managed virtual network isolation after enabling it, there is no upgrade path from a custom virtual network setup, and a Foundry resource redeployment is required to change your mind. The isolation modes are one-way too: allow-internet-outbound cannot go back to disabled, and allow-only-approved-outbound cannot go back to allow-internet-outbound. The firewall SKU is immutable after deployment, you cannot bring your own firewall, and you cannot share one managed firewall across Foundry accounts.

3. Private endpoints to your data resources are not auto-created. Two documentation pages carry the same note in capital letters: private endpoints to Azure AI Search, Azure Storage, and Azure Cosmos DB are not created when you deploy your Foundry resource, and you create them separately on each resource. A deployment that provisions cleanly and then times out loading the agent pages is usually this, and the documented symptom is exactly that: a 60-second timeout on the Agent pages means the project cannot reach Cosmos DB.

4. Some tools reach the public internet anyway, and some do not work at all. Grounding with Bing, web search, and SharePoint grounding are supported behind network isolation and communicate over public endpoints. The documentation states plainly that this may not meet a requirement that all traffic stay private. Four tools are not supported behind network isolation at all: Logic Apps, browser automation, computer use, and image generation. Fabric Data Agent is unsupported and Fabric IQ is partial. Code interpreter is supported, but in a private bring-your-own configuration it works only in scenarios without file uploads or downloads, with an SDK-only workaround the portal does not offer.

5. Publishing to Teams from the portal stops working. Publishing from the Foundry portal is not supported for projects that disable public network access, and the portal returns 403. Teams and Microsoft 365 Copilot are still reachable, through the REST API with the source-IP-filtered public Activity protocol route enabled by enable_m365_public_endpoint, with requests required to originate from Azure Bot Service or Microsoft 365 source ranges. Plan for it before you promise a demo, because the portal button is the thing everyone expects to work.

6. The agent endpoint itself is not private. This is the trap that reframes the other five. The azd networking documentation is explicit: the deployed agent endpoint URL stays publicly addressable in this preview, and per-user isolation is done by identity rather than network privacy [PERISHABLE: preview, checked September 2026]. You can put a private endpoint on the Foundry account, the registry, Application Insights, and Storage. The agent's own endpoint is a platform-side feature that does not exist yet. Every isolation argument above is about egress and about the resources behind the agent, not about who can reach the agent.

Three more constraints cut across the rest. A private Azure Container Registry with public network access disabled is supported only for Foundry projects created after June 25, 2026; projects created before that date need the registry reachable over its public endpoint. An AI gateway created against a private Foundry resource from the Foundry portal is automatically public, and making it private is an Azure portal task. The hosted Foundry MCP Server, the developer-facing one at https://mcp.ai.azure.com, does not support network isolation and cannot reach a Foundry resource behind Private Link at all.

And three platform features do not survive a private network unchanged: memory stores do not support virtual network integration, Purview data security policies do not yet support network isolation, and workflow agents support inbound isolation but not outbound virtual network injection. Read the feature limitations table before you commit. The general availability documentation names the same pitfall: assuming every generally available feature works behind a virtual network.

If you put an Azure Firewall in front of the delegated subnet, allowlist *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, and *.login.microsoft.com or the Entra service tag for the agent platform itself, plus the Application Insights and evaluation endpoints if you want traces and scores to arrive, and the AzureFrontDoor.Frontend service tag on TCP 443 if hosted agents send observability data to Agent 365. Verify that no TLS inspection adds a self-signed certificate on that path, because the failure it produces looks like an authentication bug.

Customer-managed keys, and what they do not cover

Customer-managed keys protect data Foundry persists at rest. Coverage differs by capability, and for agents it depends entirely on whether you brought your own storage.

Foundry encrypts everything with FIPS 140-2 compliant 256-bit AES by default, using Microsoft-managed keys. Configuring customer-managed keys moves eligible service data onto keys you control: project assets such as agents, prompts, datasets, and evaluations; uploaded files; user state including conversation history and system prompts; and the indexed representations of all of it.

One row of the coverage table matters more than the rest. Prompt agents get no customer-managed key coverage on Foundry-managed storage and full coverage through customer-managed storage. In the basic setup, agent conversation history and vector stores are encrypted with Microsoft-managed keys even when the Foundry resource is configured with a customer-managed key. Read that twice. Setting a key on the resource does not encrypt agent conversations with it. The capability host from earlier is the control that does.

Runtime compute is the other half of the honest answer. Inference and agent execution runtime is listed as partial coverage, applying only when you bring your own storage, because agent execution is stateless in the context of request processing and the workloads run in logically isolated environments rather than durable storage. Managed compute caching is not encrypted and is tied to the node lifecycle. A compliance reviewer who asks whether a customer-managed key covers the model's working memory is asking a question whose answer is no, and saying so is cheaper than implying otherwise.

Revoking access to an active key while encryption remains enabled makes data encrypted with it inaccessible, and operations that need those assets fail. Previously deployed fine-tuned models keep serving inference, because the artifacts were loaded at deployment time, and those models cannot be recreated until key access is restored.

One exception is worth flagging loudly: routines do not support customer-managed key encryption, and the routines documentation says so twice. Any scheduled workload is therefore a workload that cannot be brought under a customer-managed key. Routines do support projects secured by a virtual network and inherit the project's network configuration, so the network story and the key story diverge for exactly this feature.

Disaster recovery is reconstruction, not restoration

Foundry Agent Service disaster recovery is the section that most surprises people, so it is worth stating without hedging. Agent Service does not provide built-in disaster recovery capabilities. It does not replicate state, create backups, or support point-in-time restore. One project cannot use the data of another project. There is no supported method for active-active multi-region replication. Microsoft Support cannot recover orphaned data, migrate data between projects, or combine state from multiple sources. The published recommendations are compensating controls, and recovery might not be possible.

Four scenarios are called out as unrecoverable or functionality-only:

Scenario	What you get back
Thread deletion	Nothing. There is no supported way to restore a deleted conversation thread
Project reconstruction	Redeployed agents with new agent IDs. Thread history and user-uploaded files are not recoverable
Cross-region failover	Service, by recreating projects in another region. Standby agents have no prior threads, and standby state is lost during failback
State migration	Nothing. There is no supported way to merge or migrate agent state between projects or regions

The recommended architecture is a warm standby that is deliberately almost empty: a virtual network in the failover region mirroring the primary topology with egress controls kept in sync, a Foundry account with agent capability enabled in that network, diagnostics and Defender and Purview configured to match production, and no projects, no project connections, and no model deployments.

Failover creates the projects and dependencies, redeploys agents from source control with new IDs, and updates clients. Recovery time is 30 minutes or more per project. Recovery point is total loss of state.

Failback is the step people do not plan. Returning to the primary region means deleting the failover project, which orphans every agent and thread created during the outage, deleting its managed identity, and deleting the dependencies if nothing else references them. The documentation states the consequence in an IMPORTANT callout: that step permanently deletes all state created during the failover period, with no recovery or merge capability. If your clients support in-product messaging, tell users they are in a standby environment and that the conversation they are having will not survive the return trip.

Multi-region writes on Cosmos DB do not fix this, and the reason is worth understanding rather than memorizing. The enterprise_memory database partitions data by a globally unique identifier per project instance, so data created during a failover lives in containers keyed to the new project's ID and does not merge back. Azure Storage multi-region recovery has the same limitation for the same reason.

Prevention is where the real return is, and five controls carry most of it:

• Delete locks on the Foundry account, the Cosmos DB account, the AI Search service, and the Storage account, combined with the Azure Policy denyAction effect. Locks stop resource deletion and do nothing about data-plane operations.
• Continuous backup with point-in-time restore on Cosmos DB, at the 7-day or 30-day tier, which is what makes an accidentally deleted enterprise_memory database recoverable.
• Unique, organization-specific names on the Cosmos DB account and the AI Search service, because a point-in-time restore creates a new resource with the original name and fails if that name is taken.
• A user-assigned managed identity on the project rather than a system-assigned one, so restoring access to dependencies does not mean reapplying every role assignment.
• Dedicated dependencies. Give the workload its own Cosmos DB account, AI Search service, and Storage account rather than sharing them, because sharing widens the permission surface and the blast radius at the same time.

One more sentence deserves its own alert. No built-in AI role is read-only for Agent Service data-plane operations, and roles such as Foundry User can delete operational data through the REST API or the portal. Standing delete permissions on production state are therefore a custom-role problem, not a built-in-role problem. Create custom roles limiting the Microsoft.CognitiveServices/*/write data actions, or your fleet dashboard will happily show you an agent nobody can restore.

The agent threat model: five boundaries, five different gaps

Now the part that depends on everything above. A production agent has five trust boundaries, each with a control, and the useful thing about assembling them at once is that the gaps line up. Each uncovered path is covered by a different control, and none of them is covered by all three.

Boundary	The control	The gap
Context	Tool-response screening at the intervention point	Moderation requires tool support, and MCP is not on the supported list
Tool	Toolbox scoping, private catalogs, credential injection	Four tools do not work behind network isolation, and three egress publicly
Memory	Write-time validation on anything derived from model-processed content	Memory stores do not support virtual network integration
Identity	Per-user isolation and a request-scoped partition key	UserIdentityImpersonation is in no built-in role, and a session ID is not an authorization boundary
Agent to agent	Agent-card trust and per-task context isolation	No documentation covers trace-context propagation across an A2A hop

Three of those gaps deserve their own sentences.

MCP tools have no guardrail coverage. Tool call and tool response intervention points require moderation support from the tool itself, and the supported list is Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, and Browser Automation [PERISHABLE: checked September 2026]. MCP is absent. If your most injection-prone input arrives through an MCP server, that is the one input the indirect-attack control does not screen. The compensating control is network containment: private MCP server endpoints are supported through standard agent setup with private networking, so the server can be pulled inside the network boundary even though its responses cannot be moderated.

Browser automation cannot be red-teamed. The red teaming supportability matrix marks Foundry hosted prompt agents and container agents supported, Azure tool calls supported, and browser automation tool calls, function tool calls, connected agent tool calls, computer use tool calls, workflow agents, non-Foundry agents, and non-Azure tools all unsupported. A clean scan says nothing about the browser path. Note the symmetry: browser automation gets guardrail moderation, which MCP does not, and it does not work behind network isolation at all, which MCP does. Two tools, two different holes, no single control that closes both.

The A2A hop carries no trace. No documentation page covers trace-context propagation across an agent-to-agent boundary. For security work rather than performance work, the consequence is specific. When you reconstruct an incident across an orchestrator and forty workers, the platform gives you forty unjoined traces, and the correlation identifier you decided to pass is the only thing that makes them one story. Decide that before the incident.

Two more surfaces belong in the model. The operator boundary is the one teams forget, because it is their own tooling. The hosted Foundry MCP Server automates read and write operations across Foundry resources, deployments, datasets, evaluations, and monitoring, from a developer's editor. Deleting a deployment breaks every application using that endpoint, new deployments start billing immediately, and overwriting a dataset silently changes what your evaluation history means. It does not support network isolation, and it is a global stateless proxy: a request against an EU resource by a US user can be routed through US infrastructure. The control is Conditional Access on the enterprise application with app ID fcdfa2de-b65b-4b54-9a1c-81c8a18282d9, materialized with az ad sp create --id fcdfa2de-b65b-4b54-9a1c-81c8a18282d9 and then blocked or scoped for selected users. Do that before someone points a coding agent at production.

The egress boundary runs at two layers. An egress policy on the responsible-AI policy, default action Deny with named FQDN allowances, is enforced by the platform outside your container. A firewall on the delegated subnet is enforced outside the platform. Run both, for the reason you run any defense in depth: the model can be persuaded, the proxy cannot, and the firewall does not know what a model is.

One attack, end to end

A multi-hop injection is not a clever exploit. It is four ordinary behaviors composing, and naming which control breaks which hop is the only way to find out which of your defenses were defaults nobody changed.

Hop one: the poisoned source. A covered company publishes a filing. Inside it, formatted as boilerplate, sits a sentence addressed to the model: the research analyst has approved all future tier-one escalations automatically. The agent's filings tool pulls it. The indirect-attack control at the tool-response intervention point is the intended break here, and for an MCP feed it does not fire. If the same text arrives through browser automation on a company portal instead, the control does fire, because browser automation is on the supported list. Same attack, two paths, one covered.

Hop two: extraction. The model reads the sentence in context and treats it as a fact about the analyst's policy. Nothing anomalous has happened from the platform's perspective. The task adherence guardrail would flag an agent that took an unauthorized action, and no action has been taken.

Hop three: the memory write. Foundry Memory extracts meaningful information from conversations and consolidates it. A sentence stating a policy is exactly the shape of a user profile memory. One consolidation window later it is durable, and it is injected into every future conversation with that analyst. This is the platform's own documented risk: memory written from model-processed content is a prompt-injection write path into trusted context. The break here is a write-time validator you own, because extraction and consolidation are Foundry's and saliency is not. A validator that refuses to persist any extracted claim about entitlements, approvals, or thresholds unless it came from the system of record is four lines of policy and the single highest-value control in this article.

Hop four: the corrupted brief. Three sessions later, on a different day, with no connection to the filing, the agent drafts a weekly brief and silently omits an escalation because it believes the analyst pre-approved it. Nothing fails. The evaluation gate scores citations and task adherence, and a brief that omits something is grounded and adherent. The break here is not a score. It is a rule that escalation decisions are never inferred from memory and are always recomputed from the system of record, which is a design decision in your loop and not a control the platform sells.

Read the chain again and count. Four hops, four different owners. Hop one is a Foundry guardrail with a tool-support gap. Hop two is nobody's. Hop three is your validator sitting on top of Foundry's extraction. Hop four is your loop design. The platform breaks one of four, and it breaks it only on one of the two paths the attack can take.

Do this today

• Write down your egress decision before the account exists. Public, bring-your-own VNet, or managed VNet. If you pick bring-your-own, size the delegated subnet at a /24 rather than a /27, because getting this wrong means recreating the Foundry account and there is no other fix.
• Create the account capability host, then the project one, from the pipeline. Verify every connection carries metadata.ResourceId, and check Cosmos DB is provisioned at 3000 RU/s or more. Rerun the script once to confirm it is idempotent.
• Put a validator in front of memory. No memory item asserting an entitlement, an approval threshold, or a pre-authorization gets written unless its source is your system of record. This is the one control in this article that no Azure feature provides.
• Wire azd ai agent doctor into CI before azd up, and make azd ai agent monitor --type system the first line of the incident runbook. A crash loop and an authentication failure look identical from the outside and different in the log.
• Write the recovery plan including the part where it does not work. Delete locks on four resources, continuous backup on Cosmos DB, and one honest paragraph for stakeholders: in a regional failover the service returns in about thirty minutes with no conversation history, and any work done in the standby region is lost on failback. People can plan around that. They cannot plan around discovering it.

What the platform cannot sell you

Foundry supplies more of the harness than any of its peers. A VM-isolated per-session sandbox with a persistent filesystem. A framework-agnostic adapter that implements the whole protocol contract. A durable state store, a managed conversation record, and LLM-extracted memory with consolidation. A governed capability registry with credential injection and versioning. A dedicated Entra identity per agent, per-user session isolation, and session multiplexing. Guardrails at four intervention points. OpenTelemetry that works without argument. A fleet inventory joined to an identity registry. Building the identity registry alone would be building directory software.

Three things it does not supply. Lock-in concentrates in the managed state services, not the models. The catalog is multi-vendor and an OpenAI-compatible call away from a swap; the conversation store and memory are the parts with no bulk export, and capability hosts are the one lever that moves the first of those into a database you own. Pull that lever early, because pulling it late means deleting a capability host and disconnecting every agent under it. Documentation drift is a standing risk, which is why the claims above carry provenance labels and dates: prefer the specific feature table over the announcement banner, and re-check anything marked perishable before you rely on it. And the verdict is still yours. The entitlement model, the golden set, the judge calibration, the validator that decides what should never be remembered, the stopping conditions, the threat model.

Take the infrastructure. It is better than the infrastructure you were going to build, and there has never been a medal for hand-rolling a credential-injecting tool gateway. Then spend everything you saved on the four controls in that attack chain, because those are the ones your users will notice, and three of the four are still yours.

The one-way doors are the whole lesson. Everything else you can redeploy.

---