Agentic access governance needs a new framework for AI identities

At a glance

What this is: This is Oasis Security’s framework for governing agentic access, centered on discovery, ownership, credential hygiene, least privilege, monitoring, and continuous improvement.

Why it matters: It matters because IAM teams now have to govern AI agents as non-human identities, while also protecting the human and machine identity controls those agents depend on.

By the numbers:

• Our Fortune 500 customers data shows AI-agent adoption up 840x YoY from July 2024 to July 2025.
• At this pace, large enterprises will see agents outnumber employees by the end 2025.

👉 Read Oasis Security’s framework for governing agentic access

Context

Agentic access governance is the discipline of assigning, constraining, and monitoring access for AI agents that can act at runtime without behaving like human users. Oasis Security argues that traditional IAM models fail here because they assume identities are static, human-controlled, and auditable in ordinary review cycles. That assumption no longer holds when agents can spawn sessions, call APIs, and delegate tasks dynamically.

The governance gap is not the existence of AI tools. It is unmanaged access across copilot, plugin, connector, and automation identities that can accumulate privilege faster than organisations can review it. That is why the article centres on discovery, ownership, credential lifecycle, access security, vendor trust, monitoring, and continuous improvement as one operating model rather than disconnected controls.

Key questions

Q: How should security teams govern AI agents that access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, task-scoped privilege, credential lifecycle controls, and runtime monitoring. The practical test is whether the organisation can inventory each agent, explain what it can touch, and revoke access cleanly when the workflow ends. If not, the agent is operating outside manageable identity governance.

Q: Why do AI agents create more access risk than normal automation?

A: AI agents create more access risk because they can make runtime decisions, select tools, and chain actions without being bound to a fixed script. That makes privilege harder to define at provisioning time and easier to overextend in practice. The risk is not automation itself, but delegated behaviour that outpaces human review and audit cycles.

Q: What breaks when agent identities rely on hardcoded API keys?

A: Hardcoded API keys turn agent access into long-lived credential exposure, which increases the chance of reuse, leakage, and difficult revocation. Once the key is embedded in pipelines or notebooks, accountability and lifecycle control become fragmented. Practitioners lose the ability to trace which agent used the credential and when it should have been retired.

Q: How do organisations know if agent governance is actually working?

A: Agent governance is working when every agent is discoverable, owned, least privileged, and auditable at the action level. Look for reduced shadow AI, fewer embedded secrets, clean revocation on retirement, and logs that show which tools and data paths were used. If those signals are missing, governance is still partial.

Technical breakdown

Discovery and inventory for agentic identities

Agentic environments create identities that are harder to enumerate than human accounts because they are instantiated through copilots, plugins, connectors, and automation paths. Discovery is the first control layer because an unknown agent cannot be assigned ownership, privilege boundaries, or logging requirements. In practice, this means cataloguing both the agent and its downstream service credentials, data sources, and delegated permissions. The architectural problem is not just sprawl, but relationship mapping: one agent can sit on top of multiple NHIs and service endpoints, which makes hidden access paths easy to miss.

Practical implication: build an inventory that maps each agent to its credentials, tools, and data connections before you try to govern its permissions.

Credential lifecycle and federation versus static secrets

The framework treats static secrets as a poor fit for agentic access because long-lived credentials expand exposure windows and hide where authority really resides. Federation reduces that problem by shifting from embedded secrets to more traceable, revocable trust relationships. For agentic systems, the key issue is not only rotation cadence, but whether the identity path can be decommissioned cleanly when a connector, model, or workflow is retired. Credential lifecycle therefore becomes an access architecture problem, not just a secrets hygiene task.

Practical implication: replace hardcoded tokens with federated or vault-backed trust where possible, and tie decommissioning to every agent lifecycle event.

Monitoring, anomaly detection, and auditability of agent actions

Agentic systems require monitoring that can distinguish legitimate task execution from misuse, because the same workflow can look normal until scope or destination changes. That means logging must capture agent actions, called tools, target resources, and approval context in a way that is durable and reviewable. Without that, organisations get blind spots in both security operations and compliance evidence. The architecture challenge is not simply detection volume, but attribution quality: if you cannot tell which agent took which action, you cannot separate business automation from abuse.

Practical implication: instrument agent activity with immutable logs that preserve action, tool, and destination context for security review and forensic use.

Threat narrative

Attacker objective: The attacker objective is to exploit agentic trust paths so that AI-driven access can be used for data exfiltration, spend abuse, or wider privilege escalation.

1. Entry occurs when copilots, plugins, or connectors are introduced without governance, creating unmanaged agent identities with access to enterprise systems.
2. Credential access and abuse follow when hardcoded API keys or static tokens are embedded in pipelines, notebooks, or integrations and reused by agents at runtime.
3. Impact arrives when broad agent privilege, poor ownership, and monitoring blind spots let an agent leak data, drive cost, or trigger cascading privilege escalation across environments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic access governance is now an identity discipline, not a niche AI control problem. The article is right to frame access as the core issue because every agent, connector, and plugin introduces a new non-human identity with some degree of delegated authority. That pushes the problem squarely into IAM, PAM, and NHI governance rather than treating it as a separate AI operations concern. Practitioners should treat agent inventory and privilege mapping as part of core identity architecture, not an optional overlay.

