AI agent authority requires identity, limits, and revocation

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Newcore's blog post: AI agent access remains unauthorised until identity, limits, and revocation are explicit, even when the agent presents valid credentials.

Why it matters: IAM, PAM, and NHI teams now have to govern agent authority as a policy problem, because authentication alone does not define what an AI agent may do once inside a system.

Context

AI agent authority breaks when organisations treat login proof as the same thing as permission to act. A credential can establish that a system authenticated, but it does not answer who approved the agent, what it may touch, or how the business can stop it later.

The gap becomes sharper when third parties are involved, because the service provider may reject agent traffic even if the user enabled it. That turns agent access into a governance question across task-scoped and just-in-time access, ownership, and revocation, not just a technical authentication flow.

Key questions

Q: How should organizations manage credentials for AI agents?

A: Organizations should transition from hard-coded credentials to runtime-fetched credentials that enhance security by ensuring that tokens are not stored permanently. Utilizing solutions like the MCP Secret Wrapper can help eliminate the risks associated with static credentials.

Q: Why does authentication not prove an AI agent is authorised?

A: Authentication only proves the agent presented a valid secret, certificate, or token. It does not establish what the AI agent is allowed to do, which tool calls it may make, or which data it may reach. Authorisation must be bound separately to the agent’s identity, runtime scope, and human accountable owner, usually through policy, delegated permissions, and revocation controls.

Q: What is the best way to revoke an AI agent's access quickly?

A: The fastest way is a single control action that disables the agent’s identity or its delegated credential at the source, such as deactivating the service account, revoking the token, or disabling the certificate. That should cut off every tool and data path tied to that agent, rather than relying on per-application changes or manual cleanup.

Q: How do per-agent profiles reduce AI access risk?

A: Per-agent profiles reduce AI access risk by giving each agent its own identity, permissions, secrets, logs, and owner. That separation limits blast radius, makes entitlements easier to review, and lets you revoke one agent without disturbing others. It also prevents shared credentials from hiding which agent acted, which is a common audit failure.

Technical breakdown

Why AI agent credentials do not equal authorisation

An AI agent can present a password, session cookie, or OAuth token and still lack legitimate authority. The credential proves that access was possible, not that the organisation on the receiving end consented to that access pattern or that the agent’s scope was reviewed. In enterprise terms, the agent is acting through borrowed identity, often via a user token or a standing secret tied to a tool. The mechanism fails when the organisation assumes authentication is sufficient evidence of intent, ownership, and permitted action. See the Agentic AI Identity Guide.

Practical implication: Treat credential possession and permitted action as separate controls, and require explicit policy before an agent can invoke business systems.

Per-agent profiles and scoped delegation

A per-agent profile is a governance wrapper around an agent’s reach, not a cosmetic label. It defines the tools, transactions, and approval paths that the agent may use, and it should constrain access to the minimum needed for the task. This is where task-scoped delegation matters: the agent should not inherit a broad standing entitlement simply because it can technically use one. Policy at this layer has to be evaluated at action time, not only at login, because the risk emerges when the agent starts making requests.

Practical implication: Model each agent as a separately governed identity with explicit tool scope, approval rules, and default-deny behaviour.

Revocation and auditability for agent actions

Agent governance is incomplete if the organisation cannot switch the agent off cleanly or reconstruct what it did. A valid session that cannot be tied back to an owner, policy decision, and transaction log leaves teams with forensic ambiguity after the fact. Revocation has to be a first-class control, because continuing access after trust is withdrawn is where the operational exposure becomes persistent. Logging must also preserve ownership and policy outcome, not just the fact that a request occurred. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Build agent offboarding and action logging into the same lifecycle so access can be cut and attributed without manual reconstruction.

Threat narrative

Attacker objective: The objective is to make an agent operate with legitimate-looking access while bypassing the organisation’s actual approval and scope controls.

1. Entry occurs when a user connects an AI agent to a service through a valid credential, session, or OAuth token that grants it access to the target system.
2. Escalation happens when the agent inherits or reuses more capability than the receiving organisation intended, because no separate authorisation boundary limits its action scope.
3. Impact follows when the agent can shop, query, or modify records at machine speed while teams have to reconstruct ownership and intent after the fact.

