Opal’s AI-native access model reflects the rise of agentic identity

At a glance

What this is: This is Opal Security’s conversation with its new CPO about why access governance must expand from human users to non-human identities and autonomous agents.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to control runtime access decisions, not just provisioned entitlements, across every identity type.

👉 Read Opal Security's conversation on AI-native access governance for humans, services, and agents

Context

The core problem is identity governance at machine speed. Traditional access models assume a human reviewer can assess entitlements after they are granted, but that breaks down when autonomous agents and service accounts are created quickly, act continuously, and can reach production systems before a quarterly review catches up.

Opal frames this as one access platform for every identity, which is really a broader industry signal: organisations are being pushed to unify human IAM, NHI governance, and agent oversight rather than run separate control planes. For background on the non-human identity layer, the Ultimate Guide to NHIs is the clearest reference point.

Key questions

Q: How should security teams govern autonomous agents that can access production systems?

A: Treat autonomous agents as governed actors with explicit ownership, scoped privileges, runtime policy checks, and immediate containment options. Do not rely on quarterly certification to control behaviour that can start and finish inside a single session. If the agent can choose actions and execute them without approval, the control point has to move to runtime.

Q: Why do service accounts and AI agents complicate traditional access reviews?

A: Because access reviews assume entitlements remain stable long enough for a person to inspect them. Service accounts and AI agents can exercise access continuously, and in autonomous cases the behaviour may change mid-session. That means a review can confirm that access existed, but still miss the most important question: what the identity actually did.

Q: What breaks when organisations use one IAM model for humans and non-human identities?

A: A single human-centric IAM model often breaks because it ignores runtime usage, machine-driven action paths, and the need for non-human containment. Humans, service accounts, and agents may all need access, but they do not need the same approval logic, revocation timing, or evidence trail. One model rarely fits all three cleanly.

Q: Who is accountable when an autonomous agent exceeds its intended access?

A: Accountability should sit with the team that approved the agent’s deployment and operating boundary, not with the agent itself. Organisations need a named owner, documented policy, and a containment path for when the actor behaves outside scope. Without that, incident response becomes a search for ownership instead of a control decision.

Technical breakdown

Why runtime access decisions matter more than periodic review

The article points to a shift from static entitlement governance to runtime enforcement. In practice, that means the control decision has to happen when access is requested or used, not only when it is granted and later recertified. For humans, that is an IAM and IGA problem. For service accounts and agents, it becomes a continuous authorisation problem because their permissions can be exercised by code, not just by a person. When access is evaluated too late, the organisation is reviewing an event that may already have produced data exposure or system change.

Practical implication: move high-risk access checks closer to execution time for privileged humans, service accounts, and agents.

Why autonomous agents change the identity boundary

Autonomous agents are not just another workload. If an identity can decide what action to take, select a tool, and execute without human approval, then access governance has to account for runtime intent, not only fixed roles. That changes the identity boundary because the same account can now represent both the actor and the decision-maker. In that model, a quarterly entitlement review is structurally weak: it records that access existed, but not why the agent used it, what it selected, or whether its behaviour stayed within expected scope.

Practical implication: treat autonomous agents as governed actors with explicit containment, logging, and approval boundaries.

How policy as code supports explainable access control

Policy as code is the mechanism Opal highlights for making access decisions auditable and repeatable. The value is not just automation, but consistency: if the policy logic is version-controlled and testable, teams can tie a grant or denial back to specific rules and usage context. That matters when security teams need to explain why a human, service account, or agent could reach a production system. Explainability becomes a governance control, not just a reporting feature, because it gives reviewers a way to validate whether access matched real usage.

Practical implication: version access policy, test it like application code, and require decision traceability for sensitive systems.

NHI Mgmt Group analysis

Access governance built for review cycles breaks when the actor is autonomous: access review processes were designed for access that persists long enough to be observed, certified, and revoked later. That assumption fails when an agent can obtain, use, and discard access within a single session without human approval. The implication is not simply that teams need a faster review process, but that the review model itself no longer matches the behaviour being governed.

