Every AI Agent Needs an Identity — and an Owner

This series started with Who Owns the Architecture When AI Writes the Code?, where I asked what happens when AI accelerates delivery faster than governance can follow.

My answer was simple:

We still own it.

But ownership requires control. And control starts with knowing who—or what—is acting inside our systems.

This is the second of four articles in this series.

Identity gives us the context. Boundaries define where the agent can act. Validation tells us what actually happened.

This one is about identity.

Between the two, I wrote a spin-off, Governance Needs to Move at the Same Speed as AI, on why governance has to become continuous. This article goes one level deeper: the identities doing the work.

For years, I have repeated the same advice in sessions, customer discussions, and our own work at DevUP:

Static keys are bad. Move to identities.

That advice is still correct.

But it is no longer enough.

Applications used to authenticate, follow predefined logic, and call the services we had explicitly connected to them. AI agents can choose tools, combine information, call other agents, and act with a degree of autonomy.

The identity question is no longer only whether an application can connect. It is what a non-human actor can decide to do once connected.

This also came up in my recent DevUP Talks conversation with Markus Lintuala, Microsoft Security MVP. We discussed what it means when the actors in our systems are increasingly machines, operating at machine speed.

That is the part I think many organizations are still underestimating.

Credentials: Static keys were already a problem

Static credentials have never been a good foundation for cloud security.

They are copied into configuration, shared between services, forgotten in deployment pipelines, and sometimes left active long after the original integration has disappeared. When several workloads use the same key, it also becomes difficult to answer a very basic question:

Who actually performed this action?

Moving a key from an application setting into Azure Key Vault is an improvement. It reduces the risk of exposing the credential in code or plain-text configuration.

But a protected static key is still a static key.

It still needs to be rotated. It can still be shared. It can still be stolen and used by something other than the workload it was intended for.

Where Azure services support identity-based authentication, the stronger pattern is to avoid storing the credential in the first place:

• Use managed identities for workloads running in Azure.
• Use workload identity federation for workloads running outside Azure or across platforms.
• Use Microsoft Entra Agent ID for agents on platforms that support the new agent identity model.
• Use Key Vault and frequent rotation only when a static secret cannot yet be avoided.

The goal is not simply to hide credentials better.

The goal is to remove them wherever possible.

Microsoft describes the same direction in its guidance for workload identity federation and for securing Azure MCP Server deployments.

Blast radius: AI makes it bigger and faster

AI agents do not create the need for least privilege. We needed that long before generative AI.

What changes is the speed, scale, and unpredictability of the actor using the permission.

This becomes very concrete in integration environments. An agent rarely touches only one isolated system. It can become the link between storage, APIs, workflows, messaging, and business systems.

Imagine an AI agent that:

• Reads documents from Azure Storage
• Calls an MCP server
• Triggers a Logic App
• Updates a customer system

What looks like one agent permission can quickly become a cross-system chain of authority.

Each individual permission may look reasonable. The risk appears when the agent can combine them.

A misleading instruction, compromised tool, poisoned tool response, or simply an unexpected decision can turn several individually acceptable permissions into a much larger action chain. The agent can repeat that chain faster than a human and across far more data.

Every agent identity defines a potential blast radius.

If the identity has broad access, the agent has broad access. If several agents share the same identity, we lose both isolation and traceability. If the agent calls a tool that uses an even more privileged backend identity, we may also create a confused deputy: a low-privileged caller borrowing the authority of a much more powerful service.

Authentication alone does not solve any of those problems.

Identity: Every agent needs its own

Microsoft Entra Agent ID introduces identities created specifically for AI agents, together with blueprints for applying common policies and lifecycle controls. Microsoft’s current Agent ID best practices recommend a unique identity for each agent instance, with an assigned sponsor and owner.

That distinction matters.

A production agent should not disappear behind a shared application registration or a generic integration identity. It needs to be visible as an actor in its own right.

That gives us the ability to:

• Assign only the permissions that agent needs
• Trace its actions independently
• Review its access without affecting unrelated agents
• Disable it without breaking every other workload
• Tie its lifecycle to a known business purpose

There can be practical reasons to use a shared project identity during early development. Microsoft Foundry’s earlier publishing model did this for unpublished agents, and agents created under it still share that identity. But as an agent moves toward integration testing or production, its permissions, audit trail, and lifecycle need to become explicit.

Microsoft has moved in the same direction. In Foundry’s new agent model, every new agent gets its own agent identity from the moment it is created.

Sharing an identity may reduce administrative work today.

It also increases the blast radius you will need to explain tomorrow.

Authority: Decide whose permissions the agent is using

Not every agent should operate in the same way.

Some agents act on behalf of a signed-in user. The agent should then remain inside that user’s delegated permissions. If I cannot read a customer record, an agent acting for me should not be able to read it either.

Other agents run unattended. They act on their own schedule or in response to an event, without a human user in the loop. Those agents need their own application permissions and a much stricter definition of what they are allowed to do.

This is an architectural decision, not only an authentication setting.

For every agent, we should be able to answer:

