In April 2026, Microsoft announced Entra Agent ID, an identity system built specifically for AI agents — not for people, not for ordinary applications. The official reasoning is direct: as companies put assistive and autonomous agents into production, "they need purpose-built identity constructs to authenticate, authorize, govern, and protect" these nonhuman identities.
The case for a separate identity system gets clearer with one number: according to the 2026 Identity Security Landscape report, from Idira (the Palo Alto Networks brand that inherited CyberArk's base), machine identities today outnumber human ones by a ratio of 109 to 1 inside organizations — and 99 out of 100 companies have already adopted some form of AI agent. Every new agent is, in practice, one more identity that needs an owner, a permission set, and an expiration date.
The problem is that most companies still treat an AI agent like any script: someone sets up a service account, lends it their own password, or uses a key that never expires and that no one else even knows exists. It works for the first month. After that, it becomes exactly the kind of uncontrolled identity the numbers above describe.
An automation with a borrowed password is a problem waiting to happen
Picture the most common path today: someone on the operations team configures an agent to update vendor records, generate a financial report, or respond to a ticketing system. For the agent to work, it needs access — and the fastest route is to give it that person's own password, or a generic service account several people know.
That shortcut creates three problems at once. First, the agent inherits all of that person's access, not just what the task requires — if the person can reach payroll, so can the agent, even if it only needed to touch vendor records. Second, when the person changes roles or leaves the company, no one remembers to review what the agent can still do with that borrowed credential. Third, and worst in an investigation: an action taken by the agent shows up in the logs as if the person had done it, because it was their identity that was used.
Gartner's report on the 2026 digital identity hype cycle, summarized by Silverfort, reaches the same conclusion from the other direction: machine identities are growing faster than companies' ability to discover and govern them, and the firm's recommendation is explicit — AI agents need their own identity, with credentials scoped to what's necessary and a defined human owner, instead of reusing a person's login.
Why "I'll just give it my password" doesn't scale
The most common workaround — lending a personal credential — works for one agent. It doesn't work for ten, and it definitely doesn't work for a hundred. As the 109-machine-identities-to-1-human ratio becomes reality inside the company, the "every agent uses someone's password" model simply can't be audited: there's no central list of who lent what, to which agent, for how long.
On top of that, revoking an agent's access becomes a manual task that's easy to forget. When a project ends and the agent it relied on should stop working, the borrowed credential stays valid until someone, from memory, remembers to change the original person's password — which rarely happens the same day.
The pattern Microsoft itself describes for Entra Agent ID addresses this in a specific way: every agent gets an identity with a clear line of origin (which team created it, for what purpose), the same adaptive access policies as any other corporate identity, and its full authentication and activity history logged for audit — none of it dependent on someone remembering to review it manually.
What has to be in place
Giving an AI agent its own identity means replicating, for it, the same mechanisms that already exist for people — not inventing a separate regime.
Identity coming from the same corporate directory. The agent signs in with an identity created and controlled by the company, from the same place any employee's login comes from — not an account improvised by whoever set up the automation.
Access by role, for agents too. A customer-service agent doesn't need the same reach as a financial-analysis agent. Access is defined by the function the agent performs, not borrowed from whoever created it.
A personal credential per connected tool. When an agent connects to an external system, the credential it uses is its own, not a person's — and it can be revoked individually, without affecting anyone else's access.
Human approval before a sensitive action. Before the agent executes something with real impact — sending a payment, changing a critical record, publishing a document — the action pauses and asks a person to confirm, right inside the conversation.
That's how Skyller treats agent identity: coming from the company directory, with its own scope by role and human approval before sensitive actions, the same way it already works for any member of the team.
What the company gains when the agent has its own identity
The first gain shows up in IT's daily work: knowing how many agents exist, who created them, and what each one can do stops requiring a manual investigation and becomes a queryable list, the same way it already exists for people.
The second gain shows up when something needs to change fast. A project ends, an agent gets retired, a tool gets replaced — turning off that specific agent's access doesn't require changing anyone's password or reviewing everything else that shared credential was unlocking.
The third gain is the most strategic: scaling the number of agents stops being a growing risk. With its own identity and scope, adding agent number 50 is no riskier, from a governance standpoint, than adding agent number 5 — because each one carries only the access its own function requires, with an owner and a history defined from the start.
This also changes the conversation between IT and other departments. Today, requesting a new agent usually runs into an uncomfortable question: "who's going to make sure this doesn't turn into an access problem later?" With identity per agent, the answer stops being a promise and becomes a property of the system itself — the agent is born with a defined scope, an identified owner, and a usage trail, the same way a new employee's account is.
A roadmap to get started
Before putting the next agent into production, it's worth following a simple sequence with the IT team:
- List the agents that already exist in the company today. Including the informal ones — automations someone built to solve a one-off task that are still running months later.
- For each one, identify whose credential it uses. If the answer is "so-and-so's password" or "a generic account several people know," that agent is in the highest-risk category.
- Define the minimum scope each agent actually needs. Not what's most convenient to configure right now, but what the function itself requires.
- Assign a human owner per agent. Someone accountable for that agent's existence, who reviews its access periodically and knows how to retire it once the original reason no longer applies.
- Put human approval on the highest-impact actions. Not everything needs manual confirmation — but anything involving money, critical data, or external communication does.
