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 compromised when email triggers, data sources and action tools sit inside one workflow boundary.

Why it matters: It matters because IAM teams now have to govern agent workflow boundaries, not just model prompts, when untrusted inputs can drive downstream actions and data access.

Context

Azure AI Foundry agents are built from triggers, data sources and tools that can be wired into a single workflow. That makes the platform useful for automation, but also creates a governance problem when untrusted input can influence the same execution path that reaches enterprise data.

Zenity’s example shows why agent security is not just a prompt-safety question. Once the workflow can read external messages, query internal records and invoke outbound actions, the identity boundary becomes the control surface, not the model interface.

The article’s scenario is deliberately realistic rather than exotic. It reflects the kind of customer support routing pattern many teams would consider normal, which is exactly why the governance gap is easy to miss.

Key questions

Q: What breaks when AI agent workflows treat untrusted email as a valid instruction source?

A: The workflow breaks at the boundary between interpretation and execution. If hostile content can influence data lookups or outbound actions, the agent is no longer just summarising input. It is acting on attacker-controlled instructions inside a privileged path, which turns routine automation into a governance problem.

Q: Why do agent workflows that can read data and send messages create higher risk?

A: Because the same workflow can move from discovery to exfiltration without leaving the agent’s control plane. When a system can both access sensitive data and transmit it outward, an attacker only needs one successful injection point to bridge trusted systems and untrusted recipients.

Q: How can security teams tell whether an agent is overreaching its intended workflow?

A: Look for paths where a benign trigger can reach multiple privileged systems, especially when the same thread can read, reason and act. If a routine support task can invoke CRM lookups, external email and policy exceptions, the workflow boundary is too broad for the trust level it has been given.

Q: Should organisations separate agent triggers, data sources and action tools?

A: Yes, when those components cross trust domains. Separation reduces the chance that untrusted input can directly steer a privileged action, and it makes it easier to apply different review, logging and approval rules to each stage of the workflow.

Technical breakdown

How Foundry workflows connect triggers, data and actions

Microsoft Foundry lets teams compose agents from an event trigger, data sources, and tool or action calls. In the scenario described, an Outlook-triggered workflow passes email content into the agent thread, while attached sources such as files and Salesforce context expand what the agent can reason over. That architecture is powerful because the agent does not need a separate integration for each step. It is also risky because every added connection expands the trust boundary. Once the workflow can both ingest untrusted content and act on enterprise systems, a single compromised thread can bridge read and write paths that defenders may have treated as separate controls.

Practical implication: Map every trigger, source and tool in the agent workflow to an explicit trust boundary before you approve it.

Why prompt injection becomes a workflow control problem

Prompt injection is not just a model-output issue in this pattern. If the agent can use an attacker-controlled email body to influence tool choice, data lookup, and outbound communication, the prompt becomes an instruction channel that crosses security domains. Zenity’s example shows the attack chaining from reconnaissance through data discovery to exfiltration. That matters because the dangerous step is not merely that the model was persuaded, but that the workflow treated hostile text as a valid input to privileged operations. Content filtering alone does not change the fact that the workflow is executing with access to systems the sender should never control.

Practical implication: Treat untrusted text as input to a privileged workflow, not as a harmless message that the model can safely interpret.

How agent actions become the exfiltration path

Foundry actions are implemented through Azure Logic Apps under the hood, which means a tool call is a real workflow invocation, not a simulated response. In the article’s scenario, the agent can send email and retrieve account details from Salesforce, so a malicious prompt can convert a support automation into a data transfer channel. That is why the issue is broader than jailbreaks. The relevant question is whether the agent can cause side effects in connected systems based on content it did not originate. If the answer is yes, then the action layer is part of the attack surface and must be governed as such.

Practical implication: Apply the same scrutiny to tool calls and outbound actions that you would apply to any privileged integration account.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate support-routing agent into a data exfiltration channel that leaks CRM information through trusted outbound email.