Assumption collapse: access review was designed for identities whose privilege persists long enough to be reviewed. That assumption fails when an autonomous agent can spawn, combine, and retire access paths in the same runtime window, leaving no stable entitlement snapshot to certify. The implication is not just that existing review cycles are too slow, but that the governance premise behind them no longer matches the actor. Security teams must rethink what it means to observe and attest to access when the subject can change shape mid-session.

Static secrets are becoming identity debt for agentic systems. The framework’s emphasis on federation and lifecycle hygiene reflects a deeper shift: long-lived credentials no longer describe a trustworthy access model when agents can be replicated, chained, or embedded across workflows. A secret tied to an agent is only as manageable as the lifecycle around it. Practitioners should regard every embedded token as unresolved governance, not merely a technical convenience.

Monitoring must move from account-level visibility to action-level accountability. Agents do not behave like users, so a login event tells you very little about the actual risk. The meaningful control point is what the agent touched, which tools it invoked, and which data paths it traversed. That is why the future of NHI governance is not just access approval, but evidentiary tracing across runtime behaviour.

Identity blast radius is the right named concept for agentic access risk. In agentic environments, one compromised or over-privileged identity can cascade into multiple systems because the agent can chain actions faster than humans can intervene. That makes the blast radius of a single entitlement much larger than the account itself. Practitioners should assess agents by the maximum damage path they can execute, not by the label on the credential.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented policies to govern AI agents, even though 92% agree that agent governance is critical to enterprise security.
• That governance gap is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next resource for lifecycle, ownership, and offboarding design.

What this signals

Identity blast radius: agentic systems widen the consequences of a single credential or permission decision because one identity can touch many tools, data stores, and downstream workflows. That means readers should expect their access model to shift from account management to action containment. For broader context on how non-human access changes governance, see Top 10 NHI Issues.

With 92% of organisations agreeing that governing AI agents is critical but only 44% implementing policies, the operational gap is already visible in programme maturity, not future planning. Teams should assume that shadow AI and unmanaged connectors will surface faster than access review cadences can respond.

The right control question is not whether an agent can log in, but whether its runtime behaviour can be attributed, constrained, and revoked without ambiguity. That is where OWASP NHI Top 10 becomes useful as a bridge between identity governance and agentic application risk.

For practitioners

• Map every agent to an accountable owner Assign a named business and technical owner to each agent, including copilots, plugins, and connectors. Make ownership explicit for approvals, exception handling, and retirement so no agent sits outside governance.
• Replace static secrets with federated access paths Remove hardcoded API keys and embedded tokens from agent workflows where possible, and move those identities to vault-backed or federated trust models. Tie revocation to workflow retirement and connector removal.
• Limit agent privilege to task-scoped boundaries Constrain each agent to the minimum data sources, tools, and actions needed for its current purpose. Review broad scopes across connector chains, because excessive privilege often hides in inherited permissions.
• Instrument action-level monitoring and immutable logging Log each agent action with tool invoked, target resource, and decision context so security teams can separate normal execution from abuse. Preserve those records in an immutable system for investigations and compliance.

Key takeaways

• Agentic access governance is an identity problem because AI agents create non-human identities with real privileges, not just automation workflows.
• The reported 840x adoption increase and 1,767% copilot growth show that agent populations are scaling faster than most governance programmes can absorb.
• Practitioners should move from static access assumptions to ownership, federation, action-level logging, and lifecycle-aware revocation.

Key terms

• Agentic access governance: The practice of governing access for AI agents that can act at runtime rather than following a fixed script. It combines identity inventory, privilege scoping, ownership, logging, and retirement controls so the organisation can explain and revoke what each agent did.
• Non-human identity: A non-human identity is any credentialed actor used by software, workloads, or AI systems to access resources. In agentic environments, the term includes connectors, service accounts, API keys, tokens, and certificates that support runtime action rather than human login.
• Identity blast radius: Identity blast radius is the maximum damage a credential or entitlement can cause if misused or compromised. For agents, the blast radius can expand quickly because one identity may chain tools, move across systems, and reach data sources that were never intended to be connected.
• Shadow AI: Shadow AI is the set of AI agents, copilots, or connected workflows that operate without formal discovery, ownership, or oversight. The risk is not only hidden use, but hidden privilege, hidden data access, and hidden accountability across the identity stack.

Deepen your knowledge

Agentic access governance and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents with real privileges, it is worth exploring.

This post draws on content published by Oasis Security: The Agentic Access Management Framework: A Standard for Governing Agentic Access. Read the original.