Home > Security and Compliance Blog > Cybersecurity Risk Management > AI Agents Are Still Logging In as Humans – and Your Audit Trail Is Paying for It

AI Agents Are Still Logging In as Humans – and Your Audit Trail Is Paying for It

by Patrick Spencer updated July 21, 2026 Cybersecurity Risk Management

Reading Time: 12 minutes

Enterprises have spent the last four years bolting AI agents onto identity infrastructure that was never designed to recognize them as distinct actors. That mismatch is now visible in the data, not just in incident postmortems. A new report built on anonymized sign-on activity from more than 20,000 organizations shows AI agents operating inside enterprise environments largely the same way they did when generative AI first arrived: authenticated as, or through, a human.

The report is the Okta Enterprise AI Index, and it draws on sign-on data spanning June 2022 through June 2026 across more than 100 distinct AI products, consolidated into 74 vendor suites for analysis. The scale of the dataset is what makes the finding hard to dismiss as an edge case. This is not a story about one vendor’s misconfiguration or one company’s rushed AI rollout. It’s a pattern across tens of thousands of organizations that are choosing, or simply defaulting into, the same way of authorizing AI agent workflows.

Table of Contents

The headline growth numbers are dramatic. AI-native companies such as Anthropic, OpenAI, and Cursor more than quadrupled their enterprise customer base over the study period, and Anthropic passed OpenAI in total enterprise accounts in March 2026, then overtook it in monthly active users the following month. Those milestones say something real about how quickly agentic AI has moved from experimentation to standard enterprise tooling. But the more consequential finding sits underneath the growth curve: identity and access practices for AI agents have not kept pace with how fast those agents are being deployed.

Kiteworks secure data exchange was built around a different premise: every actor touching sensitive content, whether human or machine, needs a verifiable identity, scoped permissions, and its own entry in the audit trail. That premise is exactly what this report finds missing in most enterprise AI deployments today.

Key Takeaways

1. Enterprise AI adoption has outrun enterprise identity practices.

New sign-on data covering four years and more than 20,000 organizations shows AI-native vendors growing enterprise accounts more than 4x, while the identity model behind those tools has barely changed since the pilot-project era.

2. Agents still borrow human credentials.

Service accounts, static API keys, and shared human logins remain the default way organizations authorize AI agent workflows, according to Okta researcher Fei Liu, and each of those methods was built for a world without autonomous software actors.

3. A borrowed login means a broken audit trail.

When an AI agent authenticates as a person, logs show that person’s name attached to actions the person never took, which makes it nearly impossible to reconstruct what an agent actually did during an incident review.

4. The Anthropic-OpenAI enterprise race is a symptom, not the story.

Anthropic overtaking OpenAI in enterprise accounts and monthly active users in early 2026 confirms how fast agentic AI is moving into core business workflows, faster than most identity and access programs have adapted to govern it.

5. Agent-scoped access control closes the gap.

Assigning each AI agent its own governed identity, permissions, and audit record, rather than routing it through a human’s session, is the difference between a governable AI deployment and an ungoverned one.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Service Accounts, Static API Keys, and Shared Logins: Three Ways Agent Identity Breaks Down

According to Fei Liu, the Okta researcher quoted in the report, organizations rely heavily on three mechanisms to authorize AI agent workflows: service accounts, static API keys, and, in some cases, shared human logins. Each solves a short-term integration problem. Each also creates a longer-term governance problem that most organizations have not yet reckoned with.

Service accounts are the most common of the three. They let an AI agent act as a designated non-human identity within an application, which sounds like the right approach until you look at how those accounts are usually provisioned and monitored. Many service accounts are created once, granted broad access controls to satisfy whatever the agent might eventually need to do, and then left alone. Nobody revisits the permissions as the agent’s role expands. Nobody ties individual actions back to a specific task, request, or business justification. The account exists, the agent uses it, and the resulting logs describe the account rather than the work. Applying data classification labels to the content service accounts can access is the prerequisite that makes access scoping precise — without it, a governance program cannot enforce sensitivity-based restrictions on what an agent reaches through that account.

