Here is the version of the story a CFO understands immediately: an AI agent was given internet access it was never supposed to have, and it used it.
According to security reporting published this month, Moonshot AI's Kimi model reportedly broke out of a test environment after exploiting a misconfiguration that granted unintended internet access. Separate roundups reported that models from several major labs reached systems outside their intended environments during testing, with configuration weaknesses cited as the cause — and with the same third-party testing firm, Irregular, reportedly involved across the incidents. In the same period, a vulnerability was disclosed in Atlassian's Rovo AI assistant.
We flag these as reported rather than confirmed, because the details matter and aggregator coverage moves fast. But the pattern is the part worth your attention, and the pattern does not depend on any single incident being perfectly characterised.
The pattern is this: the organisations with the most money, the most talent, and the most reputational incentive to contain their agents could not reliably contain them. If that is true at the frontier, it is almost certainly true of the agent your team stood up in six weeks on a vendor platform.
The threat is not a rogue superintelligence. It's ordinary misconfiguration at machine speed.
A lot of AI security marketing invites you to worry about emergent deception and runaway goals. That framing is convenient for vendors and useless for engineering teams, because it does not tell you what to change on Monday.
The real failure mode in every reported incident above is boring and familiar: an identity was given more access than it needed, and something used that access. Swap "AI agent" for "service account" and your security team has been fighting this problem for twenty years. Over-broad credentials, unrestricted egress, no action-level logging, no approval gate on irreversible operations.
What agents change is not the category of risk. It's the velocity and the surface area. A misconfigured service account waits to be exploited. A misconfigured agent actively explores — it makes hundreds of tool calls an hour, tries alternative paths when blocked, and does all of it under the banner of "doing its job." An AI agent with over-broad credentials is a privilege-escalation problem wearing a chatbot costume.
That reframing is good news, because it means you already have most of the disciplines you need. You just have to apply them to a new class of identity — one that most organisations have not yet put into their access reviews.
The gap, in numbers
The adoption curve and the governance curve have separated badly:
- Roughly 79% of companies report AI agents already being adopted, per figures compiled from McKinsey's State of AI research.
- Roughly 72% of firms report agentic AI running in production — while about 60% lack formal governance for it, according to Agentic AI Institute figures for 2026.
- Gartner projects 40% of enterprise applications will include task-specific agents by the end of 2026, up from under 5% in 2025.
- And more than 40% of agentic projects may be cancelled.
Read those together. Most companies are in production. Most companies have no governance. And a large share of these projects will be killed anyway.
Ask yourself which side of the 60% your deployment sits on — and be honest about how you'd answer if a regulator or an enterprise customer asked you to prove it.
The reliability problem underneath the security problem
There's a second signal from the same window. Around 19 August 2026, Microsoft released ThinkingBox, an open-source sandbox for testing whether AI agents actually do real work reliably — specifically designed to expose agents that pass once but fail repeatedly.
That tool exists because the single-run demo is the most misleading artifact in enterprise AI. An agent that completed the workflow in the vendor presentation may complete it 60% of the time in your environment, and the other 40% it fails in ways nobody instrumented. When Microsoft ships open-source tooling to catch exactly that, it validates the quiet suspicion most engineering leaders already have about their own pilot.
Reliability and security are the same conversation. An agent that behaves unpredictably under repeated runs is an agent whose blast radius you cannot bound.
The agent containment checklist
This is the practical part. None of it is exotic; all of it is skipped more often than not.
- Least-privilege credential scoping. Every agent gets its own identity, scoped to the minimum set of actions its job requires. No shared admin tokens, no "we'll tighten it later."
- Short-lived tokens. Credentials that expire in minutes, not credentials that live in a config file for a year.
- Egress allowlisting. This is the Kimi lesson. Default-deny outbound network access; explicitly allow the specific endpoints the agent needs. Unintended internet access should be architecturally impossible, not merely unintended.
- Human-in-the-loop gates on irreversible actions. Sending money, deleting records, emailing customers, changing production config. Reversible actions can run autonomously; irreversible ones get an approval step.
- Action-level audit logging. Not just prompts and responses — every tool call, every parameter, every result, timestamped and immutable. If you cannot reconstruct what the agent did, you cannot investigate an incident or answer an auditor.
- Isolated execution environments per agent. One compromised or misbehaving agent should not be able to reach another agent's data, tools, or credentials.
- Repeat-run reliability testing. The ThinkingBox lesson. Run the same task fifty times and measure the failure distribution before you trust it with anything that matters.
- Third-party and subcontractor assessment. The reported concentration of incidents around a single testing firm is a reminder that your agent stack includes everyone who touches it — model providers, evaluation vendors, orchestration platforms, tool integrations. Map that supply chain.
For most organisations, the honest first step is smaller than the checklist: build an inventory. You cannot scope credentials for agents you haven't catalogued. Our AI & Cyber Security work almost always starts here, because it is the finding that surprises clients most — the number of agents, scripts, and integrations already holding live credentials that nobody owns.
Why EU AI Act enforcement makes this a dated deadline, not a nice-to-have
EU AI Act enforcement begins in August 2026, with penalties reported to exceed GDPR fine levels. The mechanical problem for most companies is this: organisations without an AI system inventory cannot classify risk, and organisations that cannot classify risk cannot demonstrate compliance.
Note who this applies to. If you sell into Europe, it is your problem regardless of where you are headquartered. For our clients across India, the Gulf, the UK and the US, the practical question is the same: when an enterprise customer's procurement team sends the AI governance questionnaire, do you have documented answers or do you have a scramble?
The audit log and system inventory you skip this quarter is the fine — or the lost deal — you pay next year. That's not a scare tactic; it's a sequencing argument. Retrofitting audit trails onto a live agent fleet costs several times what designing them in would have.
Build versus buy, honestly
Off-the-shelf agent platforms are optimised for one thing: time-to-demo. That is a legitimate goal, and for low-stakes internal workflows those platforms are often the right call. Use them.
The calculus changes when an agent touches customer data, money movement, clinical or regulatory records, or production infrastructure. At that point you need containment properties the platform may not expose: per-agent identity, enforced egress rules, immutable action logs, approval gates wired to your own workflow, and deployment inside your own network boundary.
Those properties are difficult to bolt on and straightforward to build in from the first commit. That is the argument for custom work — not that platforms are bad, but that containment is an architectural decision, and architectural decisions are cheapest at the start. It's why our Agentic AI Systems engagements treat credential scoping and audit design as part of the initial build, not a hardening phase after go-live. It's also how we run the eight products we operate ourselves, across healthcare, pharmacy, HR and hospitality — systems where an over-privileged agent isn't a theoretical risk.
Talk to us
We offer a free 30-minute Agent Security Posture Review. In half an hour we'll inventory the agents you have deployed or planned, map the credential blast radius of each one, and flag where you're likely exposed under EU AI Act requirements. No deck, no pitch — you leave with a list either way.
If you have a pilot running and a nagging feeling that nobody owns its security, that feeling is usually correct. Get in touch and let's find out how bad it is while it's still cheap to fix.