1. Is it acting for a user or under its own authority?
2. Which identity is presented to each downstream system?
3. Which exact tools and operations can it use?
4. What data can it read, change, or send?
5. Who approved that access?
6. Who can disable the agent when something goes wrong?

If those answers are unclear, the agent is not ready for production.

Ownership: Treat agents like employees, but stricter

Agents need the same discipline as employees: a known purpose, a responsible owner, appropriate access, regular reviews, and a clear end to the lifecycle.

When a new employee joins, we know who the manager is. We should know the same for an agent.

Microsoft Entra Agent ID has two roles for this. The sponsor is accountable for why the agent exists. The owner is the technical administrator.

It is similar to the split we already use for people: a manager who answers for the role, and IT who manages the account.

An agent with neither is an agent nobody will answer for when something goes wrong.

But their boundaries need to be tighter. Agents operate continuously, execute at machine speed, and can be influenced by prompts, retrieved data, tool descriptions, and responses from other systems. Unlike a human colleague, an agent does not stop because something feels wrong.

The old identity fundamentals still apply.

The tolerance for weak implementation should not.

Controls: Seven practical places to start

We do not need to invent security again for AI agents.

We need to apply what we already know—more consistently and with much tighter boundaries.

I would start here:

1. Inventory the actors. Know which agents, MCP servers, tools, app registrations, managed identities, and federated identities exist.
2. Remove static credentials. Replace keys and client secrets with managed identities, agent identities, or workload identity federation wherever the target supports it.
3. Separate production identities. Give each production agent an identity that can be audited and disabled independently.
4. Choose the authority model. Be explicit about whether the agent acts on behalf of a user or under its own application permissions.
5. Reduce the permission scope. Assign the smallest suitable role at the narrowest practical resource scope. Avoid broad subscription-level access.
6. Assign ownership and lifecycle. Every agent needs a sponsor, technical owner, review date, and retirement path.
7. Log the complete chain. Record the caller, agent, tool, downstream identity, operation, and result so an investigation can reconstruct what happened.

This is not bureaucracy around AI.

It is what makes AI safe enough to become part of real business processes.

Guardrails: Behavior and authority

In the governance article, I argued that guardrails provide boundaries, not governance.

For identity, there is a second distinction. Guardrails are an important part of agent security, but the term covers different types of controls.

Model-level guardrails can filter harmful content, detect prompt attacks, and inspect inputs and outputs for defined risks. Microsoft Foundry’s guardrails and controls work at this level. At the time of writing, agent guardrails are in preview.

Identity guardrails—such as least privilege and Conditional Access for agents—limit which resources an agent can access and under whose authority.

The important point is defense in depth:

Behavioral guardrails reduce the likelihood of a bad decision. Identity and authorization limit the impact when one still happens.

We need both.

And the identity guardrails only work when the agent actually uses an identity. An agent that connects with an API key bypasses Conditional Access completely.

Drift: The designed identity may not be the identity in use

An architecture diagram may show a managed identity. The deployed configuration may still contain a connection string. The configured identity may have broader permissions than intended, while the running solution may use another identity entirely.

And even when the original design was correct, access and ownership can drift over time.

This is the recurring governance gap we need to understand:

• What was designed
• What was configured
• What is running
• What is actually being used
• What has changed

Identity governance cannot stop when the first role assignment is created. It needs continuous verification throughout the workload lifecycle.

Governance: From findings to direction

This is also how we think about security in Helium, our Continuous Cloud Governance Platform for Azure.

It is the same loop I described in the governance article:

Discover → Understand → Prioritize → Improve → Verify

For identity, the argument is short. A static key is a finding. A static key on a publicly exposed resource, where a managed identity is available but not used, is a priority.

Security findings become useful when they create clarity and direction—not only another list of failed checks.

The next opportunity is to correlate identities and permissions with Azure resources, exposure, activity, ownership, and architectural context. Over time, that could include agent identity observability, effective-permission mapping, and a broader identity graph.

Helium does not replace Microsoft Entra, PIM, Defender, or Sentinel. Its role is to connect their controls and signals with the wider Azure environment so teams can understand what matters first and verify whether it improves.

Accountability: So, who owns the identity?

The answer is the same as it was for the architecture:

We still do.

The agent does not own the permissions, the data it exposes, the action it takes, or the incident it might create. The organization deploying it is still accountable.

The security fundamentals have not disappeared.

Identity. Least privilege. Zero Trust. Ownership. Visibility.

They have simply become more urgent.

Boundaries: Identity is not the only perimeter

Identity tells us who or what is allowed to request access.

It does not answer where the agent can connect, which tools it can reach, or where data can leave.

That is the next layer: boundaries. Azure Network Security Perimeter, gateways, tool access, and data-exfiltration paths all enter the picture.

That is where the next article, Identity Is Not the Only Perimeter, begins. After boundaries, we return to validation: what could the agent do, what did it do, and can we reconstruct the complete chain?

---

Want to get control of identities and static credentials in Azure?

DevUP Helium is our Continuous Cloud Governance Platform for Azure. Learn more about Helium or contact Mattias.