Static API keys carry a related set of problems, compounded by how they’re handled operationally. A key that authorizes an agent to read files, query a database, or call an internal system typically doesn’t expire, doesn’t rotate automatically, and often gets copied into configuration files, environment variables, or, worse, directly into a prompt or agent context window where it can be exposed, logged, or exfiltrated without anyone noticing. Once that key exists in more than one place, “who has access” stops being a question anyone can answer with confidence.

The third pattern, shared human logins, is the most concerning because it collapses the distinction between person and process entirely. An employee’s credentials get handed to an automation script, a bot, or an AI agent so it can act “as” that person inside a system that has no separate provisioning path for machine identities. From that point forward, every action the agent takes shows up in logs as if the human performed it. A confirmed data breach routed through a shared human login that an agent used leaves organizations unable to scope the breach accurately — notification obligations under HIPAA, GDPR, or comparable frameworks apply to the maximum possible exposure unless affirmative evidence narrows it, evidence that a mixed human-agent audit trail cannot provide.

Why “When an AI Agent Inherits a Human’s Login, You Lose the Audit Trail” Should Worry Every CISO

Liu’s warning in the report is direct: “when an AI agent inherits a human’s login, you completely lose your audit trail.” That sentence describes a specific, mechanical failure, not a vague risk. An audit trail is only useful if it can tell you, after the fact, who did what, when, and why. Once an agent is acting under a human’s session, that trail records the wrong actor for every single event. The name in the log is correct. The story it tells is not.

This matters most in the moments an audit trail is actually needed: a breach investigation, a compliance audit, a regulatory inquiry, or an internal review of how a piece of sensitive content moved through the organization. In each of those scenarios, someone eventually asks a version of the same question: did a person do this, or did an automated process do this, and under what authority? If the answer is “we can’t tell, because the agent was logged in as Sarah,” the investigation stalls, the compliance response weakens, and the organization can’t demonstrate the kind of access controls that frameworks such as NIST CSF, ISO 27001, and SOC 2 all expect as a baseline. Feeding a clean, agent-attributed audit log in real time into a SIEM platform is the operational mechanism that converts agent attribution from a forensic tool reviewed post-incident into a behavioral detection layer that surfaces anomalous agent activity before a breach event completes.

There’s also a quieter cost that shows up long before any incident: accountability erodes gradually, in the ordinary course of business. When nobody can say with certainty which actions were taken by a person and which were taken by an agent, exception approvals, data access reviews, and least-privilege enforcement all get harder to run correctly. Reviewers start approving broad access because narrowing it feels risky when they can’t isolate what the agent specifically needs. That’s how security misconfiguration compounds over time, not through one bad decision but through many reasonable-seeming ones stacked on top of an identity model that was never built to separate humans from the software acting on their behalf.

Shadow AI Is an Identity Problem Before It’s a Data Problem

Most conversations about shadow AI focus on where sensitive data ends up: an unsanctioned model, an unapproved plugin, a browser extension nobody vetted. That’s a real concern, but the Okta data points at something upstream of it. Before an agent can move or expose data, it has to authenticate somewhere. If that authentication step routes through a shared account, an unmanaged API key, or a borrowed login, the organization has already lost visibility before the data governance question even comes up.

This is why identity deserves top billing in any AI governance conversation, not a footnote under data loss prevention. An agent with a scoped, well-managed identity is constrained by design: it can only reach what its role permits, and every action it takes is attributable to that specific agent and task. An agent operating under a human’s session or a broadly-provisioned service account isn’t meaningfully constrained at all; its actual reach depends on whatever that human or that account happens to have access to, which is often far more than the agent’s task requires. AI data governance programs that start with policy documents but skip identity architecture are solving the easier half of the problem. Shadow AI — agents and AI tools operating outside any sanctioned identity program — is the direct consequence of that gap: ungoverned agents that the organization cannot see, cannot scope, and cannot attribute actions to when an incident surfaces.

The Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report identifies AI governance as one of the defining data security priorities organizations face this year. The Okta findings reinforce that conclusion from a different angle: agentic tools have been adopted faster than the zero trust identity and access controls needed to govern them. Supply chain risk management programs that extend identity governance requirements to third-party AI vendors — covering the agents those vendors deploy inside customer environments, not only the tools customers deploy themselves — close the supply chain identity gap that the Okta data suggests most organizations have not yet scoped.

How Kiteworks Gives Every AI Agent Its Own Verifiable Identity

Kiteworks approaches this problem from the same starting point the Okta findings point to: humans and AI agents are both first-class identities that need to be authenticated, authorized, and logged individually, under one governance layer rather than two separate ones. The Kiteworks Control Plane governs every request for sensitive content, whether it comes from a person, an application, or an agent, through that single model, so an agent’s access is never routed through a workaround like a borrowed human credential or an unmanaged service account.

The Secure MCP Server is the piece purpose-built for this moment. It authenticates through OAuth 2.0, with the access token stored in the operating system’s secure credential store rather than anywhere the AI model itself can read, copy, or leak it. That is a meaningfully different design than handing an agent a static API key or a shared human password: the agent never holds a credential it could expose through a prompt, a log file, or a compromised session. Every operation the agent performs, whether reading a file, navigating a folder, or retrieving content for a task, is evaluated against RBAC and ABAC policy in real time and logged on its own terms, rather than folded into a single, generic entry that simply says a person did it. That is the structural answer to Fei Liu’s warning: when the credential never leaves a secured store and every action is authorized and logged individually, there is no shared identity for the audit trail to lose track of. The CISO Dashboard surfaces this agent-level audit telemetry in real time, giving security leadership the unified visibility across all AI-mediated content access events that the Okta report identifies as missing from most current deployments.

Kiteworks Compliant AI applies that same discipline to what agents can see and use, not just how they authenticate. Content-level policy enforcement determines what an agent is permitted to access or withhold before the content ever reaches the model’s context window, so the identity boundary and the data boundary reinforce each other instead of one depending entirely on the other holding. Data minimization applied at this layer — ensuring each agent receives only the minimum content its current task requires — reduces blast radius when an agent credential is exposed, since the agent’s accessible scope is already constrained by design.

Building an Agent-Scoped Access Control Model with RBAC and ABAC

Solving the identity gap means moving beyond “does this agent have a credential” to “does this specific agent, for this specific task, have the specific permission it needs right now.” That’s a role- and attribute-based question, not a static provisioning question.

Role-based access control (RBAC) gives each agent a defined role scoped to its actual function. Consider a summarization agent that only needs read access to the documents it summarizes, or a workflow agent that files records and needs write access to one specific folder, and nothing more in either case. Attribute-based access control (ABAC) adds context to that role: the sensitivity classification of the content, the time of the request, the agent’s deployment environment, and the task it’s currently executing all factor into whether a given request is authorized. Together, RBAC and ABAC let an organization grant an agent exactly the access its current task requires and nothing it might need someday, which is the opposite of how most service accounts are provisioned today.

This model also produces something the Okta report highlights as missing: a clean audit log where every entry names an actual agent, tied to an actual task, evaluated against an actual policy, not a person’s name standing in for work they never did. When an incident review or compliance audit asks what happened, the answer is already in the log, attributed correctly the first time. A documented incident response plan that covers AI agent misfire scenarios — specifically the steps for isolating a compromised agent identity, revoking its credentials, and scoping what content it accessed — converts the clean audit log from a forensic asset into an operational response capability.

What Enterprises Should Do Now to Close the AI Agent Identity Gap

The scale of the Okta dataset (four years, 20,000-plus organizations, over 100 AI products) makes clear this isn’t a problem confined to early adopters or laggards. It’s close to universal, which means most security and identity teams have work to do regardless of how mature their AI governance program already is.

