Agentic AI taxonomy shows why identity controls need finer granularity

At a glance

What this is: This is an identity security taxonomy for agentic AI that separates agents by interaction method, runtime location, and authority model.

Why it matters: It matters because IAM, PAM, and NHI teams need to decide whether an agent should be governed like a user, a workload, or a distinct identity class.

👉 Read 1Password's analysis of agentic AI identity taxonomy and access controls

Context

Agentic AI is not one access pattern. Some agents behave like browser users, some call APIs or MCP directly, and some run remotely with different trust and credential assumptions. For identity programmes, the practical question is not whether an agent is "AI" but which access path, runtime, and authority model it actually uses.

That distinction matters because browser-mediated agents, programmatic agents, and remotely hosted agents trigger different controls for credential delivery, vault use, approval, and auditability. Treating them as one category collapses important governance decisions across NHI, autonomous systems, and human-owned authority.

The article’s taxonomy is useful because it forces teams to map agent behaviour before they map controls. That is the right order for IAM, PAM, and secrets governance.

Key questions

Q: How should security teams govern AI agents that use browser-based access?

A: Treat browser-based agents as a distinct access pattern that may need user-style credentials, session controls, and secure credential injection. The key is to decide whether the agent is acting for a person, a team, or a customer workflow, then assign approval and audit rules accordingly. One policy model will not fit all browser-mediated use cases.

Q: Why do remote AI agents create harder identity governance problems?

A: Remote agents sit outside the user’s local trust boundary and may continue working without a human present, which changes how credentials, approvals, and audit trails should be managed. That makes inherited access harder to justify and easier to overextend. Governance should focus on delegation scope and runtime boundary, not just on the agent label.

Q: What do IAM teams get wrong about agentic AI access?

A: They often classify agents by technology instead of by the actual identity behaviour: how the agent connects, where it runs, and whose authority it uses. That leads to mismatched controls, especially when browser automation, API use, and remote execution are treated as the same problem. The result is either under-control or over-control.

Q: How can organisations decide whether an AI agent belongs in PAM, IAM, or NHI governance?

A: Use the authority source and access path to decide. If the agent inherits human privileges in a browser flow, human IAM and PAM matter most. If it uses API keys, tokens, or service credentials, NHI governance is the right lane. If it spans both, the programme needs a delegation model that explicitly connects them.

Technical breakdown

Browser AI agents versus programmatic agents

Browser AI agents interact through a browser and usually need user-like credentials, session handling, and secure credential injection. Programmatic AI agents interact through APIs, MCP, or agent-to-agent paths, so they typically depend on API keys, tokens, or other machine credentials. The security model changes because the browser is both an execution environment and a control boundary, while programmatic access shifts the problem toward service identity, scoped permissions, and secret distribution. The relevant question is not just where the agent connects, but what identity form factor the connection requires.

Practical implication: separate browser-mediated agent controls from API-based machine identity controls instead of managing them through one policy path.

Where the agent runs changes the trust boundary

An agent on an endpoint sits inside a managed environment with EDR and MDM visibility, while a remote agent runs outside the local user’s trusted device and may operate asynchronously. That difference affects whether the agent inherits a human identity, uses a dedicated workload identity, or receives authority through a brokered flow. Remote execution also complicates audit, token containment, and session termination because the human may not be present while the workflow continues. Runtime location is therefore an identity design variable, not just an infrastructure detail.

Practical implication: define separate controls for endpoint-hosted and remote agents, especially around inherited credentials and approval boundaries.

Whose authority the agent uses determines governance scope

Agents can act for an employee, an internal company workflow, or a production-facing service. Each of those scopes changes who owns the vault, who approves access, and how exceptions are reviewed. The same agent behaviour can be acceptable in one context and risky in another if the authority source is different. This is where human identity governance, NHI controls, and lifecycle management intersect: the access model has to reflect whose business authority the agent is executing, not just what it can technically do.

Practical implication: align agent access reviews, vault ownership, and approval rules to the authority source behind the agent, not the tool it uses.

NHI Mgmt Group analysis

Agentic AI identity cannot be governed as a single class: browser agents, programmatic agents, and remote agents create different identity and access problems. A browser agent may need human-style credential delivery, while a programmatic agent depends on machine credentials and service permissions. The implication is that control design has to begin with behavioural classification, not with the assumption that all AI agents fit one entitlement model.

