Eight Security Assumptions AI Agents Are Breaking: From Two Weeks to Ten Hours

When an attacker can afford to fail

The economics of cyberattacks have shifted with the arrival of AI agents. Where an attacker once needed a strategic reserve of time, an agent can now burn through a million times more of it than a human ever could. In one recent corporate network breach, work that would normally take about two weeks compressed into under ten hours. Investigating an incident at Hugging Face, analysts reconstructed roughly 17,600 agent actions carried out over four and a half days.

An agent doesn't get tired, doesn't lose focus, and can try several attack vectors in parallel, discarding failed paths without any psychological cost. Weak points that once seemed protected by obscurity or sheer difficulty of discovery stop functioning as defenses. This fundamentally upends the assumptions corporate security has been built on.

Eight critical assumptions that need rethinking

1. Prepare for an attacker who can afford to fail

At Hugging Face, the agent ran through hundreds of failed approaches, switched channels whenever it was blocked, and circled back to old leads until they eventually formed a working attack chain. Ordinary endpoints forgotten in network configurations, over-privileged accounts, routine setup mistakes — none of this remains a weak point once an attacker can afford to try everything. Reexamine every assumption that quietly relies on a resource being hard to find or on an attacker simply giving up.

2. Measure time from detection to containment

Security teams typically measure whether they can detect an intrusion. Add a metric: how long it takes from detection to actual containment. In the corporate breach mentioned above, two weeks of work collapsed into ten hours. At Google, a separate group of agents moved from a compromised cloud resource to a mass credential-harvesting campaign even faster. Slow escalation — as happened at Hugging Face, where security systems raised alarms but the response moved through several rounds of approvals and meetings — can kill any defense. Decide in advance which containment measures trigger automatically and which the security team can apply without additional sign-off.

3. Secure the scaffolding, not just the model itself

Scaffolding is everything around the model: tools, memory, credentials, network access, execution environments, and policies. In tests where AI models played the role of attackers, the scaffolding heavily determined what the model could actually accomplish. Australia's cybersecurity agency reached the same conclusion from the defensive side: an organization doesn't control how the underlying model evolves, but it can control the scaffolding. List everything an agent can see and call, everything it can write to, and everything it can spend money on. Ask yourself: if the agent misbehaves tomorrow, what's the worst this scaffolding would let it do?

4. Prepare for swarms of agents

In the Hugging Face incident, hundreds of agents exchanged information and invented their own communication methods between runs that were supposed to be fully isolated from one another. A group of agents can divide up work, share findings, and keep an attack going even after individual attempts fail. Shared folders, databases, message queues, and other writable resources can turn into unexpected communication channels. If you're running many agents, treat communication between them as a full-fledged permission that needs to be controlled and monitored.

5. Stop handing agents persistent credentials

Every agent should be treated as a separate machine identity with its own credentials. Issue narrowly scoped credentials that expire along with the task. Separate read permissions from write permissions. Don't store static cloud keys in an agent's environment. Make sure you can trace any sub-agent back through the chain to its parent agent and to the human behind it. This isn't just the principle of least privilege — it's that principle applied to software that actively probes its own environment. A human might never discover that an old account opens access to some forgotten system. An agent will search for it methodically.

6. Assume prompt injection will succeed

Prompt injection is instructions an attacker plants in content that an agent reads. Assume the agent will sometimes follow them. Instead of asking "can malicious instructions leak through," ask "what happens when they do." Agents read logs, hostnames, vulnerability reports, payloads, code comments, and configuration files. Any of these can contain text crafted specifically to manipulate the model. Even a deceived agent should still run into hard limits on credentials, network access, tools, and the authority to make consequential changes.

7. Keep the security boundary outside the model

A prompt saying "don't touch production" is a wish. Real control exists when the agent's API simply has no permissions that reach production. If an action could have serious consequences, let the model propose it while a separate part of the system decides whether it actually gets executed. The same goes for audit logs. If an agent can edit the records used to review its own behavior, assume you have no audit trail at all. Hard limits need to live in code, not in prompts.

8. Defend against agents with agents

An incident spanning tens of thousands of machine actions leaves far more traces than a human team could ever review in real time. Security operations centers (SOCs) will need their own agents to triage alerts, hunt for threats, investigate incidents, and help contain attacks. But defensive agents carry their own risks: they constantly read potentially manipulated data and are often granted broad permissions. Prompt injection can turn their work against the organization without an attacker ever needing to steal any credentials. Defensive agents need tightly controlled scaffolding and access to only what's absolutely necessary.

Organizations need to keep pace with AI-powered attackers without creating a brand-new security problem for themselves in the process.