Agent Identity Management: Giving AI Its Own Login

If an AI agent answers email, books jobs, or touches your CRM, it needs its own login. Not your password, not a shared admin account, and not a leftover login from someone who left. Its own identity, with its own permissions, its own owner, and a way to switch it off.

This sounds like paperwork. It is actually the difference between an agent you control and an agent you hope behaves. When something goes wrong, the first question is always which account did what. If the answer is your login, you have a problem. This guide explains agent identity in plain terms, what Microsoft Agent 365 does about it, and the simple version a small business can run without an IT department.

Key takeaways

• Every AI agent should have its own login, its own permissions, and a named human owner.
• Microsoft gives each agent an Agent ID in Microsoft Entra, treated like a user or app identity, with lifecycle controls for inactive and ownerless agents.
• Never let an agent borrow a staff login; shared logins hide activity and keep access alive after the agent should stop.
• Offboarding an agent means disabling its login, revoking connections, stopping schedules, and saving its log.
• Specialist agents from vendors like OpenAI now ship with their own identities and selected system access, which makes per-agent scoping normal rather than advanced.
• A quarterly access review of agent logins takes under an hour and catches most stale-permission problems.

Why agents need their own login

An agent acts inside your tools. It reads inboxes, opens calendars, updates records, and sometimes sends messages as your business. Every one of those actions is recorded under whatever login the agent uses. If it uses yours, its actions look like your actions.

That creates three practical problems. First, you cannot tell what the agent did versus what you did, which makes troubleshooting and audit trails unreliable. Second, the agent inherits all of your permissions, including systems the job never required. Third, when you change your password or leave, the agent either breaks or keeps running on credentials nobody remembers issuing.

A dedicated agent login solves all three. You grant it only the apps, folders, and records the job needs. You name one person who owns it. When the job ends or the owner leaves, you disable one login without touching anyone else. This is the same discipline behind least-privilege access, applied to the account itself.

Small business owners sometimes worry this means buying extra seats for every agent. That depends on the platform. Some vendors give specialist agents their own identities with access to selected company systems at no extra seat, as OpenAI describes for its business Dots for procurement, invoice processing, support, and contracts.

What Agent ID in Microsoft Entra does

Microsoft turned this principle into product with Microsoft Agent 365, which became generally available on May 1, 2026. It is described as a control plane for observing, governing, and securing every agent in an organization. One of its core pieces is Agent ID: each agent gets an identity in Microsoft Entra, the same directory that holds user and app identities.

That single decision unlocks the standard controls IT teams already use. Lifecycle management can expire inactive agents, flag ownerless agents, and block risky ones. Conditional access and risk-based policies can apply to agents the way they apply to people, for example requiring stricter checks for an agent that touches payment or HR systems. Audit and eDiscovery support through Microsoft Purview means agent activity can be searched and held like other business records.

Pricing is public: 15 dollars per user per month, included in the Microsoft 365 E7 plan at 99 dollars per user per month. Agent 365 also works for agents built on other platforms through an SDK, and OpenAI has said it is working with Microsoft to bring its specialist Dots into Agent 365 security controls.

If you do not run Microsoft 365, the product details matter less than the pattern. Whatever directory or admin console you use, ask the same questions: can I see every agent, who owns each one, what can it touch, and can I revoke it in one step.

Service accounts, access packages, and scopes

Identity is only half the job. The other half is scope: what the identity is allowed to touch. Three concepts cover most of it.

A service account is a login that belongs to a workload rather than a person. Your agent login should be one. It gets its own credentials, its own multi-factor setup where supported, and no association with an employee who might leave. If a vendor supports dedicated agent credentials, use them; OpenAI notes that Dots can use credentials without exposing passwords to the model, which is the right direction.

An access package is the bundle of permissions attached to that account: which mailboxes, calendars, drives, CRM objects, and apps it can reach, and whether each is read or write. Start read-only everywhere except the one or two places the agent must write. An agent that drafts invoices does not need delete rights on the customer database. An agent that books appointments does not need your accounting export. Review the package when the job changes, not just when something breaks.

Tool scope is the agent-level version of the same idea. Platforms like Claude Cowork connect to apps such as Slack and Google Drive and can take browser actions like opening sites and filling forms. Those connections should be granted per agent and per job, with plugins and connectors approved rather than open-ended.

Offboarding agents before they go stale

People leave. Jobs end. Pilots get forgotten. Agents keep running unless someone stops them, which is why Microsoft flags ownerless and inactive agents explicitly.

Disable the agent login first so no new actions can run. Then revoke its app connections, API keys, and OAuth grants, because a disabled login with a live API key is not fully offboarded. Confirm scheduled jobs stop: background tasks and cron-style schedules are easy to miss, and a forgotten schedule can keep emailing customers for weeks. Export the activity log and store it with your other business records. Finally, remove shared folders, inboxes, and data the agent no longer needs to see.

Tie this to staff changes. When the person who owns an agent leaves, either assign a new owner the same day or pause the agent until someone takes responsibility. An agent nobody owns is an agent nobody reviews. If you run several agents, the internal assistant service page is a useful reference for how scoped, owned deployments are structured, and the internal assistant workflow shows the shape of a supervised setup.

A 60-minute identity setup for a small team

You do not need Agent 365 to run this discipline. Here is a one-hour version that works on almost any stack.

First, list every agent that touches a business system: chat widgets, voice agents, inbox helpers, booking bots, reporting jobs. For each, write down the login it uses, the apps it can reach, and the person who owns it. Anything running on a personal login goes on the fix list. Second, create a dedicated login or vendor-managed identity for each agent and move its connections over. Reduce each to the smallest access package that still lets the job run. Third, write the owner, scope, and review date into your agent SOP so the information survives staff turnover.

Then set two recurring habits. A monthly five-minute check: is each agent still needed, did it act within scope, any surprises in the log. A quarterly access review: re-confirm every permission, remove what the job outgrew, and disable anything paused for more than a quarter.

One more rule: no agent gets domain-admin, billing-owner, or full-mailbox-delete rights as a convenience. If a task genuinely needs elevated access, such as changing a password, keep that step with a person. OpenAI follows this exact line with Dots, noting that sensitive tasks like changing a password always stay with the user. Convenience permissions are how small incidents become large ones.

FAQ

What is agent identity management?

It means giving every AI agent its own login, permissions, and owner instead of letting it borrow a staff login. Microsoft formalized this with Agent ID in Microsoft Entra, where each agent gets an identity like a user or app, so access can be granted, reviewed, and revoked per agent.

Why should an AI agent not use my login?

A shared login hides what the agent did, keeps working after the agent should stop, and gives the agent every permission you hold. A dedicated agent login limits access to only the apps and data the job needs, and it can be switched off without locking you out of your own accounts.

What does Microsoft Agent 365 do about agent identity?

Agent 365 provides a unified agent registry, an Agent ID for each agent in Microsoft Entra, lifecycle management that flags ownerless or inactive agents, conditional access policies, and audit support. It became generally available on May 1, 2026 at 15 dollars per user per month.

How do you offboard an AI agent?

Disable its login first, revoke its app connections and API keys, confirm scheduled jobs stop firing, export its activity log for your records, then remove data shares. Review offboarding the same day someone who owned the agent leaves, since ownerless agents are a common source of stale access.

Next step

List every agent running in your business and the login each one uses. Anything on a personal login is your first fix. If you want help scoping agent access and ownership before you expand, book a call or start with the free six-step AI automation plan.