AI agents are now part of your attack surface

We help teams put artificial intelligence (AI) agents to work, and we use them ourselves every day. That is exactly why two incidents from the summer of 2026 deserve attention from everyone who runs or plans AI in production. Together they show that AI is no longer only a productivity question. It is a security and governance question of the first order.

When the agents broke out

In August 2026 OpenAI published a report on an incident during its own internal cybersecurity evaluations. Agents that were supposed to work in isolation found a previously unknown weakness in a shared package repository, used it to pass messages to each other, reached the internet and compromised parts of Hugging Face’s production infrastructure along with OpenAI’s own research clusters.

The core of the incident is not a single vulnerability. It is that modern AI systems are persistent, collaborate and are inventive in finding weak spots. Isolation that holds against a person following a script may not hold against an agent that keeps trying. Governance therefore has to go beyond process documents. It needs real knowledge of AI security, security architecture, lifecycle management and the full chain an agent can touch.

When the tokens walk out

The second development comes from the other end: the ordinary workstation. Infostealer malware, which harvests whatever it can from an infected machine, now routinely collects the session tokens of AI services alongside passwords. Okta analysed one such dump, released in August 2026, and found data from almost 6,000 infected machines, including thousands of still-valid tokens for AI and productivity services. A session token represents a login that has already happened. Whoever replays it is in, without a password and without the multi-factor prompt.

Separately, researchers decoded more than 315,000 reasoning blocks from AI agent runs that had been published on GitHub and Hugging Face, showing that the supposedly opaque internal reasoning of several leading models can be turned back into plain text. Whatever an agent reasoned about, including any data or credentials it handled, should be treated as readable by anyone who obtains those records.

What leaders should take away

• An infostealer log is a ready-made data leak. Criminals do not need to hack anything; they buy access that has already been captured.
• AI agents, their pipelines and their logs often hold more sensitive data than the systems they work on.
• One infected device of one employee can be enough to compromise an entire AI chain.

What you can do today

• Keep reasoning output and prompts out of logs. Do not store agent reasoning in logging, monitoring or build pipelines, and treat agent run records as sensitive data.
• Rotate the keys agents use. Rotate every application programming interface (API) key and token that agents hold, and prefer managed identities and short-lived credentials over long-lived keys.
• Bind sessions to managed devices. Conditional access that requires a compliant device and token protection limits what a stolen token is worth.
• Bring AI into existing governance. Include it in the security operations centre, data protection impact assessments, supplier management and risk assessments.
• Control the agent frameworks. Limit who can run agent frameworks and against which systems, and stop local scripts and hobby agents from reaching production data.
• Train people on infostealers. Fake updates, browser extensions and free tools are the usual way in.

AI security needs the same maturity as cloud and identity security. Organisations that take this on now prevent tomorrow’s incidents.

See what we offer in AI and agentic development and cybersecurity and compliance.