Agentic AI taxonomy shows why identity controls need finer granularity

At a glance

What this is: A 1Password taxonomy argues that agentic AI should be classified by how it interacts, where it runs and who it acts for, because those distinctions change identity and access requirements.

Why it matters: IAM and security teams need this separation because browser agents, programmatic agents and remote or delegated agents do not share the same credential, authorization or governance model.

Context

Agentic AI is not a single identity pattern. Once an agent can use a browser, APIs, MCP or agent-to-agent links, the governance problem stops being simple automation and becomes a question of which identity model is actually in play.

The security gap is that teams often treat agentic systems as either users or workloads, then apply controls that fit neither cleanly. That creates ambiguity around credential type, runtime trust, human authorization and offboarding responsibility.

For identity programmes, the practical issue is granularity. The article's taxonomy is useful because it forces teams to separate interaction mode, execution location and delegated authority before they decide how to govern access.

Key questions

Q: How should teams separate browser-based agents from programmatic agents in IAM?

A: They should treat the interaction path as a control boundary. Browser agents need browser-mediated credential handling and controls that reflect human-like sessions, while programmatic agents need machine-facing authentication, API authorization and tighter service credential governance. A single policy set usually misses both cases.

Q: Why does agent runtime location matter for identity controls?

A: Because an endpoint agent and a remote cloud agent inherit different trust conditions. Endpoint deployment can rely on managed-device controls and local context, while remote deployment usually weakens assumptions about human presence, device trust and session visibility. That changes how secrets, approvals and audit evidence should be handled.

Q: When should organisations distinguish employee, internal and customer agent authority?

A: Always when the same agent can act on behalf of different principals. Employee, internal and customer contexts imply different vault ownership, approval rules and audit expectations, even if the workflow looks the same. If teams blur those contexts, they lose accountability and overgeneralize access policy.

Q: What should organisations do when AI agents start using inherited credentials?

A: Treat those agents as governed identities rather than untracked automation. Scope their credentials tightly, log every action back to a human owner, and make revocation part of the operational model. Otherwise, agent activity will outgrow session-based IAM assumptions and create access that is hard to explain or remove.

Technical breakdown

Browser agents and programmatic agents use different credential paths

Browser-based agents imitate human behaviour through a web interface, so they tend to need user-centric credentials such as passwords, passkeys or browser-mediated autofill. Programmatic agents interact through APIs, MCP or similar machine interfaces, so they more often depend on API keys, tokens or other non-interactive credentials. Those are not interchangeable because the authentication mechanism, storage model and abuse surface are different. A browser agent is also bound to the browser runtime, which changes how secrets can be injected and how session state is controlled.

Practical implication: Treat browser and programmatic agent access as separate control classes, not a single AI access pattern.

Execution location changes the trust boundary for agent identity

An agent running on an endpoint sits inside a managed device boundary where MDM, EDR and local user presence can shape the risk model. A remote agent running in a private or public cloud sits outside that boundary and often behaves asynchronously, which makes human supervision and device trust assumptions weaker. Location matters because it changes where secrets live, how credentials are delivered and whether the agent is inheriting authority from a local user context or operating independently as a remote workload.

Practical implication: Align identity controls to the runtime boundary, especially when a remote agent no longer benefits from endpoint trust.

Delegated authority determines whether an agent acts as employee, company or customer context

The article's third dimension is whose authority the agent is using. An agent acting for an employee, an internal company task or a customer-facing workflow may require different vault ownership, approval paths and audit expectations even when the underlying tooling looks similar. That distinction matters because the same technical action can carry very different governance obligations depending on whether the agent is operating under individual, internal or external authority. In identity terms, the delegation model is part of the identity itself.

Practical implication: Separate vault ownership and authorization rules by delegated authority, not just by the tool the agent uses.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

Agentic AI taxonomy is becoming a governance control, not a naming exercise. The article's three-way split across interaction mode, runtime location and delegated authority is useful because identity teams cannot secure agentic systems with a single policy tier. Browser access, remote execution and authority inheritance each produce different control demands. The implication is that agentic identity programmes need classification before they need scale.

