Notifications
Clear all
Topic starter
11/06/2026 11:13 pm
TL;DR: AI agents need different identity controls depending on how they interact with systems, where they run, and whose authority they inherit, with browser-based and programmatic use cases requiring different credential handling, according to 1Password. The central issue is that agentic access breaks assumptions built for either users or workloads, so governance must distinguish each agent’s operating model.
NHIMG editorial — based on content published by 1Password: Agentic AI taxonomy shows why identity controls need finer granularity
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Separate endpoint and remote controls Apply different control paths for agents running on managed endpoints versus remote cloud environments.
- Bind vault ownership to authority source Require the vault owner, approver, and reviewer to match the business authority behind the agent.
What's in the full article
1Password's full article covers the operational detail this post intentionally leaves for the source:
- The browser-agent credential delivery model, including how Secure Agentic Autofill handles extension-based filling.
- The distinctions between endpoint and remote deployment, which matter for trust boundaries and asynchronous execution.
- The employee, internal company, and customer-facing authority cases that determine who owns the vault and approval flow.
- The practical taxonomy examples that help teams map agent type to the right security measure.
👉 Read 1Password's analysis of agentic AI identity taxonomy and access controls →
Agentic AI identity taxonomy: what IAM teams need to separate?
Explore further
12/06/2026 7:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Agentic AI taxonomy shows why identity controls need finer granularity
