peach_fotolia - stock.adobe.com
Secure your agentic AI with identity management
AI agents are an invisible workforce that ushers in a new generation of vulnerabilities and threats. Enforce strict identity management to secure these agents.
The industry's embrace of AI is fueling the deployment of millions of AI agents that interact with corporate databases, APIs and even inboxes. To complete tasks, every AI agent or automated system requires a machine identity to operate with delegated authority.
These agents form an invisible workforce that poses an often-overlooked security vulnerability: Most businesses currently lack centralized oversight to track who owns digital agents or what sensitive data they are authorized to access. This is a significant blind spot in corporate governance. Rogue agents lead to data loss that's difficult to detect, resulting in unauthorized payments, incidents and severe penalties under privacy regulations.
To that end, identity underpins agentic AI security. It should underscore every decision about whether or not to deploy any and every agent, rather than just part of the implementation work that follows. Before any agent receives access to a business system, leaders should answer four questions: Who owns the agent, what it can access, what it can do and whether they can prove it did.
Why existing Identity and Access Management is not enough
Identity and access management (IAM) as an IT capability was designed around employees. When a person joins, changes roles or leaves a company, HR records each change and updates access permissions for applications and data. In a well-governed business, these are reviewed regularly.
AI agents change the equation. Tooling built for human movement was never designed to discover, attribute or govern identities at the scale these systems are being deployed. For example, an agent can be created by an API call, make thousands of requests and end within minutes -- long before any review process can intervene.
Agents are also different from the service accounts that traditional IAM teams manage. A service account runs fixed code: Teams know in advance all the sources it will access and actions it will take. But an agent is given a goal and decides for itself which tools and data to use. Developers usually respond by giving the agent a broad role and a long-lived API key so that it doesn't fail partway through a task.
That practice is dangerous because agents often read untrusted content. For example, an email or web page can include hidden instructions, which might be malicious. An agent that follows them can use its legitimate permissions on an attacker's behalf.
Because agentic AI privilege ushers in a variety of distinctive risks, the CISA, the NSA and four allied agencies published guidance on May 1, 2026 -- "Careful Adoption of Agentic AI Services" -- that ranks privilege first among its five categories of risk. It warns that agents combine permissions across many tools. A single compromised agent can give an attacker wide access. It also expects each agent to have a verified, cryptographically anchored identity with short-lived credentials.
Extend the Identity Access Management you have
None of this means businesses should replace their current identity provider, user directory or governance workflows. Vendors have instead added the AI agent as a new type of identity alongside users and applications, such as in the following tools:
- Microsoft Entra Agent ID. Creates each agent identity from a blueprint, which is a template for its credentials and policies. Disabling a blueprint stops all agents created from it. When an agent's human sponsor leaves the business, sponsorship transfers automatically to that person's manager.
- Google's Agent Identity. Gives each agent its own ID as an alternative to shared service accounts; administrators assign permissions directly to that ID. A native IAM type based on the open source SPIFFE standard.
- Okta for AI Agents. Registers agents in Universal Directory with an owner and a managed lifecycle. Okta has made Agent SSO generally available, which builds the open Cross App Access standard into its core single sign-on and issues short-lived tokens in place of stored credentials. Platform-independent.
Businesses should, however, urgently replace outdated security practices, such as permanent digital keys, shared generic accounts and AI agents programmed to impersonate human employees. Relying exclusively on traditional password vaults, for example, is a vulnerability, because it can release a password but cannot verify that agents' actions align with their authorized use.
Ultimately, as operations span multiple cloud providers, consider investing in a dedicated, cross-platform identity management tool to ensure seamless security oversight free from any single vendor's ecosystem.
5 agentic AI identity management recommendations
Building out robust IAM for AI agents is an absolute necessity for businesses using agentic AI. These five tips can help.
1. Give every agent a named human owner
Staff can now build agents with low-code tools, many of which run without centralized approval. When the person who built that process leaves, their agent might continue to run with no one responsible for it. So, at a minimum, start with an inventory of agents and require a named owner for each one. When buying software or services, ensure the product cannot create or run an agent without an owner.
2. Give each agent its own scoped, short-lived credentials
An agent should not share an account with other agents or use an employee's login, even when performing tasks on their behalf. If an agent uses the employee's login, you cannot revoke the agent without locking out the employee. Meanwhile, the activity logs show only the employee's name. Credentials should be issued for a specific task and expire within minutes. A stolen credential of that kind is of little use to an attacker; a permanent key gives access for months.
3. Enforce least privilege and limit delegated authority
An agent should start with no permissions and receive only what the task needs, incrementally and limited by time, resources and actions. Similarly, when an agent retrieves documents to answer a question, it should see only what the person asking is allowed to see. Otherwise, a routine question can expose sensitive information such as HR or financial files. Irreversible or high-value actions, such as payments and deletions, should require human oversight or approval. The client-initiated backchannel authentication standard supports this by sending an approval request to the owner's phone while the agent waits.
4. Keep an audit trail of the whole chain
When one agent delegates to another, do not log only the last agent in the chain--the one taking the action--because then the original human request might be lost. Keep the log outside the agent's own environment so that a compromised agent cannot alter it.
5. Monitor continuously and be able to revoke at once
A check at login is not enough because malicious actors could manipulate an agent after authentication. Therefore, monitoring should compare behavior with the agent's normal pattern, such as the volume of data it moves and the hours at which it works. Revocation of permissions must end every token and session the agent has running. Okta's universal logout feature and Microsoft's ability to disable an Entra blueprint are examples. Decide now who has the authority to stop an agent in the middle of the night.
Donald Farmer is a data strategist with 30+ years of experience, including as a product team leader at Microsoft and Qlik. He advises global clients on data, analytics, AI and innovation strategy, with expertise spanning from tech giants to startups. He lives in an experimental woodland home near Seattle.
