TL;DR: AI agents, automation scripts, and local tooling are pushing credentials outside traditional identity systems, where login-based IAM cannot reliably see or govern secret use, according to 1Password. The core shift is that authority now needs to be re-evaluated at the moment of access, because session-based trust assumes a stable actor and a stable privilege window.
At a glance
What this is: This is 1Password’s analysis of why AI agents, automation scripts, and local tooling expose the limits of login-based IAM when credentials are used outside traditional identity systems.
Why it matters: It matters because IAM, PAM, and NHI programmes increasingly need to govern access at secret use time, not just at authentication time, as agent-driven workflows spread.
Context
Login-based IAM assumes a stable subject authenticates once, enters a session, and keeps the same authority until that session ends. That model weakens when AI agents, scripts, and local tools can retrieve and use secrets outside the systems that normally record identity events.
For identity teams, the problem is not only visibility. Credentials created, stored, and used on employee devices, in browsers, and in local development environments can bypass federated logging, leaving NHI governance and access review processes blind to the point where risk actually begins.
The article’s core argument is that access decisions now need to be made at the moment a credential is requested or used. That is an operational shift for human IAM, NHI governance, and emerging agentic AI access patterns alike.
Key questions
Q: What breaks when AI agents are governed only with login-based IAM?
A: Login-based IAM breaks because it stops at authentication and never evaluates the thousands of actions an autonomous agent may take after sign-in. The result is broad delegated access with no runtime control, which makes inherited credentials, token reuse, and chained actions effectively invisible to governance teams. Runtime authorisation is the missing control plane.
Q: Why do long-lived secrets create more risk in agent-driven workflows?
A: Long-lived secrets increase risk because the same credential can be reused across humans, agents, and machine workflows without a fresh trust decision. Once a token or key is copied into local tooling, its usable life extends beyond the original login context, making misuse harder to detect and limit.
Q: How do identity teams know whether secrets governance is actually working?
A: Identity teams know secrets governance is working when they can prove that every active secret has an owner, an approved scope, and a tested revocation path. If they cannot quickly identify where a secret is used or remove it without breaking the workload, governance is still incomplete.
Q: What is the difference between login-time trust and runtime access control?
A: Login-time trust decides once, at authentication, and carries that decision forward through the session. Runtime access control re-evaluates authority when the credential is actually requested or used. For AI agents and other non-human workflows, runtime control is stronger because access happens where the risk occurs.
How it works in practice
Why login-based sessions fail for agentic access
Login-based IAM is built around authentication events, session creation, and policy assignment at entry time. That works when a human user keeps the same context throughout a session. It fails when an AI agent, automation script, or local tool pulls a secret later in the workflow, because the credential use is decoupled from the original login event. In practice, the system that authenticated the user may never see the actual access to the target resource. That leaves authority inferred from an earlier checkpoint instead of confirmed at the point of use.
Practical implication: move access decisions closer to secret use and do not treat login as proof of ongoing authority.
How unmanaged secrets escape identity system visibility
The article points to exposed SSH keys, plaintext .env files, long-lived API tokens, and locally installed agents as examples of credentials that live outside traditional SaaS logs and federated identity systems. These secrets often appear first on employee devices, in browser-based tools, or inside development environments where identity controls are weak or absent. Once a secret is copied into a local workflow, the access path may never pass through the central identity stack again. That makes the secret itself the enforcement boundary, not the user session.
Practical implication: inventory secrets where they are created and used, not only where enterprise identity logs already exist.
Why runtime delivery changes control of AI agents and machine identities
Runtime delivery means credentials are provided only when they are needed, rather than being left in a reusable form on disk or in scripts. For AI agents and machine identities, that shifts control from possession to issuance. The important question becomes whether access can be confirmed in context each time a credential is requested, used, or handed to an agentic workflow. This is especially relevant where the same secret might be exercised by a human today and by an agent tomorrow. The mechanism aligns more closely with just-in-time access and zero standing privilege than with static login-based trust.
Practical implication: design credential delivery so the secret is scoped, contextual, and auditable at the moment of use.
NHI Mgmt Group analysis
Login-based IAM is the wrong abstraction for agentic runtime access: The model assumes identity proves authority once, then remains trustworthy for the duration of the session. That assumption was designed for human-paced access, not for AI agents and local workflows that request secrets mid-task. The implication is that security teams need to govern authority at secret use time, not treat authentication as the final control point.
Credential visibility has moved to the endpoint and the browser: When credentials are created, stored, and first used on employee devices, traditional SaaS identity logs miss the governance event that matters most. That is not just a monitoring gap. It is an NHI governance blind spot that leaves service credentials, API keys, and agent sessions outside the normal lifecycle record.
Unified audit across humans, agents, and machine identities is now a governance requirement: Once the same secret can be used by a person, an agent, or automation, audit trails split across systems of record. A single credential lineage becomes the only defensible way to answer who or what used access, when, and under which context. Practitioners should treat fragmented auditability as a governance defect, not an inconvenience.
Ephemeral access must replace persistent trust windows: The named concept here is runtime trust collapse. As delegation shifts from user login to agent execution, the old trust window becomes too wide to govern safely. Identity programmes should assume that any reusable credential left outside context-aware issuance will be exercised in ways the original policy never saw.
Agentic AI changes identity from a perimeter control to an execution control: That does not eliminate human IAM or NHI governance; it merges them into a single runtime problem. Organisations that keep access governance anchored to login events will undercount risk, overestimate visibility, and misread where control actually fails.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Runtime trust collapse: Security programmes that still anchor authority to login events will miss the point where AI agents actually consume access. The control boundary shifts to secret issuance and use, which means identity governance and NHI governance now share the same enforcement problem.
Access reviews alone are too slow for agentic workflows because a credential can be exercised before any recertification cycle has a chance to matter. Practitioners should treat endpoint visibility, scoped delivery, and unified audit as execution controls rather than optional hardening.
The practical test is simple: if a secret can be copied into a browser, IDE, or local file and still function without fresh context, your identity model is already behind the workflow.
For practitioners
- Map where secrets are created and first used Trace SSH keys, API tokens, .env files, and other secrets on employee devices, in browsers, and in IDE workflows before they ever reach central logging.
- Shift from session trust to runtime authorisation Require access confirmation at the moment a credential is requested or injected into an AI agent, script, or machine workflow.
- Centralise credential custody for mixed human and machine use Store reusable credentials in one governed system so access can be assigned, revoked, and audited regardless of whether a human or an agent uses them.
- Reduce long-lived secret reuse across tools Replace static tokens and copied environment files with scoped delivery patterns that limit how far a credential can travel once it is issued.
- Unify audit trails across people, agents, and automation Correlate credential issuance, secret injection, and downstream use so investigations can reconstruct which identity path actually exercised access.
Key takeaways
- AI agents and local tools expose a structural weakness in login-based IAM because they can use credentials outside the authentication event that originally granted trust.
- The article’s core concern is not just visibility, but governance at the moment of secret use, where reusable credentials create unmanaged access paths.
- Practitioners should move control closer to issuance, usage, and audit so access is confirmed in context rather than assumed from a prior session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on secrets exposed on devices, in files, and in local tools. |
| NHI-07 — Long-Lived Secrets | Reusable credentials are the article’s main risk because they outlive the login session. | |
| NHI-04 — Insecure Authentication | Login-based trust fails when secret use happens outside the original authentication event. | |
| Recommendation — Scan endpoint and developer workflows for leaked secrets and remove them from local storage. Reduce standing secret lifetime by issuing credentials only when a task needs them. Re-evaluate authentication boundaries so credential use is checked at issuance time. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article argues authorisation must be confirmed when access is requested, not only at login. |
| Recommendation — Apply PR.AA-05 to validate entitlements at the moment a secret is used. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Exposed secrets enable credential access that can expand into broader system reach. |
| Recommendation — Map exposed secrets to TA0006 and TA0008 to prioritise detection around reuse and spread. | ||
Key terms
- Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
- Unified audit trail: A single evidence stream that links identity proofing, authentication, consent, and executed actions across human and non-human actors. It matters because split logs prevent teams from reconstructing what the agent was allowed to do and what it actually did.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
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.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org