By Adam Wolf

AI agents are being deployed faster than the identity systems underneath them can keep up. Service accounts, inherited credentials, and shared API keys are how most agents authenticate today, and the security and standards communities have started to call that out as a structural problem rather than an implementation detail.

Klique was built around a different premise: that every agent deserves its own identity, federated with the same systems that govern human users. Here is what the data says, what the emerging standards are doing about it, and how Klique closes the gap.

A breach that should have changed how we think about agent credentials

In August 2025, attackers tracked as UNC6395 stole OAuth and refresh tokens from Salesloft’s Drift chat agent integration with Salesforce. Over roughly ten days, the campaign reached more than 700 organizations, including Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint, Tanium, Zscaler, and Cisco. The attackers used the stolen tokens to query Salesforce environments at scale, pull customer support data, and harvest embedded secrets from support tickets.

The Drift compromise was not a novel attack on the LLM. It was a textbook OAuth token theft against an AI agent that had been wired into a hundred enterprises’ most sensitive customer relationship data. The agent had broad, persistent access. The tokens it held were long-lived and rarely rotated. When the agent’s credentials were compromised, every downstream tenant inherited the breach.

Verizon’s 2026 Data Breach Investigations Report treated Salesloft Drift as the canonical example of a new pattern: AI agents and the non-human identities they rely on are now a primary attack surface, and traditional identity controls do not address them. That gap, the gap between how agents are deployed and how they should be governed, is exactly what Klique was designed to close.

The data on non-human identities is unambiguous

The category the security industry has settled on is non-human identity, or NHI. It is the umbrella term for service accounts, API keys, OAuth grants, machine credentials, and increasingly, AI agents. Three data points worth taking seriously:

First, Sophos’ State of Identity Security 2026, a vendor-agnostic survey of 5,000 IT and cybersecurity leaders across 17 countries published in May 2026, found that 71% of organizations suffered at least one identity-related breach in the past year, and that weak management of non-human identities was the root cause of 41% of those breaches. Average remediation cost: $1.64 million. Only 34% of organizations regularly audit or rotate service accounts and NHIs at all. Just 11% do so continuously.

Second, Gartner named “Identity and Access Management Adapts to AI Agents” as Trend 4 in its Top Cybersecurity Trends for 2026, published in February. The framing matters. Gartner is not describing AI agent identity as an emerging risk to monitor. They are describing it as a structural shift that traditional IAM strategies were not designed for and a top-six priority for CISO attention this year.

Third, the ratios. Multiple 2025 and 2026 industry reports place the ratio of non-human to human identities in enterprise environments between 40:1 and 100:1, with some hyper-automated organizations significantly higher. Sophos uses the 100:1 figure directly. The ratio is widening every quarter as agents proliferate and the identity practices built for humans simply do not scale to that math.

This is the environment Klique is built for. When the platform was being designed, the question on the table was not whether agents needed identity. It was whether enterprises could afford to keep treating them like another service account.

Why service accounts were never the right fit for agents

Most AI agents in production today authenticate one of three ways. The first is a static API key for an LLM provider, often the personal key of the developer who built the agent. The second is a service account, frequently shared across multiple agents or workloads, with permissions that drift upward over time. The third is an OAuth grant that was issued for a specific use, then quietly reused for everything else the agent learned to do.

Each of these is a workable pattern for a specific type of integration. None of them was designed for what AI agents actually do.

The structural mismatch comes down to four things, and Klique is designed to answer each of them at the platform level rather than leaving them to the agent harness.

