# The Agent Did Nothing Wrong. That's the Problem.
*Sponsored content — Token Security*
---
Watch an AI agent try to open a CSV file that turns out to be a directory. It fails, adapts, writes a small script to list the contents, recovers, and gets the job done. The whole detour takes four minutes. Nobody planned for it. Nobody could have.
That loop — fail, observe, adapt, continue — is not a bug in how large language models reason. It's the mechanism. It's why agents can handle open-ended tasks that brittle automation never could. And it's exactly why the security models enterprises built over the last two decades are now the wrong tool for the job.
The threat isn't that agents misbehave. It's that agents operating correctly, with broad permissions, create damage that no one predicted because no one *could* predict it.
---
## The Feature That Breaks Your Security Model
Traditional identity and access management was designed around a simple question: what can this account reach? You enumerate credentials, map them to resources, apply least privilege, and audit the logs. The model works because human users and service accounts follow predictable patterns. A billing service calls the billing API. A read-only analyst queries the data warehouse. Behavior is narrow and consistent enough to monitor.
AI agents break this model structurally. Two agents with identical permissions and identical credentials can behave completely differently depending on what each is trying to accomplish in a given session. One might read a few files and write a summary. The other, handed the same keys, might traverse directories, call an external API, write to a shared drive, and draft an email — all in service of a single ambiguous instruction. Past behavior tells you nothing useful about the next session.
This matters because most enterprise security is built on profiling. Anomaly detection, UEBA, behavioral baselines — they all assume that what an identity *has done* predicts what it *will do*. An agent's next move depends on a context it hasn't encountered yet. You cannot baseline the future state of a goal-driven reasoning loop.
---
## The Guardrails Problem
For roughly two years, AI security investment focused on the model layer: prompt filtering, output constraints, jailbreak defenses. These aren't useless — for consumer-facing chatbots handling sensitive queries, they matter. But they're being applied to the wrong layer for enterprise agent risk.
Prompt filters try to constrain behavior by shaping input and output. The problem is that natural language is an infinite surface. A filter that works ninety-nine percent of the time still fails — and one percent of an infinite prompt space is still infinite. More importantly, these controls operate *after* access has already been granted. Once an agent holds credentials to a production database, a Salesforce instance, or an internal file share, the security boundary is already behind you. A guardrail can shape what the agent says. It cannot undo what the agent is allowed to do.
The access question is prior to the behavior question. Securing the behavior of an agent that holds admin credentials to production is like installing a lock on the inside of a vault that's already been opened.
---
## Nobody Knows What's Running
The permissions problem would be tractable if enterprises knew what agents they had deployed. They don't.
Palo Alto Networks puts the current ratio of non-human identities to human identities at roughly 109 to 1, with AI agents accelerating that curve. Anyone with API access to a major LLM provider can spin up an agent in minutes — and most do so without going through any security review. The result is shadow AI: dozens or hundreds of agents accumulating credentials and running in production environments that security teams have never inventoried.
You cannot apply least privilege to access you don't know exists. You cannot revoke credentials you haven't mapped. The inventory gap is the precondition for everything else going wrong.
The path of least resistance — grant broad access, move on — isn't just laziness. It's a rational response to the combinatorial difficulty of scoping permissions for every agent, for every session that agent runs, against the specific task in front of it right now. The workload of doing least privilege correctly for agents is orders of magnitude harder than doing it for human users and static service accounts. So teams don't do it.
---
## What Defenders Actually Need
The shift in framing is from *behavior control* to *access scoping*. That means:
Session-scoped permissions. An agent performing a specific task doesn't need persistent, broad credentials. It needs the minimum access to complete *this* request, revoked when the session ends. Most platforms don't provision this way by default; it has to be enforced.
Agent inventory first. Before policy comes visibility. You need to know every agent running in your environment, what identity it's operating under, and what that identity can reach. Without this, least privilege is theoretical.
Treat agent identities like privileged accounts. The same disciplines that apply to privileged human access — just-in-time provisioning, session recording, regular credential rotation — apply to agents, often more urgently, because agents can act faster and at greater volume than any person.
Separate approval paths for agentic tools. If your organization lets developers ship agent integrations without a security review, you have shadow AI. The review process has to exist before deployment, not as an audit after the fact.
The "access multiplied by autonomy" framing from Token Security's research is genuinely useful here. Access sets the ceiling for what goes wrong; autonomy determines how fast and how far the damage travels. Reducing one reduces risk even when you can't fully control the other.
---
## HackWire Analysis
What's missing from most coverage of this problem is how deep the timing mismatch runs. The enterprise AI deployment wave is already in the middle innings. Agentic systems are handling real workflows — customer support, code review, financial analysis, HR triage — right now, in organizations that are still running identity programs designed for human users on static service accounts. The security infrastructure is two generations behind the deployment curve.
The 109:1 non-human-to-human identity ratio is a data point worth sitting with. At that ratio, the human identity program your security team has spent years building — the policies, the tooling, the audit trails — covers less than one percent of your actual identity surface. Every agent that gets spun up outside a formal review widens that gap.
There's also a model liability question that hasn't been litigated yet: when an agent operating correctly, within its provisioned permissions, causes a data exposure or compliance violation, who owns that? The developer who scoped the permissions too broadly? The platform team that didn't audit shadow deployments? The security team that didn't build agent-aware controls? The legal answer will eventually get tested. The practical answer is that whoever built least privilege into the access model will have a much cleaner story to tell.
The deeper issue is that AI agents are the first category of automated identity that can genuinely surprise their operators. That's the definition of a security problem — unpredictable behavior with real access. Guardrails are a band-aid. Inventory and access scoping are the foundation.
— HackWire Editorial
---
## Related Coverage