Inside the Agent Stack: Securing Azure AI Foundry-Built Agents

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.

At Zenity, we work closely with these platforms to understand how attackers think, how defenders can respond, and how to harden every phase of the agent lifecycle - from buildtime to runtime. 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

Zenity’s security and governance platform applies defense-in-depth to secure agents across every stage of their lifecycle. Rather than relying on one layer of control, we combine visibility, observability, detection, and automated response to understand agentic intent and context and reduce risk exposure in both build time and runtime.

1. Visibility

Full visibility into every agent and component including triggers, actions, connections and data sources.

In our Extract, Transform and Load (ETL) pipeline, we process the collected data, transform it and build a comprehensive inventory that contains details about each object that helps teams understand exactly how each agent operates and where risk may arise.

On top, we analyze and map each agent’s capabilities and build a detailed security graph that visualizes the relations between the agents and its components, including triggers, actions and data sources. The graph provides a deeper understanding of potential attack paths and vulnerabilities and helps investigate issues and threats when they arise.

In addition to the inventory and security graph, for each agent our solution provides full visibility into the agent’s runtime activity that is mapped into different steps including user and AI messages, tool invocation, RAG steps and more. Each step is enriched with information that helps understand the runtime context and the end-to-end flow of each agent thread.

2. Governance and Risk Assessment

After understanding each agent’s context, the next step is to enforce policies for every asset that meets the organization’s needs and guidelines.

For example, many organizations need ways to prove that they can ensure that agents are only using approved tools, and are only granted access to allowed endpoints. Policies can be customized per environment for production vs. development agents and security teams can apply controls at build time that are aligned with well known frameworks such as OWASP Top 10 for LLMs and MITRE ATLAS.

We then run an analysis using our rule engine and other scanners to enforce a variety of rules with different severities, from security best practices, such as secrets found in agent instructions to toxic combinations to mark risky agents in the organization.

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.

With the continuous risk assessments, we make sure to surface issues as soon as they are discovered, and suggest practical and concrete steps that the organization should take in order to fix or harden its posture to reduce or completely eliminate the attack surface.

3. Threat Detection

Next, security teams should implement systems that enable them to be alerted to real-time threats and malicious actions taken by the agent. This can be done within the Zenity platform by analyzing the end-to-end thread of agentic behavior with enriched context to detect and prevent harmful actions, data leakage or tool misuse.

Our pipeline consumes the agent thread events, and converts them into unified schema for further analysis.

It integrates smart scanners that run on the multi-step threads and collect indicators from the different steps including agent trigger, actions and response. Combining the various indicators from different steps and scanners allows us to determine the confidence and the severity of the issue or attack.

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.

4. Automated Response

To complete the end-to-end security, security teams can also fix and mitigate issues as soon as they are discovered in the Zenity platform. This is done automatically, without human intervention, by configuring playbooks to apply policies and rules specific to environments.

Users can easily configure multi-step workflows and use pre-defined mitigation actions to fix existing and future issues at scale.

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.

5. Inline Prevention

To block malicious actions or prevent unintended behavior in real time, security teams can also instrument the agent workflows and connect it to the Zenity platform to enforce inline controls.

In the Zenity platform, we analyze the entirety of the agent’s context and examine the agent’s activity, then decide whether to allow, block or modify the agent’s decision or action.

In this example, we instrument the agent’s trigger and actions by changing the underlying connected Logic Apps workflows. As shown below, the agent workflow is interrupted and data exfiltration by send email action is blocked.

TLDR;

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 Bedrock, exploring the architecture, unique risks, and best practices for both build time and runtime protection. Stay tuned!