Identity is bound to the wrong actor. An agent that runs on a developer’s API key is, from the resource server’s perspective, the developer. When that key is rotated, the agent dies. When that developer leaves the company, the agent either dies or, more often, keeps running with credentials no one is monitoring. In Klique, every agent gets its own platform identity. It is not the developer’s key. It is not a shared service account. It is the agent itself, registered, named, and governable.
Permissions accumulate without governance. Service accounts shared across agents tend to get the union of every permission any one agent ever needed. The 2026 NHI literature consistently finds that the overwhelming majority of NHIs carry privileges well beyond their operational function, and once granted, those privileges are almost never revoked. Klique’s answer is to make every agent its own tenant, with its own scoped access policies, resource quotas, and scheduling priority. The platform’s multi-tenancy machinery enforces the boundary. It is not built into the agent harness, where it can be bypassed or forgotten.
There is no concept of acting on behalf of a user. When an agent acts on behalf of a person, traditional service account authentication has no way to encode that relationship. The downstream resource server sees the agent’s credentials, not the user’s. Audit logs show what the agent did. They do not show who asked. Klique’s AI Identity Federation passes end-user tokens through at request time, so the call is attributable end-to-end. The agent has its own identity. The user has theirs. The audit trail shows both.
Lifecycle is decoupled from purpose. A service account exists until someone remembers to delete it. An AI agent might exist for a single task, or for a six-month project, or indefinitely. The credential lifecycle was built for the former and is being used for all three. Klique ties agent lifecycle to the same identity provider lifecycle that already governs human users. When the creator leaves the company, the agent’s access flows through the same offboarding that the rest of the company already runs.

This is the gap. It is not that service accounts are insecure in the absolute. It is that they were designed for predictable workloads with stable scopes, and AI agents are neither. The same RBAC, the same SSO, and the same lifecycle controls that govern human users have to govern agents, because the alternative is the ratio data above continuing to widen.

What agent identity actually looks like

The good news is that the standards work has moved meaningfully in the last 12 months. The shape of the answer is becoming clear, and Klique’s architecture maps cleanly to where the consensus is heading.

The Model Context Protocol (MCP), which has become the de facto interface between agents and tools, added OAuth 2.1 support for its HTTP transport in January 2026. The profile mandates PKCE, prohibits the implicit and password grants, and tightens redirect handling.

In other words: the protocol that most agents now use to call external systems is explicitly adopting modern OAuth security, not letting agents hold long-lived static credentials.

In parallel, the OpenID Connect for Agents (OIDC-A) proposal extends OIDC with agent-specific claims: agent identity representation, delegation chain validation, attestation, and capability-based authorization. The Cyber Security Agency of Singapore’s October 2025 Addendum on Securing Agentic AI takes the next step and treats identity spoofing as a named threat, requiring trusted agent registries and short-lived OAuth/OIDC tokens for every agent.

Across all of this work, a consistent architectural pattern is emerging. It has three pieces, and each one is a first-class concept inside Klique.

Every agent is its own first-class identity. Not a shared service account, not its developer’s key. A registered, named, governable identity that is the agent itself, with its own lifecycle, scopes, and audit trail. This is what Klique’s end-to-end identity model delivers out of the box. Every agent is born with a managed identity. Access is controlled and auditable from creation to decommission.
Acting on behalf of a user is explicit. When a user invokes an agent, the user’s identity is passed through alongside the agent’s. The downstream resource sees both. The effective authority of the call is the intersection of what the agent is allowed to do and what the user is allowed to do. Practitioners have started calling this the identity intersection rule, and it is exactly what Klique’s AI Identity Federation enforces on every request.
Tokens are short-lived and scoped. Long-lived, broadly-scoped credentials are the Drift breach pattern. Short-lived, narrowly-scoped tokens, issued just-in-time for a specific task, are what the standards work is converging toward, and what Klique issues by default for every agent and every workload that runs through the platform.

None of this is exotic. It is what modern IAM has been moving toward for human users for the last decade. What is new is the recognition that agents need to be treated as first-class participants in the same system, not as second-class machine accounts bolted onto the side. That principle, that the same governance machinery governs everyone, human and non-human, is the spine of Klique’s architecture.

How Klique implements agent identity

Klique’s identity model has four components. They are designed to fit on top of an enterprise’s existing identity infrastructure, not replace it.

