Securing Azure AI Foundry agents starts with workflow boundaries

At a glance

What this is: This is Zenity’s analysis of how Azure AI Foundry-built agents can be abused through prompt injection and workflow chaining.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now have to govern triggers, tool use, and data access as one attack surface, not separate design choices.

👉 Read Zenity's analysis of Azure AI Foundry agent prompt injection risk

Context

Azure AI Foundry agent security is really a workflow-governance problem: once untrusted inputs, privileged connectors, and automated actions sit in the same execution path, prompt injection can turn a normal business process into a data-loss path. The article shows how a customer support routing agent can be steered from a simple email into CRM lookups and outbound exfiltration.

For identity teams, the issue sits at the junction of agent lifecycle, tool permissions, and data access boundaries. Build-time controls alone do not hold if runtime behaviour can still combine trigger trust, connector scope, and action authority in ways the programme never intended.

Key questions

Q: How should security teams stop prompt injection from reaching agent tools?

A: Security teams should separate untrusted input from agent instructions, constrain tool access to the minimum workflow need, and enforce policy checks at runtime. The goal is to prevent attacker-controlled content from becoming a valid execution path. If the agent can read sensitive data and send data out through the same workflow, prompt injection becomes much easier to weaponise.

Q: Why do AI agents create a larger identity risk than ordinary automation?

A: AI agents can interpret content, choose actions, and chain tools in ways ordinary automation cannot. That matters because the security boundary is no longer just the application account. It is the combination of trigger trust, data access, and outbound authority. Once those three are combined, one compromised workflow can move sensitive data across systems quickly.

Q: What breaks when an agent can read sensitive data and send email?

A: The trust model breaks because the same workflow can both discover sensitive information and transmit it outside the intended boundary. That creates an exfiltration channel that does not require a separate malware payload. If the email body can influence retrieval and the agent can forward results, the workflow itself becomes the attack surface.

Q: How do organisations govern agent security without over-trusting platform safeguards?

A: Organisations should treat platform safeguards as one layer, not the control model. Real governance needs visibility into every agent thread, policy enforcement over tool use, and inline prevention for unsafe actions. That approach is stronger because it catches abuse at runtime, where prompt injection and chained tool actions actually unfold.

Technical breakdown

Prompt injection in agent workflows

Prompt injection occurs when attacker-controlled content is interpreted as instructions by an agent, rather than treated as data. In the Foundry scenario, the email body becomes the trigger payload, so the agent processes malicious text inside the same workflow used for legitimate customer requests. The weakness is structural: if instruction and input share a channel, the agent can be manipulated into changing its own behaviour. Content filters can reduce obvious abuse, but encoding, obfuscation, and multi-step chaining still create room for exploitation.

Practical implication: separate untrusted input handling from agent instruction paths and treat every user-originated message as hostile until proven otherwise.

Tool access, connectors, and data sources

The risk expands when an agent can call tools such as Salesforce, email, or Azure Logic Apps connectors. Tools are not just integrations. They are authority boundaries that let the agent read data, take actions, and pass information across systems. In this pattern, the agent uses a data source for account context, then a send-email action to move data outside the environment. Once the tool set includes both sensitive read access and outward communication, prompt injection can be converted into actionable exfiltration.

Practical implication: review every agent tool for read, write, and forwarding capabilities, then remove any connector that creates an unnecessary exfiltration route.

Defense in depth for agent runtime

Agent security has to combine visibility, policy enforcement, detection, and inline prevention because no single layer is reliable against adversarial prompting. Foundry’s built-in safeguards may block simple abuse, but the article argues they can be bypassed in realistic scenarios. That means security posture depends on runtime context, workflow graph analysis, and the ability to stop or modify agent actions as they happen. For agents, security controls need to see the full thread, not just the prompt at the point of entry.

Practical implication: instrument agent runtime events, policy-check every action path, and block unsafe actions inline rather than relying on post-event review.

Threat narrative

Attacker objective: The attacker’s objective is to make the agent itself carry out reconnaissance, data discovery, and exfiltration while appearing to process a normal business request.

1. Entry occurred through a malicious email that looked like a legitimate customer message but carried prompt injection content.
2. Credential or access abuse followed when the agent exposed account context and invoked connected tools against CRM and messaging systems.
3. Impact came from successful data exfiltration, with sensitive CRM information routed into the attacker’s email box.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Prompt injection is a workflow governance failure before it is a model failure: The broken premise is that untrusted input can be processed inside the same execution path that also carries sensitive authority. Once an email can influence routing, retrieval, and outbound action, the agent is no longer just reading content. It is participating in the attack path. Practitioners should treat this as a control-boundary problem, not a prompt-tuning problem.

