Agentic IAM extends identity and access management to AI agents as principals in their own right: software that authenticates, holds permissions, and chooses its next action at runtime. It covers the identity the agent presents, the credential it carries, the authorization decision taken at each call, and the record of what it did.
Somebody on a platform team handed a coding assistant a token for one repository in March. It now opens pull requests across forty, because the token was scoped to the organization and nobody read the scope. Nothing failed. The identity environment acquired another identity that never passed through onboarding, alongside the humans, machines, service accounts, and automations already there, and the token is still valid.
The break shows up first in the session.
Key Takeaways
- Agentic IAM asks the three questions identity has always asked: who is this, what may it do right now, and what did it do. The principal answering them picks its own next call instead of following a fixed path.
- Workforce IAM often settles most access decisions at sign-in or session start. An autonomous agent invalidates that assumption by choosing its actions after the session begins.
- An agent running under the identity of the person who launched it produces a log naming a human who did not take the action.
- Standing, long-lived credentials are the specific artifact that makes agent access dangerous. Short-lived credentials scoped to a task shrink the exposure without removing the need to know which agent held one.
- Adoption starts by finding the agents that already hold credentials, because most enterprises acquired them one team at a time with no identity decision recorded.
- Agentic IAM extends an identity stack rather than replacing it. The identity provider keeps authenticating the workforce, and the governance tool keeps running the certification and lifecycle processes already in place.
What Is Agentic IAM?
Agentic IAM is the identity, credential, authorization, and audit layer for AI agents that act on their own initiative inside enterprise systems. The definition has an edge worth holding: it applies when the software chooses which call to make.
A scheduled job running the same three API calls every night is a workload, and workload identity covers it. An agent that reads a ticket, judges a refund justified, and calls the billing API is making a choice. A grant that was safe for the job is no longer safe here.
The agentic workforce sits inside the wider non-human population an enterprise already carries, and the taxonomy of that population is a separate subject. What distinguishes the agent within it is runtime discretion.
Two adjacent problems sit outside the term. Whether an agent behaves well is a model question, and oversight, ownership, and policy review belong to a governance program running alongside.
The agent becomes the principal
When the coding assistant opens a pull request, three parties could be the principal: the engineer who started it, the platform hosting it, or the agent. Workforce IAM has an answer for the first only. The agent presents a token, the target system reads the token's subject, and whatever that subject is becomes the accountable party in the record.
If the subject is the engineer, the record shows commits the engineer did not write. A delegated identity is a defensible answer while the agent works inside that engineer's session and existing reach. It stops being the answer once the agent carries on after the engineer closes the laptop.
From Workforce IAM to Agentic IAM
Workforce identity and access management was designed around a person and a session. Someone signs in, the identity provider checks who they are, and the session that follows inherits the trust from that check.
Every downstream control leans on it. Conditional access evaluates the login. Entitlements attach to a role a manager approved. The log names the human the session belongs to.
Teams now writing requirements for agentic AI IAM are describing a change in the principal rather than an upgrade to the tooling. The agent authenticates once, then makes hundreds of calls the original check never anticipated, because it selects them while it runs.
The usual objection is that an agent is another workload, and service account management and OAuth clients already handle workloads. The difference is the path. A script follows a fixed path, so a grant that fits the path fits every execution. An agent chooses its path, so the same grant authorizes actions nobody enumerated.
A service account with commit rights across forty repositories was over-provisioned and harmless while a script used two of them. Hand it to something that reads its own scope and decides what to do next, and the over-provisioning becomes reachable.
| Control | What it assumes about a person | What breaks for an agent |
|---|---|---|
| Authentication | Most access decisions are settled at sign-in or session start | The next call may target a system the sign-in never covered |
| Authorization | A grant approved once fits the work the role implies | The agent picks actions inside that grant which nobody enumerated |
| Credential | A credential tied to a person who can respond to a challenge | A token in a configuration file, with no one to challenge and nothing to prompt |
| Lifecycle | A joiner, mover, or leaver event arrives from an HR system | No HR event exists, so the credential outlives the project that needed it |
| Attribution | One session, one human, one name in the log | Activity lands under the sponsoring user unless the agent holds its own identity |
Every row is a control that kept working while the assumption underneath it stopped being true. Restoring the assumption takes four things, and most enterprises hold them in pieces.
The Core Capabilities of an Agentic IAM Platform
IAM for agentic AI is workforce IAM with the order changed: the identity has to exist before any session, and the authorization has to survive after one. Certification and entitlement review stay in the governance tool that already runs them.
Agentic AI IAM architecture and components
Four components carry the work, and each is concrete enough to look for in a product:
- An identity registry holding agents as records, each with an owner, a purpose, and a state that can be set to revoked.
- A credential issuer minting short-lived tokens on request instead of distributing standing secrets.
- A policy decision point reachable at the moment of the call, not only at the start of the session.
- An audit path recording the agent, the authority it acted under, the target, and the outcome.
Three out of four leaves a familiar gap: an agent whose authority was settled where nobody can revoke it.
Identity and credential issuance
OAuth 2.0 is an authorization framework: it lets a client obtain limited access to a service, either on a resource owner's behalf or on its own behalf. OpenID Connect adds an identity layer for authentication. Agent deployments may use both, but handing an agent a token does not by itself establish ownership, delegation, or accountability.
A client credentials grant gives the agent a token for its own account, with the agent acting on its own behalf. It carries no statement about a user it might be acting for.
RFC 8693, OAuth 2.0 Token Exchange, supplies the missing half. A client presents a subject_token for the party on whose behalf the request is made, plus an optional actor_token for the party that will act. The server can return a composite token whose act claim names the actor while sub still names the subject. The audience and resource parameters name the target service, and scope narrows what the issued token may do there.
Delegation there keeps the actor's identity separate from the subject's; impersonation makes the two indistinguishable, which the RFC says outright. Short-lived tokens issued per task are the working form of just-in-time access for a principal with no reason to hold anything between tasks.
Decision rule. Narrow a user's authority through token exchange while the agent acts inside that user's session and existing reach. Issue the agent its own identity when it carries authority no single user has, or when it keeps acting after every user session has closed. An agent on a schedule is already in the second case, whatever the launch button suggested.
Authorization at call time
NIST SP 800-207 sets out zero trust architecture. One of its tenets carries the argument: "All resource authentication and authorization are dynamic and strictly enforced before access is allowed." Another tenet holds that access to individual enterprise resources "is granted on a per-session basis", and the document treats authentication and authorization as discrete functions performed before a session is established.
Published in August 2020, it is an architecture document rather than a mandate, and it predates enterprise agents. The tenet transfers anyway, because the session is the wrong unit of measurement here. Between its first call and its hundredth, the agent has chosen new targets.
AI agent authorization taken at the call is where the decision belongs. The call is the first point at which the agent's identity, its authority, the target, and the conditions are all present together.
The Model Context Protocol (MCP) specification, revision 2026-07-28, makes authorization optional for implementations and specific where it is used. A protected MCP server acts as an OAuth 2.1 resource server, and it must validate that a token was issued specifically for it as the intended audience.
MCP's enterprise-managed authorization extension moves the decision further back, to the identity provider. The client obtains an identity assertion there, then exchanges it for an access token at the MCP server's authorization server. The decision belongs to the enterprise rather than to each application.
Audit and attribution
This is the component teams discover last. An agent authenticating as the person who launched it produces audit logging that is accurate about the credential and wrong about the actor. A composite token can preserve that distinction in the record: sub names the user whose authority was drawn on, while act names the agent. Without a distinct identity, the incident review becomes an engineer explaining forty pull requests they never opened.
How Organizations Adopt Agentic IAM
Adoption starts mid-stream. The agents are already running, which makes discovery the first move.
Start where agents already have credentials
Agents tend to arrive the way SaaS did, one team at a time, with no identity decision recorded. The population is easier to find through credentials than through any register. Look for OAuth client grants nobody re-approved, personal access tokens in CI configuration, and API keys in a secrets manager with no owner attached. Traditional identity governance strains against this population, and the agent identity governance gap is where that strain shows.
Decision rule. When agents already hold credentials, close the tap before cleaning the pool. Route new agent access through a broker first, then work backwards through what is already issued, starting with whatever reaches the most sensitive system. Inventory alone is not a sequence. By the time the list is complete, new credentials may already have made it stale.
Sequencing the work
- 1.Find the credentials. Enumerate tokens, client grants, and keys across source control, CI, secrets managers, and SaaS admin consoles, recording which agent and which human each belongs to.
- 2.Give each agent an identity and an owner. A record with a purpose and a named owner is what later lets someone revoke it without guessing what breaks.
- 3.Move issuance to short-lived tokens. Start with agents whose reach crosses systems, since those grants had no composite review.
- 4.Move the decision to the call. Put a policy decision in the path of the request, so scope can change between one call and the next.
Oversight structure, policy review, and who signs for an agent belong to the governance program running beside this work. The sequence above does not wait for it.
Real-World Agentic IAM Use Cases
Engineering automation
An internal research agent chains three MCP servers: a wiki, a ticket system, and a data warehouse. Each connection was authorized separately and each looked reasonable alone. The composite reach was authorized by nobody.
The agent can read a design document, find the customer named in a linked ticket, and pull that customer's rows from the warehouse in one sequence. Per-connection approval produced a reach no per-connection reviewer saw.
Customer operations
A support agent reads a ticket, queries the CRM, and issues a refund, all inside one unbroken session. The refund is the step that matters. In a workforce model it would have sat behind an approval tied to a human role; here the agent inherited the role.
A prompt-injected instruction in the ticket body reaches the same refund API with the same valid permissions, which is why the decision has to be taken at the call. Treating the agent as the synthetic employee it functions as gets scoping and revocation asked about at the right time.
Security operations
A triage agent reads the SIEM, judges an endpoint compromised, and calls the isolation API. The read grant is low risk. The isolation grant can take a production host off the network.
Both arrived in one service account because the runbook needed both, and the boundary crossed is the one between observing and acting. The agentic IAM answer keeps the read grant standing and issues the isolation grant per task, so it expires with the task that justified it.
How New Core Is Building the Agentic IAM Platform
Most enterprises already hold pieces of what the components above describe. A token service in one team, a service account whose purpose nobody wrote down, a log that credits agent activity to whoever started the agent. NewCore's view is that agentic IAM is an assembly problem before it is a product problem. The primitives exist, scattered across systems each bought for a human workforce, and the work is joining them into one path an agent can be made to travel.
- Agentic Governance: Agentic SSO, Task-Scoped Tokens, AI Inventory, and Machine-Speed Security, applied inline across governed agent access requests. Permissions scoped to the job in front of the agent stop being useful between jobs.
- Agent Guardian: controlled agent execution across tools, apps, APIs, and MCP servers. It mints short-lived, scoped credentials and evaluates policy per call, so authorization is not settled at session start and left alone for the two hundred calls that follow.
- Identity Discovery: continuously indexes every identity, account, credential, and access relationship into one current identity record, with a graph of how access was acquired. It surfaces the agent nobody in identity knew about.
The positioning is complementary: the identity provider continues authenticating the workforce, and the governance suite continues running the certification and lifecycle processes already in place. Agentic Governance adds one policy model spanning humans, on-behalf-of actions, delegated agents, and autonomous workloads. Agent Guardian adds the scoped credential and the per-call decision, and Identity Discovery adds the population both of those act on. Built in, not bolted on, for the principal the other two systems were not designed to hold.
The three questions have not changed. The principal has.
Your environment already has agents acting under someone's authority. Give them identities you can scope and revoke. Request a Demo →
Frequently Asked Questions
Is an OAuth client credentials grant enough for an agent?
For a narrow, single-purpose agent, often yes. The grant gives the agent a token in its own right, which beats borrowing a user's. The agent is then acting on its own behalf, with no statement about any user it acts for, so one working for different people at different times becomes hard to attribute. That is the case token exchange was designed for.
How long should an agent's credential live?
There is no defensible universal number. It depends on what the agent can reach and how fast your systems can reissue. Measure against the task instead of the clock: if a credential outlives the unit of work it was issued for, the extra lifetime is exposure with no purpose. Tie the limit to your own control framework instead of a vendor default.
Does agentic IAM require replacing the identity provider?
No. The identity provider keeps doing the job it does well, which is authenticating people and federating them into applications. What it was not built to do is issue and evaluate authority for an identity with no HR record and no human present to respond to a challenge. That gap is additive; closing it does not require a migration.
What breaks first when agents are added to a workforce IAM stack?
Attribution, usually before authorization. An over-broad grant gets noticed eventually, because something visible happens. The logging problem surfaces during an investigation. By then agent activity has been recorded under a human name for months, with no way to separate the two after the fact.
Is there a standard for agentic IAM yet?
Not as a single specification, and it would be premature to claim one. The pieces are established and in use: OAuth 2.0 and OpenID Connect for grants and identity, RFC 8693 for delegated and narrowed authority, and the Model Context Protocol's authorization section for agent-to-tool access. In that last one, authorization stays optional for implementers. Anyone describing a finished standard here is ahead of the evidence.