Runtime control is now the real identity boundary: identity governance used to focus on who was entitled to reach a system. For AI agents and machine identities, the more important question is what they can do once they arrive and whether the organisation can constrain the action path in real time. That is an OWASP-NHI and Zero Trust issue at the same time, because entitlement alone does not describe operational risk once the identity can act at machine speed.

Policy as code is becoming a governance requirement, not a nice-to-have: when access decisions have to be explainable across humans, service accounts, and agents, ad hoc manual approvals stop scaling. Versioned policy creates a defensible record of what the organisation intended, which is essential for auditability, incident response, and access containment. Practitioners should treat this as a control design shift, not a tooling preference.

The next access crisis will be identity sprawl plus decision sprawl: the article’s own framing that every agent becomes a new identity is the right warning. If organisations add agent identities without the same lifecycle discipline they apply to human users and critical service accounts, they create a second layer of unmanaged access. That is where governance drift becomes security drift, and practitioners need one operating model across all identity types.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• For the broader breach context, 52 NHI Breaches Analysis shows how unmanaged machine identities turn governance gaps into incident paths.

What this signals

Decision sprawl is becoming the next identity governance problem: when every autonomous workflow or service account becomes a separate decision surface, control frameworks need to track not only entitlement but also action authority. The organisations that will struggle most are the ones still treating agent access as an extension of human IAM rather than a distinct runtime governance problem. For a baseline, compare your current model with the Ultimate Guide to NHIs.

The operational signal is clear: access review alone is too slow for identities that can change behaviour at machine speed. Teams should expect more demand for policy-as-code, runtime authorization, and explainable decision trails across both human and non-human populations. That also means zero trust programmes will increasingly be judged on whether they can govern the identity that acts, not just the identity that logs in.

Agent identity debt: the longer organisations add agents before defining ownership, scope, and shutdown paths, the harder it becomes to recover control. That debt will show up first as unclear accountability, then as excess privileges, then as access that nobody can confidently revoke. Practitioners should start measuring how many identities fall outside a documented lifecycle path.

For practitioners

• Map every autonomous agent to an accountable owner Require each agent to have a named business owner, technical owner, and control boundary before it is allowed to reach production systems. If no owner can explain the agent’s allowed actions and shutdown path, the identity is not ready for release.
• Move privileged access checks to runtime Apply runtime approval or policy evaluation for sensitive actions rather than relying on periodic certification alone. This is especially important for agents and service accounts that can complete work faster than a review cycle can detect misuse.
• Separate human, service account, and agent policy paths Do not recycle a single role model across different actor types. Define distinct policy conditions for human users, non-human identities, and autonomous actors so that logging, containment, and escalation rules reflect how each one actually behaves.
• Make access decisions explainable in seconds Keep policy logic version-controlled and testable, then require decision traces for production access. Security teams should be able to answer who can reach a system and why without waiting for manual report assembly.

Key takeaways

• The article shows that access governance is shifting from static entitlements to runtime control across humans, service accounts, and agents.
• The governance risk is no longer theoretical, because machine-speed identities can outpace review cycles and leave weak evidence trails.
• Practitioners should redesign access policy, ownership, and containment so they can govern the actor that behaves, not just the account that exists.

Key terms

• Autonomous Agent: A software identity that can decide what action to take, choose tools, and execute without human approval. In governance terms, it is not just an automated workflow. It is an actor whose behaviour must be bounded, logged, and owned like any other high-risk identity.
• Runtime Authorization: Authorization that happens when the identity tries to act, not only when access is granted. This matters for service accounts and agents because their risk is revealed in use, not just in assignment. It is the difference between knowing access exists and knowing what the actor can do right now.
• Policy as Code: Access policy written in version-controlled, testable logic rather than scattered manual rules. It gives security teams a repeatable way to explain and audit decisions across human and non-human identities. For agents, it is especially useful because it turns access intent into something that can be reviewed and changed safely.
• Access Review: A governance process that checks whether an identity still needs the permissions it has. For humans it often works as a periodic certification exercise, but for non-human identities and autonomous agents it can be too slow unless paired with runtime controls and rapid revocation paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Opal Security: Building What’s Next, a conversation with CPO Sameer Mehta. Read the original.