Topic starter
10/06/2026 11:27 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by 1Password: “Introducing 1Password® Unified Access: Identity Security for Humans and Their AI Agents”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 5:25 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Unified access for AI agents exposes the limits of login-based IAM
This post was modified 2 days ago by NHI Mgmt Group