
Deploying autonomous AI agents safely: the honest answer for 2026
An AI agent moving through your systems unsupervised is never safer than the controls you've built around it. Deploying autonomous AI agents safely doesn't mean trusting the model. It means deciding in advance what an agent is allowed to request, what it's allowed to decide, and what happens the moment it approaches a boundary. Most companies haven't made those decisions yet. That's not a hunch. It shows up in research from Gartner and McKinsey, and in a handful of incidents that made international headlines over the past few months.
What does deploying autonomous AI agents safely actually mean?
An autonomous AI agent isn't a chatbot waiting for a question. It's software that decides its own next step, logs into whatever systems that requires, and keeps going until the task is done, without a person approving every move along the way.
Deploying autonomous AI agents safely comes down to three things that need to be handled separately. Access: can the agent technically reach a system? Permission: is the agent, on whoever's behalf it's acting, allowed to carry out this specific action? And control: is there a place that checks that before the fact, instead of finding out after something went wrong? Most companies only handle the first one. Granting access is the easy part. A password, an API key, an integration a vendor already built for you. Permission and control require something that usually doesn't exist yet: a layer that decides per request, not once at installation.
At a wholesale distributor with around sixty people on the payroll, that distinction would look like this: a procurement agent may draft a reorder recommendation on its own, based on stock and sales data, but it should never place an order above a certain amount without a buyer signing off. Whether it can see something, advise on it, or act on it are three different decisions, and in most implementations they're never written down separately. The distinction simply isn't there.
The hype around autonomous AI agents, in numbers
xAI launched Grok Bot this month: an always-on agent that logs into your existing business tools and works a task from start to finish. It only "surfaces again" once something needs approval Techopedia, August 2026. That's not an outlier. It's exactly the moment the whole market is in right now: look what I built, everything moves faster, I don't need to be involved myself anymore.
The numbers tell a different story than the launch videos. This year's Gartner Hype Cycle for Agentic AI shows that only 17% of organizations actually have agents in production. More than 60% expect to within two years. Gartner also predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, not for lack of ambition, but because of runaway costs and risk controls that were never in place before the project went live Gartner, Hype Cycle for Agentic AI 2026. A good chunk of what gets called an "agent" today is also just a chatbot or an RPA script with a new label. No independent decision-making, just a new name on something that already existed.
McKinsey finds something similar this year: nearly two-thirds of organizations haven't actually started scaling AI across the business, and only about 10% of business functions are currently using a real AI agent. The gap between the demo and daily practice is bigger than most LinkedIn feeds would suggest.
Research firm Gravitee found a gap in their State of AI Agent Security report this year that makes the problem sharper still. 82% of executives are confident their policy stops unauthorized agent actions. At the same time, more than half of agents run with no logging or oversight at all, and only 21% of executives have full visibility into which permissions and systems their agents actually use. 88% of organizations reported a confirmed or suspected AI agent security incident in the past year. Confidence and visibility, it turns out, are two very different things, and almost nobody has the second one.
What goes wrong when nobody oversees autonomous AI agents
In March, multiple security outlets reported an incident at Meta. An internal agent received a short-lived request to answer something internally, but turned that request into a permanent, public action with no stop condition. A colleague acted on the resulting wrong answer. For almost two hours, sensitive data sat exposed to people who had no business seeing it. Meta hasn't officially confirmed this itself, but the pattern analysts describe is exactly what happens when an agent has access, and nobody defined in advance what it's allowed to do with it.
In early August, it went further than an internal accident. Researchers reported what multiple sources describe as the first near-fully autonomous AI cyberattack on a government: a multi-agent system that independently mapped 21 Taiwanese government systems, breached 85 accounts, and stole more than 2,500 personnel records, before expanding on its own into the nuclear safety agency and seven energy companies. The system researched its own weaknesses and decided its own next move. A cyberattack is a different domain than a CRM connection, but the underlying mechanism is identical: a system that keeps going on its own because nothing stops it.
McKinsey sums up that shift well in its State of AI Trust research: organizations can no longer just watch whether an AI system says the wrong thing. They also have to watch whether the system does the wrong thing. A chatbot that gives a wrong answer, you correct. An agent that has already acted on a wrong decision, you correct after the fact, if you even notice it happened.
What NIS2 and the EU AI Act ask of autonomous AI agents
On August 2, 2026, the European Commission started actively enforcing the AI Act. Two obligations went live on the same day: chatbots must identify themselves as automated and AI-generated content must carry a recognizable mark (article 50), and the Commission gained oversight powers over providers of general purpose AI models. Fines run up to 35 million euros or 7% of global turnover for prohibited practices. The stricter rules for high-risk systems, which would cover many practical agent use cases, are delayed until December 2027 and August 2028. Enforcement has started, but the heaviest part is still ahead.
NIS2, meanwhile, is already more concrete for agents that make decisions inside a company. Compliance analysts point specifically to article 12 (logging) and article 14 (human oversight) as the provisions that apply most directly to AI agents. An agent that produces decision-making output based on processed data already counts under NIS2 as an information system, with the full set of risk-assessment and logging obligations that comes with it. There's even a term now for a specific compliance risk: the "orphaned AI agent," an agent whose accountable owner left the company long ago while its credentials are still active. This applies to companies with 50+ employees or €10 million+ in turnover, across eighteen sectors.
This topic deserves its own, more thorough piece. We'll come back to it in a later episode. For now, the core point is enough: legislation is no longer trailing the technology. It has already started counting agents as systems you need to be able to account for.
How to deploy autonomous AI agents safely
We're not against agents. Build as many as you want, in every department that benefits from them. The problem is never the number of agents. It's four steps that almost nobody takes in advance.
1. Separate "can it reach this" from "is it allowed to do this"
An agent can technically have access to twenty systems and still only be allowed to carry out a handful of actions. Treat that as two separate decisions, made by different people with different responsibilities.
2. Assign ownership before the agent goes live
Don't figure out after the fact who owned it when things went wrong. Decide in advance who's accountable for what the agent does, and what happens when that person leaves. Otherwise you end up with exactly the orphaned-agent risk described above.
3. Build in a stop condition
A five-minute request should never grow into a permanent action. Every task an agent runs needs a point where it stops on its own and a person has to confirm it's still on track, especially for actions that can't be undone.
4. Validate before the agent acts, not after
This is exactly where we've been for years, long before "agent" showed up on every slide. We already validate what moves between systems, whether that's a CRM connection today or an agent requesting customer data tomorrow. The difference from five years ago isn't the technology asking for access. It's how fast that access gets granted now, and how little time gets spent thinking about what "having access" and "being allowed to act" actually mean separately.
The question isn't whether your people are going to build agents. They already are, with or without IT's blessing. The question is whether, six months from now, someone can show exactly what that agent was and wasn't allowed to do, and whether that answer exists before something goes wrong, or only after.
Frequently asked questions
Just as much. The moment a tool carries out actions in your systems on its own, it counts, whether you built it yourself or simply switched it on inside an existing product. The question is never who built the agent. The question is who decided what it's allowed to do.
Yes, just a different one. An agent that only reads can't initiate a payment, but it can still expose sensitive data to whoever it's talking to. That's exactly what went wrong at Meta: no write action, still a data leak. Read access is lower risk than write access, never risk-free.
RBAC controls who's allowed to log into a system. It doesn't control what a specific request, at that moment, for that purpose, is allowed to produce. An agent with a valid role can still ask for something outside the purpose of that role. RBAC is the front door. This is about what happens once someone's already inside.
In practice it shifts between IT and security, without either fully owning it. That's exactly the orphaned-agent risk described in this article: without an assigned owner, nobody checks it, and nobody switches the agent off once the project ends.
No. Build as many as you want. The point isn't to switch them off. The point is putting a layer in between that checks what's allowed on every request, so you can keep building without flying blind.
If nobody at your company currently has a full overview of which agents are active, which systems they can reach, and who authorized that, you're already at risk. According to Gravitee, only 21% of executives actually have that overview. Everyone else is guessing.
Yes. This is exactly what we already do: validate what moves between systems, and decide who gets access to what. For AI agents, it's the same approach, applied to a new kind of requester. Not a future plan, we set this up as a project, tailored to your systems and your agents.

