Unified access for AI agents exposes the limits of login-based IAM

At a glance

What this is: 1Password argues that AI agents and local tooling expose a gap in login-based IAM because credentials are now used outside traditional identity systems and need runtime access checks.

Why it matters: This matters because IAM teams must govern humans, NHIs, and increasingly autonomous workflows with one access model, or risk losing visibility, auditability, and control over secrets.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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%).

👉 Read 1Password's analysis of unified access for humans, agents, and machine identities

Context

AI agent identity risk is increasingly rooted in where credentials are created, stored, and exercised, not just in whether a user successfully logs in. The article is centred on the collapse of a login-first model that assumes authority can be established once and safely carried through a session across humans, machine identities, and agentic workflows.

That assumption fails when secrets live on employee devices, in local development environments, browser-based AI tools, and automation pipelines that sit outside traditional SaaS logs. In practice, this is an access governance problem as much as a security tooling problem, because the same credential can now be used by a person, a service account, or an AI-driven workflow depending on context.

For practitioners, the key question is no longer whether identity exists at login, but whether access can be discovered, governed, and audited at the moment a credential is used. That is where NHI governance, runtime authorization, and audit continuity begin to overlap.

Key questions

Q: How should security teams govern AI agents that use credentials outside traditional IAM systems?

A: Security teams should govern AI agents at the point of credential use, not only at login. That means discovering where secrets live on devices and in tools, delivering them just in time, and preserving attribution for every use. If the agent can access credentials without passing through the core identity plane, the control boundary has already shifted.

Q: Why do AI agents complicate access reviews and audit trails?

A: AI agents complicate access reviews because their activity often spans endpoint tools, browser sessions, and machine identities that are logged in different places. That fragments the evidence needed to decide whether access was appropriate. A useful programme needs one audit trail that ties each secret use back to the originating actor and context.

Q: What breaks when secrets are stored in local files and developer tools?

A: What breaks is visibility, attribution, and revocation speed. Secrets in local files, .env artifacts, and developer tools can be copied and reused outside the systems that security teams monitor most closely. If the organisation cannot discover and trace those credentials, it cannot confidently govern their use or prove they were controlled.

Q: Who is accountable when AI agents use shared credentials across workflows?

A: Accountability belongs to the organisation that owns the credential lifecycle and the policy attached to it. When shared secrets are used across humans, agents, and machines, the governance model must still identify which actor used the credential, under what approval path, and for what task. Without that, accountability becomes ambiguous.

How it works in practice

Why login-based trust breaks for AI agents and local tooling

Traditional IAM models establish identity at authentication time and then carry that trust through the session. That works when the actor is a person or a stable service account, but it weakens when AI agents, browser tooling, and local scripts can invoke credentials repeatedly from outside the core identity plane. The technical issue is not just automation. It is that credential use is now happening in distributed execution contexts that traditional federation and SaaS logs do not fully observe. When secret creation, storage, and first use happen on the endpoint, the identity system may never see the risky moment.

Practical implication: Extend discovery to endpoints and developer tools so access is governed where secrets are actually used.

Runtime authorization and just-in-time secret delivery

The article points to a shift from always-on access to just-in-time delivery. In technical terms, that means a credential is not assumed valid for the full session after login. Instead, each use of a secret, token, or key is evaluated at request time and delivered only for the task at hand. This matters because long-lived secrets are easily copied into .env files, scripts, and shared workflows, then exercised far beyond their intended scope. Runtime authorization reduces standing exposure, but it only works if the vault, policy engine, and execution environment are tightly connected.

Practical implication: Use just-in-time credential delivery for high-risk secrets and bind delivery to the requesting context.

Unified audit across humans, agents, and machine identities

When identity events are split across human authentication logs, service-account records, and agent activity, governance breaks at the audit layer. A single system of record does not eliminate risk, but it does preserve attribution, which is essential for incident response and access review. The technical challenge is correlating who initiated access, what actor executed it, and which secret was used, especially when agents operate inside IDEs, browsers, or MCP-style workflows. Without that correlation, teams cannot reliably reconstruct scope or prove control effectiveness.

Practical implication: Correlate credential use to the originating user, workload, or agent session before you rely on audit evidence.

NHI Mgmt Group analysis

Login-time authority is no longer a sufficient governance model. This article shows that the identity boundary has moved from authentication to credential use, which is where AI agents and local tooling now create risk. Login establishes who began a session, but it does not prove who or what exercised a secret later. Practitioners should treat runtime access as the real control point, not the original sign-in.