Breaches seen in the wild

• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access reviews are the wrong primary control when an agent’s authority is transient. A review process assumes access exists long enough to be examined, challenged, and re-certified. An AI agent can obtain, use, and shed access within one task flow, so the review artefact arrives after the risk window has already closed. The implication is that governance has to move to issuance and execution time, not rely on retrospective certification.

Borrowed credentials create accountability debt for the organisation that enabled the agent. When an agent acts through a user token or tool secret, the resulting action is hard to attribute unless ownership and policy decisions were recorded at the moment of delegation. That is not just a logging issue. It is a governance failure that leaves no durable answer to who authorised the behaviour and under what limits. The practitioner implication is to treat delegated authority as a named control surface, not an implementation detail.

Identity and authorisation are no longer a single control decision for AI agents. Traditional IAM often bundles authentication, entitlement assignment, and trust in one flow. For agents, those decisions must split apart because a system can authenticate cleanly and still have no standing authority to act on a business process. That is why the enterprise question is not whether the agent signed in, but whether the organisation has explicitly sanctioned what it may do next.

Per-agent governance is becoming the operational unit of control. The market signal is moving toward identity, limits, and off-switches at the agent level rather than broad platform trust. That matters because agent behaviour will keep expanding across workflows while procurement and security teams still need a clean way to scope, pause, and revoke each actor. Practitioners should expect governance models to shift from user-centric entitlement management to agent-centric delegation and enforcement.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Per-agent delegation is becoming the right unit of governance: AI systems are already being treated as actors that need identity, bounded reach, and revocation rather than general user privileges. That means identity programmes will need controls that operate at issuance time and action time, not only during periodic reviews.

The practical shift is from asking whether an agent can authenticate to asking whether it has standing authority for each business action. Organisations that keep modelling AI access as a variant of user access will keep missing the point where permission becomes overreach.

A mature programme will define who owns each agent, how its access is limited, and how it is switched off when its role changes. Those three decisions now sit at the centre of AI governance, not at the edge of it.

For practitioners

• Define each AI agent as a separately governed identity Assign an owner, a purpose, and a narrow task profile before the agent is allowed to act in production systems. See the Agentic AI Identity Guide.
• Separate authentication from authorisation decisions Require an explicit policy decision for each agent action path instead of treating login success as permission to proceed.
• Replace standing tool secrets with short-lived delegated access Broker access through a gateway or control layer so the agent never holds long-lived credentials for downstream systems.
• Make revocation a single-step control Ensure you can disable an agent at one control point and have the change take effect on its next request without manual cleanup.
• Log agent actions against the owner and policy outcome Capture which agent acted, which policy allowed or blocked it, and who owns the delegated authority so audits do not depend on reconstruction.

Key takeaways

• AI agents change the identity problem by separating valid access from legitimate authority, which makes simple authentication checks insufficient.
• The operational risk is not only over-permissioned access, but also the inability to attribute and revoke what the agent does after delegation.
• Governance needs to shift toward per-agent ownership, bounded scope, and immediate revocation so that access decisions happen before action, not after review.

Related NHI Mgmt Group resources: Top 10 Agentic AI Identity Issues · Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agent Authorisation Guide

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Delegated authority: Delegated authority is permission given to one identity to act on behalf of another within defined limits. In identity systems, it enables an agent, user, or service account to perform approved actions without owning the underlying rights, using scoped tokens, roles, or approvals to constrain access and accountability.
• Per-Agent Profile: A per-agent profile is a dedicated identity record for one AI agent. It holds that agent’s permissions, credentials, ownership, logging, and runtime constraints so access can be granted, reviewed, and revoked independently instead of being shared across multiple agents or workloads.
• Brokered Access: Brokered access is a model where the user or workload proves identity to an intermediate control plane that issues short-lived access instead of exposing a reusable secret. For privileged operations, this shifts governance from secret storage to session control, auditability, and timely revocation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.