Most AI agent conversations start in the wrong place.
The first question is usually, “What can the agent do?”
Can it answer questions? Can it search documents? Can it open tickets? Can it call APIs? Can it update records? Can it trigger a workflow?
Those are useful questions, but they are not the first questions infrastructure and security teams need answered.
The better first question is:
Who is this thing when it acts?
That question changes the architecture conversation. A chatbot is something a user talks to. An agent is something that can act inside your environment. Once an AI system can retrieve data, call tools, use connectors, invoke APIs, or trigger workflows, it stops being only a conversational feature.
It becomes a non-human actor.
That means it needs an identity model.
Microsoft’s current AI agent governance guidance is direct on this point: every agent should operate under a distinct identity, and agent actions must be attributable and enforceable to a unique identity.
That is the right framing for enterprise teams.
Treat AI agents like service principals, not chatbots.
Not because every agent should be implemented with a generic service principal. Microsoft Entra Agent ID now provides purpose-built agent identities, and Microsoft’s planning guidance says standard service principals and regular user accounts are not recommended for most AI agents. The point is the operating model: agents need ownership, scoped access, auditability, lifecycle controls, and a clean disable path.
That is infrastructure language.
That is security language.
That is the language enterprises already use to govern non-human access.
Why the Chatbot Framing Breaks Down
A chatbot mindset works when the system is mostly a user interface.
The user asks a question.
The system responds.
The risk is mostly in the answer quality, data grounding, and user experience.
That is not the same problem as an agent that can act.
An enterprise agent might be able to:
- query Microsoft Graph
- search SharePoint
- inspect a ticket queue
- update a record in a business application
- invoke a workflow
- call an internal API
- create a change request
- send a notification
- call another agent
At that point, the chat window is not the security boundary.
The identity is.
If the identity is vague, shared, over-permissioned, or hidden behind a connector, the organization has a governance problem. The agent might look like a chatbot to the user, but to the environment it behaves like a workload.
That distinction matters during normal operations, and it matters even more during an incident.
| Question | Chatbot Mindset | Principal Mindset |
|---|---|---|
| What is it? | A conversational interface | A non-human actor |
| Who owns it? | The team that built the bot | Business sponsor plus technical owner |
| How does it access systems? | Through connectors or plugins | Through scoped permissions tied to an identity |
| How is it audited? | Conversation history | Sign-in logs, audit logs, tool-call traces, and downstream resource logs |
| How is it disabled? | Unpublish the bot | Disable or block the identity and revoke access |
| How is access reviewed? | Usually ad hoc | Scheduled review, expiration, and sponsor approval |
| What happens during an incident? | Find the bot owner | Contain the identity, revoke tokens, inspect grants, and review activity |
The operational model is completely different.
A chatbot can be managed like a product feature.
An agent needs to be governed like a workload identity.
The Control Model at a Glance
The important thing to notice in this diagram is where the identity sits. It is not attached to the chat window. It sits between the agent runtime and the resources the agent can access.
The user interface may be where people experience the agent.
The identity is where the enterprise controls the agent.
That is the difference between a demo and a governable production system.
Treat Agents Like Non-Human Principals
Infrastructure and security teams already understand non-human identities.
They understand application registrations, managed identities, service principals, workload identities, secrets, certificates, federated credentials, RBAC assignments, API permissions, sign-in logs, and access reviews.
AI agents should enter that same governance conversation.
The label is different. The control requirements are familiar.
An agent identity should answer practical questions:
- What is the agent allowed to access?
- Which permissions are granted directly to the agent?
- Which permissions are inherited from a blueprint or shared configuration?
- Is the agent acting as itself or on behalf of a signed-in user?
- Who is the business sponsor?
- Who is the technical owner?
- What logs show what the agent did?
- How do we disable it without breaking unrelated systems?
- How do we remove it when the business need goes away?
Those are not chatbot questions.
Those are principal questions.
The Service Principal Analogy Is Useful, but Not Perfect
“Treat agents like service principals” is a mental model, not a license to reuse old patterns blindly.
The wrong implementation would be to create one generic application identity called something like ai-agent-service, grant it broad access, and let every agent use it.
That is not governance. That is shared-account thinking with a newer name.
The better principle is:
Every logical agent needs a durable, attributable, governable identity.
In Microsoft environments, the current direction is Microsoft Entra Agent ID. Microsoft describes agent identities as identity accounts in Microsoft Entra ID that provide unique identification and authentication capabilities for AI agents. Microsoft also describes agent identities as a specialized service principal model with agent-specific behavior.
That distinction matters.
A classic service principal is a familiar infrastructure concept.
An agent identity is a purpose-built identity construct for agentic workloads.
The analogy helps security and infrastructure teams understand the operating model, but the implementation should use the right identity type when the platform supports it.
One Identity per Logical Agent
The default pattern should be one identity per logical agent.
Not one identity per prompt.
Not one identity per chat session.
Not one identity per container replica.
Not one shared identity for every agent in the company.
A logical agent is a unit of ownership, permission, auditability, and lifecycle.
Use this test:
Would I need to investigate, disable, approve, or review this agent independently?
If the answer is yes, the agent needs its own identity.
That means a service desk triage agent, a finance reconciliation agent, an HR onboarding agent, and a security investigation agent should not casually share the same identity. They have different data sensitivity, different owners, different approval paths, and different incident blast radius.
At the same time, ten replicas of the same service desk triage agent running behind a scale-out deployment usually do not need ten separate identities. Scale-out is a runtime concern. Identity should follow the logical agent boundary, not the number of running processes.
Identity Is Where Least Privilege Becomes Enforceable
Least privilege is difficult to enforce when the agent is just “the chatbot.”
It becomes enforceable when the agent has a real identity.
Once the agent has a distinct identity, security teams can ask:
| Control Area | Practical Question |
|---|---|
| Access | What permissions does this agent have? |
| Scope | Are those permissions limited to the agent’s actual job? |
| Consent | Who approved the API permissions or RBAC assignment? |
| Ownership | Who sponsors the business purpose? |
| Operations | Who maintains the agent runtime and integrations? |
| Monitoring | Where do sign-in logs, audit logs, and tool-call logs land? |
| Response | How do we block the agent during an incident? |
| Lifecycle | When does access expire or get reviewed? |
Without a unique identity, those questions become guesswork.
With a unique identity, they become normal IAM and operations work.
That is the point.
Autonomous and Delegated Agents Need Different Access Thinking
Not all agents act the same way.
Some agents act autonomously. They run in the background, respond to events, process queues, or perform scheduled work. There may be no human user present.
Other agents act interactively. A signed-in user asks the agent to do something, and the agent acts within that user’s context or on behalf of that user.
Those two modes should not be blurred together.
| Operation Pattern | What It Means | Access Risk |
|---|---|---|
| Autonomous | The agent acts as itself with no signed-in user present | The agent’s own permissions define the blast radius |
| Interactive / delegated | The agent acts with a user involved | The design must preserve user context and avoid silent privilege expansion |
| Mixed | The same agent has both background and user-assisted behaviors | Each flow needs separate access review and validation |
A common mistake is assuming that a chat interface means the agent is always acting on behalf of the user.
That is not always true.
A support agent might answer a technician’s question interactively during the day and run queue classification autonomously overnight. Those are different access paths and should be reviewed separately.
Do Not Use Human Accounts as a Shortcut
Creating a normal user account for an agent may feel convenient at first.
It can also create long-term identity debt.
Human accounts bring human assumptions:
- passwords
- MFA expectations
- interactive sign-in behavior
- manager relationships
- mailbox and collaboration defaults
- HR lifecycle assumptions
- user-focused access reviews
Agents do not behave like employees.
Some agents do need user-like capabilities. For example, a digital worker may need a mailbox, Teams presence, or access to systems that require a user object. Microsoft’s Agent ID model accounts for that with an optional agent user account that is paired with the agent identity.
That is very different from creating a regular user and pretending it is an agent.
The cleaner rule is:
| Need | Better Pattern |
|---|---|
| Agent calls APIs as itself | Agent identity |
| Agent acts on behalf of a signed-in user | Agent identity with delegated flow |
| Agent needs mailbox or Teams-style user object | Agent identity plus paired agent user account |
| Existing custom agent uses an app registration | Plan migration where Agent ID is supported |
| Agent uses a shared human account | Redesign the identity model |
The exception should not become the default.
Example: Service Desk Triage Agent
Consider a service desk triage agent.
It reads new tickets, classifies urgency, suggests routing, searches the knowledge base, and occasionally invokes an automation workflow to gather diagnostic information.
A weak design would use a generic app registration called automation-service, grant broad API permissions, and let multiple agents share it.
A stronger design would define the agent as a governed identity-bearing workload.
| Design Element | Example |
|---|---|
| Agent name | Service Desk Triage Agent |
| Agent identity | agent-svcdesk-triage-prod |
| Business sponsor | Director of Support Operations |
| Technical owner | AI Platform Engineering |
| Operation pattern | Autonomous for queue classification; interactive for technician-assisted workflows |
| Data sensitivity | Internal operational data and limited user metadata |
| Allowed access | Ticketing API read/update, knowledge base search, diagnostic workflow invocation |
| Denied by default | Broad mailbox access, privileged directory roles, tenant-wide Graph write permissions |
| Logs required | Agent sign-in logs, audit logs, ticket updates, workflow execution logs |
| Review cadence | Quarterly access review; shorter review for elevated exceptions |
| Disable path | Block or disable the agent identity without affecting unrelated agents |
That design can be explained to IAM.
It can be reviewed by security.
It can be operated by platform engineering.
It can be understood by the business sponsor.
That is the value of the principal mindset.
What Infrastructure and Security Teams Should Standardize
Before agent adoption scales, enterprises need a minimum identity standard.
At a practical level, every production agent should have:
- a unique agent identity
- a business sponsor
- a technical owner
- a documented purpose
- a classification for data sensitivity
- a defined operation pattern
- approved permissions
- required logs
- an incident disable path
- a review and retirement process
That standard does not need to slow every pilot to a halt.
But it should define the difference between experimentation and production.
A proof of concept might be manually reviewed.
A production agent needs identity governance.
Conclusion
The fastest way to under-govern AI agents is to keep calling them chatbots after they start taking action.
A chatbot can answer.
An agent can operate.
That difference changes the architecture.
For infrastructure, IAM, and security teams, the right mental model is to treat agents as non-human principals with scoped access, ownership, observability, and lifecycle controls. In Microsoft environments, Microsoft Entra Agent ID gives that model a purpose-built implementation path, but the broader principle applies beyond one product.
Every agent that can act needs a real identity.
Not just a prompt.
Not just a connector.
Not just a bot registration.
A governable identity.
That is where agent security becomes operational.
