When an AI agent runs in a production environment, it doesn’t just answer questions. It calls tools, reads from data sources, writes to systems, and takes actions on behalf of a user or a business process. That changes the security conversation. The question isn’t just what the agent knows. It’s what the agent can do, and what happens if that capability is misused or exploited.
This post covers AI agent security on Azure: how identity works for agents, how to scope permissions to reduce the damage of a compromised agent, and what to log so you have a record when something goes wrong.
Key takeaways
- An AI agent should have its own identity, not share the credentials or service principal of the application it runs inside. Each agent acting independently needs its own authentication context.
- Agents should be granted only the permissions they need for their defined task. Access at subscription scope is almost always too broad.
- “Blast radius” is the right frame for scoping agent permissions: if this agent’s credentials were misused, what could an attacker reach? That question should drive every RBAC assignment.
- Tracing is off by default in Microsoft Foundry. If you haven’t turned it on, you have no log of what your agents called, what data they accessed, or what they wrote.
- Requiring approval for write operations adds a human checkpoint before an agent takes an irreversible action. It’s a governance control, not a performance constraint.
Should an agent act as the user or as itself?
This is the foundational identity question for enterprise AI agents, and the answer depends on what the agent is doing.
When an agent acts on behalf of a specific user (accessing documents that user is allowed to see, sending messages in their name, writing to records they own), delegated access is the right model. The agent acts as the user, and the user’s existing permissions define the boundary. If the user can’t read a file, the agent can’t either.
When an agent acts as an autonomous system (running a scheduled process, handling a queue of work items, responding to events without a user present), it needs its own identity and its own permissions. In Microsoft Foundry, each agent gets its own Microsoft Entra agent identity, a special service principal that Foundry provisions automatically from an agent identity blueprint. That identity starts with no resource permissions, and Foundry doesn’t assign RBAC roles to it. You assign only what the agent needs for its specific task.
The distinction matters for security: a shared service account that multiple agents use creates a situation where compromising one agent gives an attacker access to everything that account can reach. Per-agent identities limit that exposure. See the Microsoft Learn documentation on agent identity in Microsoft Foundry for how agent identities are provisioned and governed.
How do we scope permissions when an agent spans several systems?
Agents that call multiple tools need permissions to each of them. The temptation is to assign broad roles, such as Contributor at the subscription level, because it’s easier than mapping out the minimum access each tool requires. That’s the wrong call.
The right approach is to define the agent’s task first, then work backward to the permissions that task requires. An agent that reads documents from a storage account and writes summaries to a Cosmos DB container needs Storage Blob Data Reader on that account and a data contributor role scoped to that container. It doesn’t need Contributor at the subscription level.
This matters because Azure RBAC assignments are cumulative. An agent with Contributor on a resource group can reach everything in that group, including resources it has no business touching. If that agent is compromised through a prompt injection or a malicious tool response, the blast radius is everything in that resource group.
The same logic applies to tool permissions. An agent using an MCP server should be granted least-privilege credentials on that server, and the connection storing those credentials should be scoped to the specific resources the tool needs. An agent that only reads should not hold a write-capable credential, even if the tool supports write operations.
Planning your first production agents? Our AI Readiness Assessment is thirty minutes with the director who runs the practice. You leave knowing which of your data and workloads are ready and what has to change first.
What should we log for every agent action?
The answer is: more than you think, and you need to configure it before the first agent goes to production.
Tracing in Microsoft Foundry captures the inputs and outputs of each model call, the tool calls the agent made and their arguments, intermediate steps, latency, token usage, and errors. That data is stored in a connected Azure Monitor Application Insights resource and queryable through Foundry’s tracing UI. Without tracing enabled, there is no record of what an agent did during a conversation. You can’t audit an unexpected action, investigate a data access incident, or confirm the agent behaved consistently across runs.
Tracing is off by default. It activates when a project is connected to an Application Insights resource, and it applies to all agents in that project once enabled. The access control question is worth getting right before launch: viewing traces requires read permission on the connected Application Insights or Log Analytics workspace. Traces might contain personal data and customer content, so access to that data needs the same controls as the underlying systems.
For write operations, requiring approval before an agent executes a tool call adds a human checkpoint before irreversible action. This isn’t just a safeguard against agent error. It’s also a control against prompt injection, where a malicious input tries to get the agent to take an action the user didn’t intend. See the Microsoft Learn documentation on trace data in Microsoft Foundry for how to configure and access tracing.
A zero trust approach to AI models on Azure covers related controls for the model layer, including private endpoints and access policy. If you’re still choosing a first agent, where to start with enterprise AI agents on Azure covers how to scope one well-defined task, and the Foundry Agent Service deployment guide covers the build.
Frequently asked questions
Should an AI agent have its own identity or use a shared service account?
Per-agent identities are the right approach. When multiple agents share a service account, compromising one gives an attacker everything that account can reach. Giving each agent its own Microsoft Entra agent identity limits blast radius and makes audit logs interpretable: you can see which agent took which action, not just which account was used.
What RBAC roles should an AI agent have?
Only the roles needed for its specific task, scoped as narrowly as possible. An agent that reads from a storage container needs read access on that container, not on the storage account or the resource group. Work backward from the task to the minimum access required, then assign that access at the most specific scope available.
What is blast radius in the context of AI agents?
Blast radius is the scope of damage if an agent’s credentials are misused, whether through a compromised agent, a prompt injection attack, or a misconfigured tool. Keeping permissions narrow and scoped to the specific resources an agent needs limits the blast radius. An agent with read-only access to one container can’t be used to write to or delete anything else, even if it’s exploited.
What should we log for every agent action?
At minimum: inputs and outputs for each model call, every tool call and its arguments, any errors or unexpected terminations, and the user or process that initiated the conversation. Foundry tracing captures this when it’s enabled and connected to Application Insights. Configure tracing before the first production agent runs, not after an incident requires you to explain what happened.
How do we defend against prompt injection in AI agents?
Treat tool descriptions and tool results as untrusted input. Require approval for any write operation before the agent executes it. Use least-privilege credentials on each tool so a successful injection can’t reach resources outside the agent’s intended scope. Log all tool calls and review unexpected patterns. Prompt injection defenses are part of the agent design, not an add-on after launch.
Keep reading
Model Context Protocol Explained for Enterprise Teams
If you've been evaluating AI agents for enterprise use, you've likely started hearing about Model Context Protocol, usually shortened to MCP.
Enterprise AI Agents on Azure: Where to Start
The term "AI agent" has moved from research papers to enterprise roadmaps faster than most technology concepts do.
What It Costs to Run AI on Azure
When organizations start evaluating enterprise AI on Azure, one of the first questions IT finance and technology leaders ask is...