In August 2025, attackers walked out with data from more than 700 organizations without ever guessing a password. They compromised a single AI sales-automation integration, stole its long-lived OAuth tokens, and used those tokens to impersonate the integration itself across every connected Salesforce instance. No human credential was phished. The agent’s credential was the target, and it was standing there, reusable, for anyone who found it.
That incident, the Salesloft Drift-to-Salesforce breach, has become the reference case for a problem enterprises are only now naming properly: AI agents have been authenticating with borrowed, standing, overly broad access, because that is the access pattern identity systems were built for humans and simple service accounts, not for software that acts on its own.
Two developments this year mark the start of a correction. In July, Anthropic and 1Password launched an integration that lets Claude complete logins without ever seeing the password. And across the identity industry, analysts and researchers have started treating “agent identity” as its own category, distinct from both human and traditional machine identity. Together they point to the same conclusion: the credential model enterprises inherited from decades of human and service-account access will not hold up under agentic automation. Agents need an identity layer built for them.
The old pattern: agents wearing borrowed credentials
Until recently, giving an AI agent access to a system meant one of a few equally uncomfortable options: hand it a human’s saved password, issue it a static API key, or create a service account with standing, always-on permissions. In each case, the credential was long-lived, broadly scoped, and sitting somewhere the agent, or whoever configured the agent, could see it in full.
That pattern is now a documented source of exposure, not a theoretical one. Research into AI-related secrets leaks found that credentials tied to AI services and coding assistants were leaked at a sharply higher rate than the rest of the codebase in 2025, and flagged Model Context Protocol configuration files specifically, since MCP setup documentation commonly recommends embedding credentials directly in config files, a pattern that alone contributed to tens of thousands of exposed secrets. An agent with a standing credential in its context or its config is an agent whose credential can leave with it, intentionally or not.
A human with a leaked password is one identity to contain. An agent with a leaked credential can chain that access across every tool, API, and system it was authorized to touch, at machine speed, with no one in the loop to notice the pattern until the damage is done.
What changes with a broker model
1Password for Claude, released in July, is a useful concrete example of the alternative, not because it is the only vendor building one, but because it makes the architecture visible. Instead of handing Claude a password, 1Password sits between the agent and the credential as a broker. When Claude needs to log in somewhere, it requests the credential for that specific task. The user approves the request with a biometric prompt, scoped to that item, for that session. 1Password then injects the credential directly into the target page. The password, the one-time code, whatever the secret is, never enters the model’s context, its memory, or the conversation log.
A companion feature, Agentic Mode, tightens this further at the browser level: the moment an agent takes control of the browser, the vault locks down automatically to only the items explicitly granted for that task. Nothing else in the vault is reachable, even if the agent is compromised or misdirected mid-session.
Strip away the branding and this is a specific instance of a broader architectural shift: from static secrets an agent holds, to scoped, short-lived authorizations an agent requests and a broker fulfills. The agent proves what it is and what it is trying to do. It never has to prove it by holding the secret itself.
From standing, borrowed access to scoped, brokered authorization
Why this is bigger than one integration
The reason this matters to every CIO and CISO, not just Claude users, is scale. Machine and agent identities already outnumber human identities inside the average enterprise by roughly 82 to 1, and that ratio is climbing as agentic deployments spread from pilots into production. Gartner’s 2026 Hype Cycle for Digital Identity names AI agents and workloads the fastest-arriving new category the field has seen, and its Emerging Tech Impact Radar calls out identity, authorization, delegation, and auditability for AI agents as a high-impact gap actively blocking enterprises from scaling agentic systems with confidence.
The governance infrastructure has not caught up. A January 2026 survey of 383 security leaders, run by Oasis Security with the Cloud Security Alliance, found that the large majority are not confident their existing identity tools can manage AI and non-human identity risk at all, and most reported having no formally adopted policy for how AI identities get created or retired in the first place. A separate CSA analysis found that a meaningful share of organizations do not even track the creation of AI-related identities, which means the first control most enterprises are missing is visibility itself: knowing how many agents exist, what they can reach, and who authorized them.
The market is already repricing around this gap. Analysts covering non-human identity access management put the category at roughly $11 billion in 2025, on a trajectory toward the high thirty-billions within a decade, a growth curve well ahead of most other categories of security spend. That is capital moving toward a problem that, eighteen months ago, most identity teams had not yet been asked to solve.
The agent identity gap, in numbers
Sources: CyberArk 2025 Identity Security Landscape; Oasis Security & Cloud Security Alliance, Jan 2026; Gartner Hype Cycle for Digital Identity, 2026; Meticulous Research; Google Threat Intelligence / Mandiant on the Salesloft Drift breach.
What this means for enterprise architecture
None of this argues against giving agents access. It argues for governing that access as its own discipline, with its own controls, rather than stretching human-identity assumptions to cover software that acts continuously and autonomously. In practice, that means treating a handful of principles as non-negotiable for any agentic deployment touching production systems.
- Replace standing access with scoped, short-lived authorization. A credential that exists permanently and works whenever it is used is the pattern every recent agent-related breach has exploited. Task-scoped, time-boxed access should be the default, not the upgrade.
- Keep secrets out of the agent’s context entirely. If a password, key, or token can appear in a prompt, a log, or a config file, it can leave with the agent. Brokered injection, where the agent proves intent rather than holding the secret, closes that path.
- Build a live inventory of every agent identity. You cannot govern what you cannot see. Centralized, automated tracking of agent identities as they are created, and not a quarterly spreadsheet audit, is the baseline for everything else.
- Extend existing IAM and PAM programs explicitly to agents. Agent identity should sit inside the same governance function as human and machine identity, with the same lifecycle discipline: approval, rotation, auditability, and deprovisioning when an agent or its purpose retires.
- Require an audit trail that names the authorizer, not just the action. When an agent acts, the record should show what it did and on whose explicit authority, so accountability does not dissolve into “the AI did it.”
Enterprises that get this right will not be the ones with the most capable agents. They will be the ones whose agents can be trusted with real systems, because access was designed in as a governed layer from the outset rather than patched on after the first incident. That is the same principle OnClik UAA applies across its own agent orchestration, treating identity, authorization, and audit as part of the platform rather than an integration left to each individual agent.