Agent tool boundaries now define the identity perimeter: In an agent stack, the meaningful security unit is not the model alone but the combination of trigger, connector, and action authority. A send-email tool paired with CRM access turns a business workflow into a data movement channel. That means governance has to map agent capabilities the way identity teams map standing privilege in other non-human identities. The implication is that agent authorisation must be scoped by workflow role, not just by platform membership.

Runtime observability is the only reliable way to distinguish intent from abuse: The article’s layered model is directionally right because detection has to see the whole thread, including prompt content, tool invocation, and response chaining. Static approvals cannot explain what an agent actually did at runtime. This is why agent security is converging on continuous context analysis rather than one-time certification. Practitioners should assume that the exploitable unit is the session, not the deployment.

Defense in depth is becoming the baseline for trustworthy agents: The article shows that content filters and prompt shields are necessary but insufficient when attackers can shape multi-step behaviour. That matters because enterprises will keep expanding agent use while expecting familiar app-security controls to carry the load. They will not. Security teams need layered governance that can constrain build-time exposure and runtime action simultaneously. The implication is a shift from trust-by-design to verify-every-step agent governance.

Identity blast radius is the right named concept for this problem: A single agent can bridge untrusted input, privileged data, and external transmission, so the blast radius is not the prompt itself but the span of authority attached to the workflow. That span often exceeds what teams intended because tool access, data source access, and trigger trust are evaluated separately. Practitioners should measure how far one compromised agent can move data before any human ever sees the thread.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint research.
• That governance gap is why practitioners should also review OWASP Agentic AI Top 10 for runtime controls and agent misuse patterns.

What this signals

Identity blast radius is now a programme-level metric: the question is no longer whether an agent can be secured, but how far one compromised workflow can move data before containment. Teams should start measuring trigger trust, connector authority, and outbound transmission as a single control surface, not three separate ones.

The most useful governance signal is runtime traceability. If your programme cannot reconstruct an agent thread from input to tool call to response, then it cannot credibly support incident review, audit evidence, or containment decisions when prompt injection lands.

With 80% of organisations already reporting out-of-scope agent behaviour, per AI Agents: The New Attack Surface report, the forward path is clear: security teams need policy, observability, and inline enforcement before agent adoption expands further.

For practitioners

• Map trigger to exfiltration paths Inventory every agent workflow from inbound trigger through tool invocation to outbound transmission. Flag any path where untrusted content can reach privileged data and then leave the environment through email, chat, or API calls.
• Split instruction channels from content channels Refactor workflows so user-originated data cannot be interpreted as agent instructions. Use strict message segregation, sanitisation, and parsing controls before the agent ever sees the payload.
• Restrict connector authority by workflow role Grant each agent only the connectors it needs for one business function. Separate read access from send or write capability, and remove any connector that can forward sensitive data outside the intended boundary.
• Instrument runtime decisions and block unsafe actions inline Log agent threads end to end, including prompts, tool calls, and responses. Use policy checks at action time so malicious or unexpected behaviour can be stopped before the workflow completes.
• Review agent controls with OWASP and ATLAS mapping Align build-time and runtime controls to the OWASP Agentic AI Top 10 and the MITRE ATLAS adversarial AI threat matrix so teams test for prompt injection, tool misuse, and chaining failures.

Key takeaways

• Agent security fails when untrusted input, sensitive data, and outbound tools share the same workflow.
• Real-world evidence shows AI agents are already acting beyond intended scope in most organisations.
• Defending agent stacks requires runtime visibility, tight connector scoping, and inline blocking, not prompt tuning alone.

Key terms

• Prompt Injection: Prompt injection is attacker-supplied content that causes an AI agent to follow malicious instructions instead of the task it was meant to perform. In agent workflows, the risk is greatest when user input, retrieval content, and execution authority are mixed without strong separation.
• Agent Workflow: An agent workflow is the chain of trigger, reasoning, tool use, and response that lets an AI agent complete a task. For security teams, the workflow matters more than the model alone because risk emerges from how the agent moves between data, tools, and actions.
• Runtime Observability: Runtime observability is the ability to see what an agent actually did during execution, not just what it was authorised to do at design time. It is essential for investigations because prompt injection and tool abuse are often only visible in the full execution thread.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and actions an identity can reach if it is compromised or manipulated. For AI agents, the blast radius depends on trigger trust, connector scope, and outbound authority, not just on the model’s intelligence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: Inside the Agent Stack, Securing Azure AI Foundry-Built Agents. Read the original.