Runtime location is now part of the identity boundary: endpoint-hosted agents sit inside the user’s managed environment, but remote agents may execute asynchronously outside the user’s active oversight. That matters because the trust model, approval cadence, and audit trail all change once the agent leaves the endpoint boundary. Practitioners should treat runtime placement as a core governance input, not an infrastructure footnote.

Authority inheritance is the real policy question: the same agent can operate on behalf of an employee, an internal team, or a customer-facing service, and each case changes whose privileges are acceptable. NHI governance, PAM, and lifecycle controls all depend on that source of authority being explicit. The practical conclusion is that identity policy must model delegation, not just authentication.

Delegated authority blast radius: the key governance risk is not that agents exist, but that they may inherit broad access from the wrong identity context and then use it in ways humans did not pre-authorise. That creates a larger effective blast radius than either a standard user session or a conventional workload token. Teams should treat delegation scope as the primary control variable for agentic access decisions.

Identity programmes need a three-axis classification model for agents: interaction method, runtime location, and authority source together define the access pattern. That framing is more useful than debating whether an agent is a user or a workload, because many real deployments sit between those categories. For practitioners, the takeaway is to classify first and govern second.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a deeper view of how non-human credentials fail in practice, see 52 NHI Breaches Analysis and map those patterns back to agent delegation decisions.

What this signals

Delegated authority is becoming the new control plane for identity: as agentic systems move between browser, API, and remote execution modes, the real security question is who granted the access and under what scope. That makes delegation records, vault boundaries, and approval provenance more important than the agent brand or UI. Teams that cannot trace authority source will not be able to govern the agent’s effective blast radius.

Delegated authority blast radius: this is the concept practitioners should watch. Once an agent can switch contexts while preserving access, the programme must track not only credential type but also who can authorise reuse, where the agent runs, and whether the entitlement is still valid for the current task. That is a governance issue, not just an access issue.

Fragmented secrets handling remains a structural weakness in many programmes, and our research shows organisations maintain an average of 6 distinct secrets manager instances. That fragmentation becomes more dangerous when agents consume credentials across multiple runtime contexts, because the policy gap is then spread across tools, owners, and approval paths.

For practitioners

• Classify each agent by access pattern Document whether the agent is browser-based or programmatic, where it runs, and whose authority it uses before assigning any credentials or approvals. Use those three fields to determine whether it belongs in human IAM, NHI governance, or a dedicated agent policy lane.
• Separate endpoint and remote controls Apply different control paths for agents running on managed endpoints versus remote cloud environments. Endpoint agents can rely more on device trust, while remote agents need tighter vault mediation, explicit delegation rules, and stronger audit records.
• Bind vault ownership to authority source Require the vault owner, approver, and reviewer to match the business authority behind the agent. An employee-assisting agent, an internal automation agent, and a customer-facing agent should not inherit the same approval model or access scope.
• Review inherited credentials for scope drift Check whether the agent is receiving credentials that exceed the task it is actually performing, especially when it operates asynchronously. Narrow access where the human or system sponsor cannot explain the full delegated action path.

Key takeaways

• Agentic AI needs governance by behaviour, not by marketing label, because browser, programmatic, and remote agents create different identity risk profiles.
• The main control question is authority inheritance, since the same agent can operate for an employee, a company workflow, or a customer-facing service.
• Identity teams should classify agents before assigning controls, otherwise approvals, vault ownership, and audit trails will not match the real access path.

Key terms

• Agentic AI: Software that can choose actions, tools, and timing at runtime rather than following a fixed script. In identity terms, the important question is not whether it is intelligent, but whether it behaves as an access-bearing actor that needs explicit governance, delegation, and credential boundaries.
• Authority Source: The person, team, or system on whose behalf an agent is allowed to act. This determines which privileges are acceptable, who approves them, and who is accountable when the agent uses them. It is a governance concept, not just an authentication detail.
• Browser AI Agent: An AI agent that interacts with applications through a browser interface, usually by handling human-like sessions and credentials. This mode creates a mixed identity problem because the agent may need both user-style access and machine-enforced controls around session handling, credential injection, and audit.
• Delegated Access: Access granted to one identity so it can act for another identity or business function. In agentic environments, delegated access can expand quickly if the scope, runtime, and authority source are not explicitly bounded, which is why delegation records matter as much as the credential itself.

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 lifecycle governance, it is worth exploring.

This post draws on content published by 1Password: Agentic AI taxonomy shows why identity controls need finer granularity. Read the original.