Endpoint-distributed secrets create identity blind spots that traditional SaaS-centric IAM cannot see. The article is explicit that exposed SSH keys, plaintext .env files, long-lived API tokens, and locally installed agents often sit outside the systems security teams monitor most closely. That is a structural visibility gap, not a policy gap alone. The implication is that access governance must extend to device-level discovery, because the credential lifecycle now begins before central IAM ever records it.

Just-in-time access changes the blast radius of both human and machine identity. The article describes a shift from always-on secrets to moment-of-use delivery across humans, agents, and machines. That narrows exposure, but it also makes the control plane itself more important because one mis-scoped runtime grant can be exercised instantly by an automated workflow. The practitioner conclusion is that standing privilege is no longer the default state to manage; it is the condition to eliminate.

Unified audit is now a governance requirement, not just an incident response convenience. When agent activity, machine identity, and human use are all mediated through different systems, the organisation loses the chain of attribution needed for recertification, breach analysis, and accountability. This is where NHI governance and identity governance converge: if a secret cannot be tied to a specific actor, the control was never complete. Practitioners need a single evidentiary trail for access use, not just a list of issued credentials.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the same report.
• For a broader view of the failure mode, read the Ultimate Guide to NHIs for lifecycle, visibility, and governance patterns that apply across machine identities and AI agents.

What this signals

Credential governance is moving to the endpoint layer. Teams that still rely on SaaS-centric identity logs will miss the first place many AI-agent risks now appear, which is on employee devices and in local workflows. The practical signal is to expand discovery, then correlate it with runtime access policy so secrets are governed where they are first used.

AI agents are forcing identity teams to treat secret use as the event, not sign-in. The older control model assumes a stable actor after authentication, but agentic workflows can consume credentials repeatedly across tools and sessions. That is why runtime delivery and unified audit are becoming baseline requirements, not advanced capabilities.

Access governance, NHI hygiene, and agentic AI control are converging on one operational question: can you prove who or what used a secret, and when? If the answer is no, the organisation has an attribution problem before it has a remediation problem.

For practitioners

• Extend discovery to endpoint credential use Inventory where secrets are created, copied, and first exercised on employee devices, in IDEs, and in browser-based AI tools. Prioritise exposed SSH keys, plaintext environment files, and long-lived API tokens that never appear in central SaaS logs.
• Move high-risk secrets to just-in-time delivery Use runtime evaluation before issuing secrets to agents, scripts, or machine identities. Limit delivery to the specific task context so credentials are not left available for reuse after the work item completes.
• Unify attribution across humans, agents, and workloads Correlate each secret use to the originating user, agent session, or machine identity in one system of record. Preserve the evidence needed for access review, incident response, and control validation.
• Rework access reviews around secret use, not login events Review where credentials were exercised, by which actor type, and under what context. Login records alone will miss the point at which an AI workflow or local automation actually consumed the secret.

Key takeaways

• The article shows that AI agent risk is now concentrated at credential use, not just authentication.
• Visibility gaps remain the dominant problem, with secrets and agent activity often living outside traditional identity logs.
• Practitioners should shift to runtime delivery, endpoint discovery, and unified audit if they want access controls to keep pace.

Key terms

• Runtime Authorization: Runtime authorization is the practice of deciding access at the moment a credential is used, not only when a user logs in. For AI agents and machine identities, this matters because the risky act is often secret consumption inside a workflow, not the original authentication event.
• Just-in-Time Secret Delivery: Just-in-time secret delivery provides a credential only when a task needs it, then limits further reuse. In NHI and agentic environments, this reduces standing exposure and makes access more task-scoped, which is critical when tools or agents can reuse secrets instantly.
• Identity Attribution: Identity attribution is the ability to tie a specific access event to the actor that caused it, even when humans, agents, and machine identities share workflows. It is the evidentiary layer that supports audit, recertification, and incident reconstruction when access is fragmented across tools.
• Endpoint Credential Discovery: Endpoint credential discovery is the process of finding secrets on employee devices, in local files, and inside development tools before they escape central control. It is increasingly necessary because many AI and automation risks start where traditional IAM logging has little or no visibility.

Deepen your knowledge

AI agent identity and runtime access control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment is moving from human login controls to secret-use governance, this course gives you the governance baseline to assess it.

This post draws on content published by 1Password: Unified Access Pro for humans, agents, and machine identities. Read the original.