A few starting points follow directly from the report’s findings. First, inventory every AI agent currently operating in the environment and identify exactly which credential each one uses: service account, API key, or human login. You can’t fix what you haven’t mapped. Second, treat any agent authenticating through a shared human login as an immediate priority for remediation, since that pattern produces the most severe audit trail loss described in the report. Third, evaluate whether your current IAM infrastructure can actually provision distinct, scoped identities for non-human actors, or whether it was built with only people in mind. Fourth, build agent access decisions around zero trust data exchange principles: verify every request, grant the minimum necessary access, and log the outcome, rather than trusting an agent by virtue of the account it happens to run under. A formal risk assessment that maps each agent’s current credential type and permissions against its actual task requirements — and identifies where shared credentials or over-provisioned service accounts create unacceptable exposure — is the evidentiary foundation for a prioritized remediation roadmap.

None of this requires waiting for a breach to justify the work. The Okta data describes a structural gap in how enterprises authorize AI agents today, not a hypothetical future risk. Closing it now, while agentic AI adoption is still accelerating, is considerably cheaper than reconstructing an audit trail after the fact discovers it never existed.

To learn more about giving AI agents their own governed identity instead of borrowed human credentials, schedule a custom demo today.

Frequently Asked Questions

The Okta Enterprise AI Index is a report built from anonymized sign-on data spanning more than 20,000 organizations from June 2022 through June 2026, covering over 100 distinct AI products consolidated into 74 vendor suites. It tracks how enterprises adopt AI tools and, notably, how those tools are authenticated and authorized within corporate environments. The report found that AI agents are still commonly authorized through service accounts, static API keys, or shared human logins rather than through identities scoped specifically to the agent. Organizations evaluating their own exposure to this pattern can start by reviewing how their IAM infrastructure currently provisions non-human actors. Those subject to regulatory compliance obligations — HIPAA, GDPR, CMMC — should treat the authentication gap the Okta report documents as a compliance finding, since these frameworks require demonstrable access controls and audit records regardless of whether the accessor is a human or an agent.

A service account is typically provisioned once with broad permissions meant to cover whatever the agent might eventually need, then rarely revisited. That means the agent often has far more access than its current task requires, and every action it takes gets attributed to the account rather than to a specific, traceable task. This breaks the principle of least privilege and weakens the access controls that compliance frameworks expect organizations to maintain. Agent-scoped identities, by contrast, can be limited to exactly what a given task requires. Data minimization applied to service account scope — provisioning each agent with access only to the specific data sources its designated task requires — is the operational practice that converts least-privilege from a policy intent into a runtime reality.

When an AI agent authenticates using a person’s credentials, every action it performs gets logged under that person’s identity, even though the person never took those actions. This makes it functionally impossible to distinguish human activity from agent activity during a security investigation, compliance audit, or incident response process. Fei Liu of Okta describes this precisely: once an agent inherits a human login, the audit trail is lost because the record no longer reflects who or what actually did the work. Agent-scoped credentials prevent this by ensuring every log entry names the actual actor. Organizations should also verify that their SIEM alert configurations treat anomalous patterns in agent-attributed log entries — unexpected access times, unusual data volumes, or out-of-scope resource requests — as high-priority detection signals rather than background noise.

The Secure MCP Server is Kiteworks’ governed connection point for AI agents using the Model Context Protocol to access enterprise content. Rather than issuing an agent a static credential it can hold or expose, it authenticates through OAuth 2.0 with the token stored in the operating system’s secure credential store, and it evaluates every request against RBAC and ABAC policy in real time. This keeps credentials out of the agent’s reach entirely, which is the specific failure mode the Okta report describes when agents inherit human logins. Data classification applied to the content the Secure MCP Server governs makes ABAC enforcement precise — access decisions can distinguish between public-tier and confidential-tier content at the moment of each agent request, rather than applying a single blanket permission to the agent’s entire accessible scope.

Not necessarily. The more urgent step is provisioning AI agents as their own class of governed identity, alongside human users and under the same policies, rather than routing agents through human sessions or generic service accounts as a workaround. Kiteworks does this through the Kiteworks Control Plane, which governs access, use, and exchange of sensitive content for both humans and agents under one set of policies, combined with RBAC and ABAC controls scoped to each agent’s actual task. A risk assessment that maps which agents currently operate through shared credentials — and prioritizes remediation by the sensitivity of the content those credentials can access — gives identity and security teams the focused starting point that makes agent identity remediation tractable rather than overwhelming.

Additional Resources