AI Identity Federation.

Klique federates with the customer’s existing identity provider, so SSO, RBAC, resource policies, and credential management are governed by the same system the rest of the business already runs on. Every request, whether it comes from a person or an agent, is authenticated and authorized through that federation layer before anything else happens. There is no separate identity store for agents. There is no parallel access control system for AI. One identity system covers everyone.

Every Agent is its Own Tenant.

Each agent in Klique is a first-class tenant with its own access policies, resource quotas, and scheduling priority. Isolation and governance are enforced by the platform’s multi-tenancy machinery. The same RBAC that scopes a human user’s access to data and compute also scopes an agent’s. A runaway agent cannot escape its quota. A misconfigured agent cannot reach data outside its policy boundary. The platform enforces the wall.

End-to-End User Token Pass-through.

When an agent acts on behalf of a user, Klique passes the user’s token through at request time. The downstream system, whether it is an LLM endpoint, a database, an internal API, or a third-party tool, sees both identities. The audit log shows the agent that executed the call and the user who initiated it. Accountability is preserved end-to-end. The identity intersection rule is enforced by the platform, not by trust in the agent itself.

A Four-Tier Governance Model.

Klique’s governance hierarchy maps to how enterprises actually organize. Cluster admins control infrastructure. Tenant admins set organization-wide policies. AI builders, both human and agent, work within project-scoped boundaries. AI consumers, both human and agent, self-serve within the guardrails set above them. The model is the same for people and agents, because the same four tiers govern both. There is no separate org chart for non-human actors.

The architectural commitment that ties these together is simple: agents are not second-class.
The same identity, the same governance, the same audit posture that an enterprise applies to its human workforce applies to its agents, because the alternative is what the Sophos and Drift data describe.

What to ask any AI platform about agent identity

Most enterprises will not implement OIDC-A or build a trusted agent registry themselves. Identity infrastructure is hard to get right, and the cost of getting it wrong is exactly what the breach data shows. The realistic path forward is for AI platforms to absorb this complexity on behalf of the teams running them.

When evaluating an AI platform on agent identity, the questions that matter are concrete.

Does each agent get its own identity that is registered, owned, and governed, or does it inherit the credentials of whoever deployed it?
When the agent acts on behalf of a user, does the user’s identity travel with the call, so that downstream systems and audit logs see who actually asked?
Does the platform federate with your existing identity provider, so that the same RBAC, the same SSO, and the same lifecycle controls govern both humans and agents?
Are agent credentials short-lived and scoped to specific tasks, or long-lived and broadly permissive?
When an agent is decommissioned, or its creator leaves the organization, what happens to its credentials and its access?

These are the questions a CISO or a head of platform engineering should be asking any vendor pitching them an agent-enabled AI platform in 2026. Klique answers each of them at the platform level, with the same machinery that governs the human users the enterprise already trusts.

The end of the service account era

The Salesloft Drift breach happened because an AI agent’s OAuth tokens were stored in a way that did not match the trust the agent had been granted. That is not a unique failure. It is the failure that the entire NHI category is built to address, and it is the failure that the next several years of agent identity work are organized around.

If your enterprise is deploying AI agents in 2026, the service account era is already ending. The question is whether you end it on your own terms or learn the same lesson the way Drift’s customers did. Klique was built so that enterprises do not have to choose. The same identity system that governs your workforce can govern your agents. The same audit trail covers both. The same offboarding workflow handles both. The walled garden is real, and the agents inside it act with their own identity, not someone else’s.

That is the architectural commitment behind Klique. The standards are still evolving, the threat landscape is still moving, and the right approach in a year will probably look different from the right approach today. But the principle is settled. Agents are not service accounts. They should not be deployed like service accounts. And the platform layer is the right place to enforce that, because it is the only layer that sees every agent, every user, and every resource in one place.

If you would like to see how Klique’s AI Identity Federation fits into your AI infrastructure roadmap, get in touch.