When you put an AI agent into production on Azure AI Foundry, you are not deploying a chatbot. You are deploying a new kind of privileged, non-human actor that reads text from places you do not control and can call tools that touch your systems. The useful question is not "is the model safe", it is "what are the ways in, and does a control stop each one". This is that map: fifteen paths an attacker takes against a Foundry agent, written from the defender's side, each with how it works and the control that closes it.
The single most important idea first, because it reframes everything. Most of the risk is not in the model. It is in how the platform is configured, and how the agent is wired to tools and data. A capable model behind a tightly scoped identity with no dangerous tools is low risk. A weak model with a broad identity and open tools is dangerous. So the paths below are mostly about configuration and wiring, not about jailbreaking the model, and the defences are mostly architecture, not prompt cleverness.
Getting in
Before an attacker can abuse an agent, they need a foothold. Three paths dominate, and all three are configuration failures rather than clever exploits.
The most common gap, and the cheapest to find: a data store or service the agent connects to has been left public while Foundry itself is private. An attacker scanning from the internet finds the connected store, not the front door. The control is simple to state and often missed in practice: nothing the agent touches should be reachable from the internet when the platform is not. Audit every connected resource for public exposure, not just the Foundry endpoint.
The most common real-world route to running someone else's models is a leaked secret: an API key in a repository, a connection string in a config file, a token in a notebook. The control is to remove the thing that leaks. Use managed identities instead of keys, scan for secrets in code and pipelines, rotate anything that must exist, and make sure a leaked credential grants the least it possibly can.
An attacker with a foothold elsewhere, a virtual machine in another spoke, an on-premises host, a workload in another cloud, tries to reach Foundry's private endpoints across the network. Private networking is necessary but not sufficient: it has to be paired with segmentation so a foothold in one place cannot route to the agent's subnet, and with the assumption that the internal network is not a trust boundary.
Bending the agent
Now the attacker works on the agent itself, through the text it reads. This is where AI security stops looking like ordinary application security.
An attacker crafts input that gets the model to ignore its instructions or reveal its system prompt. This is very likely to partly succeed, so the right posture is not to rely on the system prompt staying secret or the guardrail being perfect. Keep content guardrails on, but assume the instructions can be seen and that the model can be talked around. The real protection is what sits behind the model: if the identity is narrow and the tools are few, a jailbreak reaches very little.
This is the most important path, and the one worth the most testing time. The attacker does not sign in at all. They plant text in a source the agent reads, a web page, a document, an email, a tool response, and when the agent, acting for an innocent user, reaches that text, it follows the planted instructions and calls tools the user never asked for: reading other records, changing data, or sending information out.
It works because a language model has no reliable way to tell instructions from data once both are in its context. Every document, page and tool response the agent reads is therefore an input channel for whoever wrote it. The action is carried out under the agent's own identity, on behalf of a real user, so it looks like normal use. There is no single control that stops it. The defence is a stack, and the useful question is how many layers must fail before something happens.
Turning the agent against you
Once the attacker can influence the agent, the damage is whatever the agent can do. Four paths define that reach.
The classic agent threat. The agent acts under its own identity, which is more privileged than the user driving it, so a manipulated agent does things the user could never do directly. The control that matters most is a narrow, least-privilege agent identity: if the agent itself can barely reach anything, a confused deputy barely matters. This one control does more than any guardrail.
An agent that can write without a human in the loop can change things on a planted instruction. An agent with no loop limit can run without end. An agent with no spend cap can burn a large sum very quickly, denial of wallet as much as denial of service. The controls are approval gates on any write or high-impact action, hard loop limits, and spend caps with circuit breakers.
A compromised or malicious tool, or a forged request from the agent's own subnet, is used to reach internal systems the agent sits near on the network. Validate tool responses rather than trusting them, treat tools as a supply chain to be vetted, and make sure the agent's subnet cannot reach internal systems that are not explicitly part of its job.
Even with egress control, an attacker uses a destination the agent is already allowed to reach as the carrier for stolen data, a permitted API, a logging endpoint, a legitimate site. The control is an egress allow-list designed so that allowed destinations cannot double as exfiltration channels, and monitoring of what actually leaves, not just where it is allowed to go.
Getting data out
Two paths are specifically about confidentiality, and one of them is invisible to your server-side controls.
The agent is induced to put sensitive data into its output in a form that leaks when rendered, a link, an image reference, markup that the user's browser or chat client fetches, sending the data to the attacker. The important point for defenders: your server-side controls never see this leak, because it happens in the client. Only client-side output handling, sanitising and constraining what the rendered output can do, stops it.
One user reaches another user's data through shared retrieval indexes, conversation threads or uploaded files that were not properly isolated. The control is strict tenant and thread isolation, and retrieval scoped to the user making the request, so the agent can only ever surface what that specific user is entitled to see.
Breaking the controls, and seeing it happen
The last group is about the controls themselves being attacked, and about whether you would even know. If these fail, the earlier defences can be quietly switched off.
A developer or a compromised developer account turns off a guardrail, switches on public access, or enables keys, weakening the platform from the inside. The control is to lock down configuration so that high-impact settings, public exposure, key creation, guardrail changes, are not self-service, and any change is logged and reviewed.
Someone deploys a model or turns on a feature that keeps user data for later reuse, outside the approved process. The control is to gate model deployment and training behind approval, and to ensure data-retention and training-on-your-data features are off unless deliberately and contractually enabled.
The CI/CD pipeline that configures the agents is itself a target: abuse its identity to switch off a guardrail or open network access at deploy time. Give the pipeline identity least privilege, protect the pipeline as the high-value system it is, and treat a change to agent configuration with the same scrutiny as a change to production code.
The path that decides whether any of the others are survivable: if the agent's behaviour is not in your telemetry, none of the above is visible, and there is no way to stop a live misuse. Forward agent telemetry, inventory, identity, model, run and tool-call context, into the SIEM, build detections on agent behaviour, and have a working kill switch that can stop the agent's runtime and disable its identity on approval. An agent you cannot see and cannot stop is the real worst case.
The pattern across all fifteen
Read the paths together and the same shape appears. An attacker either finds a way in through a configuration gap, or abuses what the agent can already reach, and the thing that decides how far they get is not the model, it is the containment around it: a narrow identity, a short tool list, a private and segmented network, egress that cannot be used as a carrier, approval on anything that writes, and telemetry with a kill switch so you can see and stop misuse. Design an agent so that several independent controls must fail before harm occurs, and most of these paths end at the first locked door. Deploy one with a broad identity and open tools, and you have built exactly the privileged actor every one of these paths is looking for.
The full detail behind each path, the exact test steps, the control expected to stop each one, and what a passing result looks like, is in the downloadable field guide: Foundry attack paths, the 36-page field guide (PDF).
Prefer it interactive? The same material, with a threat you can trace through the guardrails and each path stepped through in the browser, is in the Foundry Field Guide microsite.
If you are putting agents into production on Foundry and want them designed to be contained and tested against paths like these before they go live, that is the kind of work I do through Cyber Spartans.