AI access control is the practice of deciding, at the moment an AI agent requests an operation, whether that specific operation is permitted. The inputs are attributes of the agent, the party that delegated its authority, the task it is running, the resource the call would touch, and the conditions around it. Workforce IAM and IGA often settle broader questions: who is authenticated and whether the identity should hold the access at all.
A support agent is asked to summarize one customer's history. It resolves that request into a query, and the query it composes carries no customer filter. Every row comes back. Nothing in the authorization path was violated: the token was valid, the scope covered reading customer records, and the API returned what it was asked for.
That gap is the argument for giving agents distinct identities, named owners, and policy controls instead of a borrowed session. Without them there is no subject to evaluate and no record separating the agent from the person who started it. The engineering question is narrower than least privilege: what gets evaluated when an agent asks, and which layer can evaluate it.
Key Takeaways
- Access control for an agent is a decision about a specific call, not a standing entitlement, because the agent chooses the call after the grant exists.
- An agent acting for a person should hold narrowed authority instead of a copy of that person's access. RFC 8693 names the first delegation and the second impersonation.
- IAM answers who is authenticated and IGA answers whether the access should exist. Neither alone necessarily answers whether this specific call is in scope right now.
- The inputs to an agent access decision are attributes of the agent, the delegating human, the task, the resource, and the conditions. A system missing one is guessing.
- Attribution is a control, not a reporting feature. When agent activity resolves to a human's identity in the log, no detection downstream can separate the two.
- Latency pressure is a common reason agent authorization degrades in production, because caching a decision can convert a per-call control into a standing grant.
What Is AI Access Control?
The term describes an authorization decision made per operation, for a non-human requester, using attributes that exist at the moment of the call. NIST's Guide to Attribute Based Access Control (ABAC) Definition and Considerations, SP 800-162, supplies the vocabulary. Access is granted or denied "based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions." It defines a subject as "a human user or NPE, such as a device that issues access requests to perform operations on objects." NPE stands for non-person entity, so these requesters were in scope from the beginning. The change is that they now compose their own requests.
The decision, not the entitlement
An entitlement is a durable fact about an identity: someone approved it, a review confirmed it, and it holds until someone revokes it. An agent request is a transient event. The risky property of AI agent authorization is that the agent picks the operation after the grant exists, from context nobody saw at approval time.
SP 800-162 makes the distinction usable. An operation is "the execution of a function at the request of a subject upon an object," and operations carry no attributes of their own. The risk sits in the object the call resolves to.
An agent granted "read customer records" holds an entitlement. Whether its query returns one row or four million is a property of that object, and no review will see it.
Why AI Agents Need Identity-Based Access Control
AI agent access control starts from a premise workforce access does not share: no human is necessarily present, and the agent may authenticate through its own identity or borrowed authority. An agent runs as something, and when that something is a shared service account, a long-lived API key, or a copy of the launching user's cookie, the decision point has no subject to evaluate beyond a role. Agents sit inside the wider population of non-human identities, and they are the members whose requests cannot be predicted from configuration.
Delegated authority has to be narrowed, not copied
RFC 8693, OAuth 2.0 Token Exchange, draws the line. Under impersonation, principal A "is given all the rights that B has within some defined rights context and is indistinguishable from B in that context." Under delegation, "principal A still has its own identity separate from B," and the specification adds that "in a sense, A is an agent for B."
The mechanism is concrete. A token exchange request carries a subject_token for the party on whose behalf the token is requested and an actor_token for the party receiving the delegated rights. The authorization server decides whether to issue a composite token, and where it does, the JWT carries an act claim naming the actor. Nested act claims record a delegation chain in which "the least recent actor is the most deeply nested."
Hand an agent the user's live session and every log line afterwards says the human did it. Exchange that session for a token whose act claim names the agent, and delegated identity gives an investigator something to follow. That difference decides whether an agentic workforce can be audited.
The mechanics behind delegated agent identity are standardized. The evaluation layer is what most stacks lack.
AI Access Control vs Traditional IAM and Identity Governance
These are not competing layers. IAM supplies the authenticated subject, IGA supplies the policy ceiling and the approval record, and a per-call decision consumes both.
What IAM answers
IAM establishes who holds a credential, whether it is valid, and what class of operation the holder consented to. OAuth 2.0 is an authorization framework and OpenID Connect is the identity layer built on it.
The common objection is that OAuth scopes already cover this. A scope is granted during authorization or token issuance and names a class of operation such as reading tickets. The agent picks the individual operation later, from context the consent screen did not see. Scopes are the outer boundary inside which the decision still has to be made.
What IGA answers
IGA answers whether access should exist. It approves the entitlement, assigns an owner, certifies it on a schedule the organization sets, and revokes it when the answer changes. Role-based access control is the usual shape of that answer, and roles work because job functions stay stable enough to model. The agent identity governance gap is that ownership, approval, and review cadence all assume a subject whose requests stay predictable between reviews.
What neither answers
Neither necessarily evaluates whether this specific call, against this object and for this task, is in scope. In a typical stack, IAM establishes the subject and session, IGA governs the entitlement, and the agent's request arrives after both decisions.
| The question | Typical IAM answer | Typical IGA answer | What an agent request leaves open |
|---|---|---|---|
| Who is making this request? | Authenticates the identity and establishes the token’s subject | Records the identity, its owner, and its review history | Whether the actor is the agent, the person, or a delegated chain containing both |
| Should this access exist? | Enforces the applicable grant and access policy | Approves, certifies, and revokes the entitlement | Whether its breadth matches the task at hand |
| What operation is permitted? | Evaluates scopes, claims, and applicable access policy | Defines the role, entitlement, or policy ceiling | Which object and parameters the operation resolves to |
| On whose authority? | Carries subject and, where supported, delegation claims | Ties the account to an owner of record | Whether that authority was narrowed or copied |
| When was it decided? | At authentication, token issuance, and sometimes during the session | At provisioning, lifecycle events, and review | Whether policy was reevaluated for this specific call |
Key Capabilities of an AI Access Control Framework
Five things have to be true before an authorization layer can answer an agent's request. Treat them as decision inputs for the policy engine.
Identity for the agent
The agent has to be a subject with its own attributes: what it is, who owns it, what it was commissioned to do, and what ceiling applies. Without those, the policy engine can evaluate only the role of whoever launched it.
One rule decides the shape. If the agent's work ends when the person's session ends, narrow a delegated credential from that person's authority and let it expire with the session. If it keeps working after the person steps away, it needs its own identity, a named owner, and a policy ceiling that inherits from nothing.
Scope for the task
A credential bound to a task names its target. The Model Context Protocol (MCP) specification requires clients to implement Resource Indicators for OAuth 2.0 and name the server the token is for. Servers must validate that tokens were issued for them and must not pass client tokens through to upstream APIs. Audience restriction is what makes that work: a token minted for one system fails when it is replayed against another that validates the audience.
Short lifetimes do the rest. A JSON Web Token that expires when the task does behaves like just-in-time access. A secret sitting in a config file behaves like a permanent grant.
Evaluation at call time
SP 800-162 names the components: a Policy Decision Point "computes access decisions," a Policy Enforcement Point "enforces policy decisions in response to a request from a subject," and a Policy Information Point "serves as the retrieval source of attributes." Attribute-based access control fits agents because the inputs are attributes rather than memberships.
Placement is the hard part. An enforcement point at the login path sees one event per session; one at the tool call sees every operation. That is where enterprise-managed authorization earns its keep, with the enterprise scoping the token once instead of each application negotiating its own grant.
A data boundary that holds
An agent scoped to read tickets reaches an attachment, and the attachment holds a payroll export. The ticket API permitted it, because the attachment is a child of a ticket the scope covered. The boundary has to sit on the object the call resolves to, not the endpoint that served it.
That is where AI access control and data security stop being separable programs. Classification attributes travel with the object under ABAC, so the policy governing a payroll file governs it wherever it is reached from.
Attribution back to a human
Record the agent, the accountable human or team, the policy applied, the target, and the outcome. An exchanged token's act chain can preserve the actor and delegation history at the protocol level; the enforcement log must capture the policy, target, and outcome. Lose it, and an investigator reading the log sees an employee who pulled a customer table at 3 a.m.
AI Access Control Challenges for Enterprise Security Teams
Latency and the temptation to cache
A per-call decision adds a round trip to every operation, and agents make a great many operations. The reflexive fix is to cache the decision for the session, which recreates the problem the design was meant to solve. A cached allow is a standing grant with a shorter name. The workable compromise caches the slow, stable lookups, such as the agent's owner or its policy ceiling, and recomputes the part that depends on the object.
Policy written for screens, not calls
SP 800-162 separates a Natural Language Policy, "statements governing management and access of enterprise objects," from the digital policy a mechanism can enforce, warning that natural language policies "may be ambiguous and thus hard to derive in formally actionable elements." Most enterprise access policy is the first kind. It describes what a person may do inside an application, which is unusable as a rule for whether an API call may touch a given row. Translating it is slow work that agent programs underestimate.
Prompt injection belongs here for one reason. Instructions arriving inside retrieved content can change what the agent asks for, so the authorization layer must not take its instructions from the same channel as its data. That bounds what a hijacked request can reach. It does not prevent the hijack.
AI access control and compliance meet at the record, not the rule. Major frameworks do not generally prescribe per-call authorization specifically for AI agents, and claiming a direct requirement where none exists is a fast way to lose an auditor's trust.
Record-keeping is the obligation that does exist. Article 12 of the EU AI Act requires high-risk AI systems to support automatic event logging throughout their lifetime. A SOC 2 Type 2 examination asks a different question: whether an organization’s stated controls operated effectively over the review period. Under either, audit logging that distinguishes the agent from its accountable person can support the evidence trail. A log showing only the person’s identity leaves that attribution incomplete.
How NewCore Enables AI Access Governance
Every challenge above shares one shape. Each is a decision that had to be made somewhere and was made once, at the start, by a system that could not see the call it was authorizing. NewCore's view is that the decision has to move to the call.
An agent carrying standing broad authority is not a productivity feature; it is an access path that authenticates cleanly every time an attacker uses it. That is what makes identity an attack surface rather than a directory.
- Agent Guardian: brokers agent access through Agentic SSO and task-scoped tokens. It mints short-lived, scoped credentials, evaluates real-time policy per call across tools, apps, APIs, and MCP servers, and ties every action back to an accountable human. The agent never holds the tool's standing secret. Risk removed: a grant made at session start that authorizes everything after it.
- Agentic Governance: resolves who is acting, where the authority came from, and what it may do right now, applied inline across governed access requests. An agent inheriting a live user session cannot exceed that user's permissions, an agent running independently sits under a scoped, time-bound policy ceiling, and no agent approves its own elevation. Risk removed: authority scoped to a role when the work is a task.
- Identity Security: runs one policy engine for humans and agents, where unconfigured access defaults to a high-strength baseline, overlapping policies resolve toward the stronger authenticator, and JIT access expires with the grant. Risk removed: two policy models that disagree about the same resource.
This complements the stack instead of displacing it. Your identity provider keeps authenticating people, and each application keeps enforcing its own internal rules. Agent Guardian, agentic governance, and security-aware policies add the agent's identity, the task-scoped credential, and the per-call decision neither layer was built to make.
AI Access Control Best Practices
- 1.Give every agent an identity of its own. A shared service account collapses the attributes a decision needs into one role and makes attribution impossible afterwards.
- 2.Exchange credentials rather than handing them over. Token exchange names the agent as actor. Passing the user's session does not.
- 3.Bind each credential to its target. Name the resource in the request so the token is useless elsewhere, and reject tokens minted for another audience.
- 4.Put the enforcement point where the call is made. A decision point at the login path sees the session begin, but later operations may run without the task, object, or conditions being evaluated again.
- 5.Evaluate the object, not the endpoint. Attach classification attributes to the data so policy follows the record wherever it is reached from.
- 6.Log the actor chain. Record the agent, the delegating human, the policy, and the outcome together. Reconstructing it later is guesswork.
Default to expiry
Set the credential's lifetime from the work, then let it end. A task-scoped grant expires because the task finishes. A role-scoped grant has no such trigger, which is why role-shaped agent credentials outlive their reason for existing.
That points at a scoping rule. Scope by task when the work has a definable end state and a nameable target, which covers most tool-calling and on-behalf-of patterns. Scope by role when the agent performs an open-ended function against a stable set of resources, then treat that role as a ceiling task-scoped credentials are drawn from. Tie review cadence to the risk of the resources in scope and to your control framework.
The Future of AI Access Control and Agentic Identity Governance
Standards bodies are settling the future of AI access control faster than vendors are. RFC 8693 gave delegation a token representation in 2020. The Model Context Protocol's authorization section now requires clients to name the resource a token is for and forbids servers from transiting tokens issued for anything else. ABAC supplied the decision vocabulary a decade before anyone needed it for agents.
The unsolved parts are less glamorous. Policy expression is the bottleneck, because rules written for application screens do not translate into rules about objects and operations. Evidence is the other open problem: nobody has settled what an agent's access record should contain to satisfy an auditor who has never evaluated one.
Frequently Asked Questions
Can several AI agents share one service account?
They can, and the cost arrives during an investigation. A shared account gives the policy engine one set of attributes for several agents with different owners and risk levels. If they do identical work under one owner, that holds for a while. Otherwise, separate identities cost less than forensics later.
How do you audit what an AI agent actually did?
The answer is in the actor chain. An exchanged token's act claim names the agent, and nested claims record prior actors in order. Pair that with enforcement-point logs capturing the target and the policy applied. If your logs carry only an effective user, the agent's actions cannot be separated from the person's.
Should agents be allowed to request escalation at runtime?
Sometimes, and the agent should not approve it. Routing an out-of-policy request to a human works when volume is low and the approver has context to judge it. At higher volumes approvers start clicking through, so failing closed is often the better default, with escalation kept for named exceptions.
What about agents that run on a schedule with no human present?
Those need their own identity and a policy ceiling, because there is no session to inherit from. Commissioning becomes the moment authority is set, and retirement the moment it ends. The per-call decision still applies; what changes is that the delegating party is a policy rather than a live user.
What does an access review look like for an agent?
Less like certifying a list, more like sampling decisions. Reviewing whether an agent should hold an entitlement tells you little when that entitlement is a ceiling. Reviewing what it did inside that ceiling, and whether those calls matched its task, is the version that finds problems. Tooling here is still thin.
