For years, cybersecurity leaders have worried about stolen passwords.
Now consider a different scenario.
An attacker discovers an internet-facing AI application. A software flaw has inadvertently disabled the authentication protecting it. The attacker gets inside, instructs an AI agent running on the server to reveal an API key, and then uses that key for three weeks.
The result?
Approximately $600,000 in unauthorized AI model credits consumed.
That is what happened to AI evaluation nonprofit Metr, according to a recent report from DataBreachToday.
Fortunately for Metr, the model developer had provided those credits at no cost, so the organization wasn't presented with a $600,000 bill. Metr also said its investigation found no evidence that the attacker obtained anything beyond an API key providing access to publicly available models.
But I think focusing only on the dollar amount misses the more important story.
An API key isn't merely a secret anymore.
In an AI-driven enterprise, credentials increasingly represent authority, capability and economic power.
And that means we need to start treating machine identity with the same seriousness we have historically reserved for human identity.
The Attack Didn't Begin With Some Exotic AI Technique
One of the most interesting aspects of this incident is how ordinary its beginnings were.
According to Metr, a researcher was running AI agents on a personal cloud server. An application on that server was accessible from the internet and was supposed to require Google authentication.
But a software flaw disabled authentication.
The application had been built using AI-assisted "vibe coding" and remained exposed to the public internet for several days. Metr suspects an attacker may have discovered it while searching newly registered AI-related websites for exposed model-provider credentials.
Once inside, the attacker reportedly instructed an AI agent running on the server to disclose Metr's API key. The attacker also installed an SSH key to maintain access.
There's something almost ironic about that sequence.
An AI application helped create the environment.
An authentication failure opened the door.
An AI agent was asked to reveal the credential.
And the stolen machine credential provided the economic capability.
This wasn't simply an AI attack.
It was a trust failure occurring inside an AI environment.
And I believe we're going to see many more variations of this problem.
We Need to Stop Thinking of Identity as Exclusively Human
When most executives hear "identity security," they still naturally think about people.
Employees.
Customers.
Administrators.
Contractors.
Privileged users.
But the enterprise identity population is changing rapidly.
Applications have identities.
APIs have credentials.
Service accounts have privileges.
Workloads authenticate to other workloads.
AI agents increasingly interact with applications, databases, cloud services and other agents.
And unlike a human employee who eventually goes home for the evening, machine identities can operate continuously and at extraordinary speed.
That changes the potential consequences of misplaced trust.
A compromised employee account might allow an attacker to perform whatever actions that employee is authorized to perform.
A compromised machine credential can potentially allow automated systems to perform authorized actions thousands or millions of times.
The identity problem hasn't disappeared.
It has become machine-speed.
Authentication Is Only the Beginning
There's another lesson here that I believe is particularly important.
We often talk about authentication as though successful authentication completes the security decision.
It doesn't.
Authentication answers:
Who are you?
Authorization answers:
What are you permitted to do?
But in an AI environment, we increasingly need additional questions:
What resource is requesting access?
What service is it communicating with?
What authority has been delegated to it?
What is the purpose of the request?
How long should that authority exist?
How much can it consume?
And at what point should a human have to approve what happens next?
That last question is going to become particularly important.
AI dramatically expands what software can do autonomously.
Security therefore has to become much more deliberate about what software should be allowed to do autonomously.
$600,000 Is an Authorization Story
Consider the stolen API key itself.
Once the attacker possessed it, the key apparently provided enough authority to consume approximately $600,000 worth of model credits over three weeks.
Why wasn't that activity immediately stopped?
Metr explained that its evaluations normally consume large numbers of tokens and routinely generate rate-limit and API errors. Its monitoring also didn't show all rejected requests. And because the model credits had been provided for free, there was no spending limit to trigger an alert or stop the activity.
That's fascinating from a security perspective.
The activity could hide, at least temporarily, inside behavior that wasn't necessarily unusual for the environment.
The credential was usable.
The service accepted it.
The consumption continued.
Which leads to an uncomfortable question:
Should possession of a valid machine credential automatically confer everything that credential is technically capable of doing?
In an increasingly autonomous environment, I don't think the answer can always be yes.
Least Privilege Is About to Become Much More Important
Metr's response is instructive.
After the incidents, the organization said it formalized security reviews for researchers placing applications on the public internet and added spending alerts to API keys.
It also isolated public-facing applications from internal systems, expanded logging and monitoring, shortened credential lifetimes, reduced permissions, hired a security lead and shut down legacy infrastructure that increased its attack surface.
Those aren't merely cleanup measures.
They point toward the architecture enterprises will increasingly need as AI adoption accelerates:
Short-lived credentials.
Scoped permissions.
Isolation.
Continuous monitoring.
Usage limits.
Context-aware authorization.
Human approval for consequential actions.
In other words:
Give machines enough authority to accomplish the task, not enough authority to become the incident.
AI Agents Will Force Us to Separate Identity From Authority
This is where I believe the AI conversation becomes particularly interesting.
Suppose an employee authorizes an AI agent to perform a task.
That creates several identities and trust relationships simultaneously.
There is the human.
There is the agent.
There is the service the agent is attempting to access.
There is the credential being used.
There is the authority delegated by the human or organization.
And there is the action the agent ultimately wants to perform.
Those things cannot simply collapse into:
"The credential is valid, therefore proceed."
The credential might be valid while the context is wrong.
The agent might be legitimate while the requested action is inappropriate.
The human might be authorized while the agent has been granted excessive privileges.
The destination might be authentic while the amount being spent is abnormal.
Or, as Metr experienced, a legitimate credential might simply have fallen into someone else's hands.
Identity tells us who or what is acting. Trust determines whether we should allow what happens next.
This Is Bigger Than API-Key Management
It would be easy to read this incident and conclude that organizations simply need to protect API keys better.
They do.
But I think that interpretation is too narrow.
This incident points toward a much larger transition taking place across enterprise security.
We are moving from an environment dominated by human identities using applications toward one populated by humans, applications, APIs, workloads and autonomous agents acting on one another's behalf.
That means our trust model has to evolve with them.
At Identité®, we've been arguing that modern digital trust needs to answer more than a single question at login.
It increasingly needs to consider:
Identity + Authentication + Destination + Intent + Context + Authorization
Full Duplex Authentication® is part of that broader philosophy because trust shouldn't simply flow in one direction. The party requesting authentication matters too.
But AI extends the challenge even further.
When machines begin acting for us, we also have to establish who authorized the machine, what authority was delegated, where that authority can be exercised, how long it should exist and when a human needs to return to the decision.
That's not merely stronger authentication.
That's a different architecture for trust.
The Most Dangerous AI May Be the AI We Authorized
Cybersecurity discussions about artificial intelligence understandably focus on what attackers will do with AI.
Better phishing.
Faster reconnaissance.
Automated vulnerability discovery.
More convincing impersonation.
Those threats are real.
But there is another AI security problem developing inside our own organizations.
We are rapidly giving machines credentials, access and authority because doing so creates enormous productivity.
And we should.
The objective shouldn't be to prevent AI agents from acting.
It should be to make sure their authority is proportional to the task, limited in duration and difficult to inherit or steal.
Because the next compromised API key might not provide access to $600,000 in free model credits.
It might authorize financial transactions.
Access customer records.
Modify production systems.
Move sensitive data.
Trigger workflows.
Or instruct another AI agent to act.
The economic consequences of machine identity compromise will increasingly be determined not simply by whether the attacker gets a credential.
They will be determined by how much authority we've attached to it.
The Question Security Leaders Should Be Asking
The Metr incident gives us a useful glimpse into a future arriving faster than many organizations realize.
The security question is no longer simply:
"How do we authenticate our people?"
It is becoming:
"How do we establish and govern trust among people, machines and autonomous agents?"
That requires us to think differently about authentication, authorization, intent, context, privilege and identity itself.
Because in an AI-driven enterprise, a credential may no longer simply unlock an account.
It may unlock capability.
And when capability can operate autonomously, continuously and at machine speed, the consequences of trusting the wrong identity can scale just as quickly.
The more authority we give machines, the more deliberately we must control who, or what, is allowed to exercise it.
Attackers don't have to defeat every security control.
They only have to become someone, or something, those controls have been taught to trust.
And in the age of AI, "something" may become the most important word in that sentence.