Browser-based agent access and programmatic agent access are different identity problems. A browser agent often needs human-style credentials and browser mediation, while a programmatic agent needs machine-style credentials and protocol-level authorization. Conflating those two models leads to weak control selection and unclear credential ownership. Practitioners should treat the access path as part of the identity design, not as an implementation detail.

Runtime location is the boundary where identity assumptions either hold or fail. Endpoint-deployed agents can ride on trusted-device controls and a visible human context, while remote agents often run asynchronously and outside that trust envelope. That shift changes how teams should think about session oversight, secret delivery and auditability. The lesson for identity architects is to make runtime location a first-class input to policy.

Delegated authority creates the hardest governance questions because the same agent can act for different principals. An agent working for an employee, an internal team or a customer-facing service needs different authorization and vault boundaries even when the workflow looks similar. This is where many identity programmes blur ownership and lose audit clarity. The practical conclusion is that authority inheritance must be explicit, not inferred from the task.

Granularity is the control pattern agentic AI now forces across NHI and human IAM. The taxonomy shows that agentic access does not collapse existing identity categories, but it does expose where those categories are too coarse. That makes classification itself a governance action. Teams should expect more precise policy branching, not a universal agent policy that ignores context.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: Agentic AI Identity Guide

What this signals

Interaction mode is now an identity decision point. Browser-based and programmatic agents do not just differ technically, they require different credential handling, which means agent classification has to happen before policy design. Teams that skip that step will continue to apply human or workload controls too broadly and miss the actual access pattern.

Remote execution should be treated as a different trust boundary from endpoint execution. Once the agent is outside the local device, the organisation loses the same combination of device trust, visible user context and simple secret delivery. That shifts the governance problem toward explicit authority assignment and auditable secret handling rather than convenience-driven access.

Delegated authority needs sharper vault and approval boundaries. An agent that acts for an employee, an internal team or a customer-facing service should not inherit the same vault structure or approval workflow. The control objective is to keep the principal visible at the point of access, not after the fact.

For practitioners

• Define separate control paths for browser and programmatic agents Map each agent to its actual interaction channel, then assign credential type, authorization logic and logging based on that channel rather than on the fact that it is an AI system.
• Classify the runtime boundary before issuing access Document whether each agent runs on an endpoint or in remote cloud infrastructure, because that choice determines which trust assumptions, monitoring tools and secret-handling methods are valid.
• Record whose authority the agent is using Tag each deployment as employee, internal company or external customer context so vault ownership, approval flows and audit records stay aligned to the principal behind the action.
• Separate human-in-the-loop approval from machine execution Require explicit authorization when a remote or customer-facing agent needs to inherit human authority, and do not let workflow convenience blur the delegated identity boundary.

Key takeaways

• Agentic AI identity cannot be governed as one generic class because browser, programmatic and remote agents follow different access and trust patterns.
• The central design mistake is assuming that user-style or workload-style controls will fit every agent context without adjustment.
• Practitioners should classify interaction mode, runtime location and delegated authority before deciding how credentials, approvals and audit trails are handled.

Key terms

• Agentic AI Taxonomy: A classification scheme that separates AI agents by how they interact, where they run and whose authority they use. In identity security, taxonomy matters because those variables determine which credentials, trust boundaries and approval flows are appropriate for the agent's actual operating model.
• Delegation authority: Delegation authority is the right for one identity to act on behalf of another within a defined scope. For agents, it must be explicit, time-bound, and auditable because the system may initiate actions independently once granted access.
• Runtime boundary: The point at which an identity's permissions, execution context, and observable behaviour are contained for policy purposes. In agentic systems, runtime boundaries matter because they determine whether the organisation can explain, audit, and limit what the agent did after execution begins.
• Browser Agent: A browser agent is software that can navigate websites and complete browser-based tasks on behalf of a person or system. In identity terms, it is an execution identity that may inherit access, session state, and trust boundaries that were previously assumed to belong only to humans.

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 IAM programme, it is worth exploring.