This blog kicks off our new series, Inside the Agent Stack, where we take you behind the scenes of today’s most widely adopted AI agent platforms and show you what it really takes to secure them. Each installment will dissect a specific platform, expose realistic attack paths, and share proven strategies that help organizations keep their AI agents safe, reliable, and compliant.

In this post, we’ll walk through a realistic scenario inside Microsoft Foundry (formerly Azure AI Foundry), demonstrate how a seemingly harmless workflow can be compromised, and show how a layered security approach (defense-in-depth) can make the difference between a contained event and a costly breach.

Microsoft Foundry

Microsoft Foundry is an end-to-end platform for building, deploying, and managing GenAI applications and agents. It provides a unified workspace for LLM deployments, prompt engineering, orchestration through prompt flows and agents. In Foundry, developers can design complex, multi-agent systems, connect them to enterprise data, and iterate seamlessly.

Building and deploying production-ready agents can be done in a few clicks. All you need to do is:

1. Provide a LLM model (deployment)

2. Define the agent’s instructions and expected behavior

3. Attach relevant data sources - from direct file uploads, a sharepoint site, data from Azure AI Search, etc.

4. Add tools or actions, if needed. This can be an API, an Azure Logic App, Azure Function, etc.

5. For autonomous agents, add a trigger. This is implemented as an Azure Logic App Workflow that subscribes to an event (the trigger) and has an action that in turn triggers the agent.

6. Connect an agent for task delegation and collaboration.

A Real-World Attack: Prompt Injection in Action

Let’s look at an example, a customer support agent built in Foundry, which is inspired by a real world scenario. The customer support agent is designed to receive customer emails, look up the relevant account details, and reroute the messages to the correct account owner for further handling.

What This Looks Like Under the Hood:

1. A trigger that is implemented as a logic app workflow with three steps: workflow trigger using outlook connector, create thread and create run actions using the Foundry Agent Service connector. The content that is passed to the agent thread is the body of the received email as you can see below:

2. A file that contains the mapping between customer account and account owner that is added to the agent as a data source.

3. “Send email” action to re-route the received email to the owner and “Get account details” from Salesforce CRM action to add context to the email.

When creating and adding an action, Microsoft Foundry creates a workflow in Azure Logic Apps under the hood consisting of: a webhook trigger, the action, and a response step and use it to invoke the action from the agent workflow and send back the response to the agent.

What Can Go Wrong?

Seems harmless, right? It is… until an attacker crafts a malicious prompt disguised as a legitimate message. In our demo, a three step attack led to data exfiltration from the CRM directly into the attacker’s email box. By crafting malicious inputs, aka prompt injection, the attacker takes control of the agent’s workflow causing unintended consequences and harmful actions. The exploit unfolded as follows:

1. Recon of the agent’s internal capabilities including tools and knowledge sources

2. Data Discovery exposed information about existing customer accounts names and bypassed the agent’s safety guidelines with encoding techniques

3. Exfiltration of sensitive data from the CRM was successful due to a malicious prompt that leveraged information obtained from the previous steps.

Microsoft Foundry offers foundational controls to defend against prompt injection and jailbreak attacks, namely content filtering and prompt shields that block malicious prompts. However, in our demo we were able to show that these controls are able to be bypassed. As we've written here, prompt injection is not a vulnerability that we can fix, rather it is an unsolved weakness that security teams should look to manage by applying defense-in-depth and hard boundaries to achieve truly trustworthy agents.

Defense in Depth

Now that we understand how these agents are built and how they can present risk, let’s quickly discuss what’s needed from a security and defense perspective. 

For starters, full visibility into every agent and component including triggers, actions, connections and data sources to understand the context of each deployed agent.

Continuous risk assessments to make sure to surface and fix issues as soon as they are discovered to harden posture and reduce attack surface. 

For example, similar to Agents Rule of Two: A Practical Approach to AI Agent Security, published by Meta, our example “Customer Support Routing Agent” violates the rule of two in that:

1. It is triggered by an email, meaning it processes untrustworthy inputs.

2. It has access to sensitive information from the Salesforce connector.

3. It transmits data through the “send email” tool.

As such, security teams should implement systems that enable them to be alerted to real-time threats and malicious actions taken by the agent. For example, in our presented attack on the Customer Support Routing Agent multiple indicators including the agent internal implementation recon and data encryption raise the suspicion of data exfiltration.

To automatically mitigate issues and help security teams track new potential threats, a playbook that disables the agent trigger until it’s reviewed and approved or disapproved by the organization security admins, could have been applied to our “Customer Support Routing Agent” and prevented misuse or data exfiltration in this example.

Intervention in real time is needed to block malicious actions or prevent unintended behavior.

In this example, we were able to instrument the agent’s trigger and actions by changing the underlying connected Logic Apps workflows, but with proper inline prevention, send email action could be blocked.

TL;DR

Even well-designed platforms present new, nuanced risks when it comes to agents. As enterprises continue to embrace agentic systems, proactive visibility, policy enforcement, and layered defense will define which organizations are successful in their adoption and innovation.

In our next post, we’ll dive into securing agents built on AWS AgentCore, exploring the architecture, unique risks, and best practices for both build time and runtime protection. Stay tuned!