1. Entry occurs when the attacker sends a malicious email that looks like a legitimate customer message and enters the agent’s workflow through the Outlook trigger.
2. Credential access is not the main step here, but the attacker gains effective control over the agent’s decision path by injecting instructions into the message body and bypassing safety guidance.
3. Escalation occurs when the agent uses its connected Salesforce data source and send-email action to follow the attacker’s instructions across trusted systems.
4. Impact is the exfiltration of sensitive CRM data into the attacker’s mailbox through the agent’s own outbound workflow.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workflow boundaries, not prompts, are the real control plane for AI agents: This article shows that the security question is no longer whether a model can be persuaded, but whether a workflow can be safely allowed to carry untrusted input into privileged actions. When triggers, data sources and tool calls are linked in one execution path, the boundary itself becomes the governance object. The practitioner lesson is to model agent workflows as identity-bearing systems, not as isolated model sessions.

Prompt injection exposes a boundary assumption that was never valid for agentic workflows: The assumption that untrusted content can be parsed before privilege is exercised was designed for systems where interpretation and action are separable. That assumption fails when an agent can read hostile input and immediately route it into data lookup or outbound action without a meaningful trust break. The implication is that review cycles built around model output miss the actual decision point.

Agent actions need governance because side effects are identity events: Sending email, querying Salesforce and invoking Logic Apps are not neutral technical steps. They are authorisations in motion, because each one extends the agent’s effective reach into enterprise systems. That means governance must treat the action layer as part of identity control, not merely as orchestration plumbing. Practitioners should expect the highest risk where the agent can both ingest external content and commit external effects.

Trust boundary drift: This is the most useful concept in the article. Every added source, tool and trigger widens the path from untrusted input to privileged action, often faster than governance reviews can keep up. Teams should stop asking whether the model is safe in isolation and start asking where the workflow boundary has drifted beyond the trust assumptions originally approved.

Defense-in-depth remains necessary, but it has to start with the workflow graph: Zenity’s layered controls are framed around visibility, policy enforcement, detection and response because a single guardrail cannot absorb the full attack path. That aligns with mature identity practice: when multiple systems can be reached from one agent thread, no single control point can be assumed to hold. The practical implication is to govern the workflow graph first, then instrument the layers that remain exposed.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: Zero Trust for AI Agents

What this signals

Trust boundary drift: Agent governance fails fastest when teams approve a workflow as a whole and never revisit how far untrusted input can travel once triggers, tools and data sources are combined. That is the point at which the workflow stops behaving like automation and starts behaving like an access path.

The more an agent can both consume outside input and reach internal systems, the more your review process has to move from prompt safety toward authorisation design. In practice, that means checking whether the agent can cross from read to write, from internal context to external delivery, and from observation to action in one thread.

For practitioners

• Define workflow trust boundaries Inventory each agent trigger, data source and action path, then mark where untrusted input crosses into privileged operations.
• Restrict outbound action scope Limit which agents can send email, call APIs or retrieve CRM data, and separate read-only review paths from action-capable paths.
• Classify untrusted input paths Treat email, chat and file content that can enter agent threads as hostile by default when it can influence tool selection or workflow branching.
• Instrument agent runtime activity Log thread steps, tool invocations and response chains so you can detect when a prompt has steered the agent into unintended data access.
• Use approval gates for risky actions Require review before triggers that can reach sensitive systems are activated, especially where the agent can re-route or transmit data externally.

Key takeaways

• The article shows that Azure AI Foundry agent risk is a workflow-boundary problem, not only a prompt-safety problem.
• Its example attack moves from malicious email to internal data discovery to outbound CRM exfiltration through ordinary agent capabilities.
• The control point that matters most is the boundary between untrusted input and privileged action, because that is where the workflow becomes an access path.

Key terms

• Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.
• Defense in depth: Defense in depth is the practice of stacking independent controls so one failed check does not expose the whole system. In App Router authentication, that means verifying identity in middleware, route handlers, and data access logic, because each layer protects a different part of the request path.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.