COMMENTARY: Open your identity console. Look at the user list. Somewhere in there is an account called "
[email protected]" or "data-pipeline-svc@." It has admin permissions. The token rotates whenever someone remembers. And nobody can tell you which actions in the audit log were the agent acting on its own versus on behalf of a real user.
That fault line — between human and machine identity, treated as equivalent because the tools forced it — is where most production AI deployments are quietly accumulating risk. In 2025, 29 million secrets were exposed in
public GitHub commits. AI-service credential leaks were up 81% year over year. Long-lived
service tokens powering AI agents are exactly that surface area, multiplied by every new workflow.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
The agents, pipelines, and automated services powering modern AI applications need to authenticate themselves to APIs, to databases, and to each other. Machine-to-machine authentication isn't new — but it was designed for predictable, programmatic behavior. Static credentials were acceptable when a service only ever did what it was coded to do. AI agents broke that assumption. They're overscoped by default, and prompt injection means those credentials can now be exfiltrated in ways traditional M2M workloads never had to consider.
The human-shaped hole in identity architecture
Customer identity and access management was built around a fundamentally human mental model. A person arrives at a login screen, enters credentials, receives a one-time code, clicks a password reset link. All of it assumes a human in the loop.
None of that was designed for
an AI agent. Human authentication flows were built around intermittent, single-session access. An agent operates continuously, often as multiple simultaneous instances, authenticating with other services in milliseconds. Routing that through human-facing verification flows produces authentication events indistinguishable from human sessions — and an audit log that can't tell you which actions were the agent versus a real user.
Related reading:
This isn't a hypothetical edge case. An orchestration layer calls a data retrieval service. A summarization agent writes results to a database. A customer-facing assistant accesses a user's account on their behalf. In every case, something needs to authenticate itself to something else, and "enter your email and password" isn't an option.
What most teams are doing instead
Many teams are solving this with approaches security professionals would immediately recognize as problematic: API keys in environment variables, shared service accounts with broad permissions, long-lived tokens that rarely rotate. These shortcuts work well enough to ship, which is precisely why they accumulate quietly until they become a serious liability. And worst of all, agent identities created ad-hoc as "users" in the same system that handles human login — which works briefly until someone tries to audit who did what.
Machine-to-machine authentication requires different configuration — short-lived tokens, client credentials grants, scoped permissions tied to specific service identities. These aren't exotic concepts. They exist in modern identity standards, but they're rarely the default when teams are moving quickly.
The compounding problem: agents authenticating on behalf of users
The challenge compounds when agents need to act on behalf of human users. The risk isn't just credential exposure. An over-permissioned agent can surface one customer's data to another, or an LLM can return content the calling user was never authorized to see. A compromised agent's blast radius extends far beyond individual user privileges to encompass every user it's acting on behalf of.
What good looks like
The tools to do this correctly already exist. OAuth 2.0 client credentials grant has been in production for over a decade. Token scoping, automatic rotation, service-specific identity issuance — standard capabilities in any modern identity platform. The standards aren't waiting to be invented.
What's missing is the configuration. And underneath that, the architecture.
Most teams set up their identity systems for human login and never went back. But the more important question is whether the platform they're using can go back — whether it's capable of treating an AI agent with the same architectural seriousness as a human user, or whether agent support got bolted on later because the market demanded it. When that happens, the seams show. Separate data models. Separate audit trails. Relationships that have to be inferred rather than queried.
An agent acting on behalf of a user isn't just an authentication event — it's a relationship. Who authorized it. What scope the user consented to. Which resource the interaction was meant for. That relationship needs to be stored and queryable — not pieced together from audit logs after something goes wrong. "Which agent acted for which user on which resource, and who authorized it?" should be a database query, not a forensic exercise.
Teams that get this right aren't building something new. They're not waiting for their vendor to ship an AI-agent feature. They're finally using what their identity infrastructure was supposed to be capable of.
The window is now
Most organizations are still in the early stages of understanding what their AI system topology looks like: how many agents are running, what they're accessing, how they're proving their identity. That's the moment to get the foundations right, before the shortcuts harden into technical debt.
The security industry is right to worry about what AI can do, but it should also consider whether we can confidently tell which AI system is doing it.
