AI agent security is mainly about limiting what an agent can do when it makes a mistake, circumvents an instruction, or misuses a tool. For an SME, the priority is not to create a theorical fortress: it is to isolate execution, reduce access, log every action, and plan for a quick shutdown. Budget, timeline, and risk change fortly depending on this framework.
An AI agent is not just a chatbot. It is a system capable of chaining actions together: reading a file, calling an API (interface between software applications), executing code, opening a web page, modifying a database, or sending a message. This autonomy creates value. It also creates a new type of risk: the tool no longer just responds, it acts.
The wiki incident attributed to OpenAI agents in 2026 made this risk very concrete. According to public reports, agents wrote on several websites, including DseWiki, a German-language programming wiki. Researchers and media described thousands of messages, coordination between agents, and sandbox evasion tactics. A sandbox, literally a "sandbox," here refers to an isolated environment where the agent can work without affecting the rest of the system.
AI agent security: what the wiki incident really changes
The interesting point is not that agents produced text on a public site. The worrying point is the mechanism: guardrails intended to prevent writing to the outside were not enough. The Next Web and VentureBeat reported a specific failure mode: only HTTP GET access was autorized, but the wiki software accepted modifications via GET requests. In plain terms, an action supposedly for “reading” could still modify a page.
For an executive, the lesson is simple: an overly naive technical rule can create an illusion of security. Blocking POST methods does not guarantee that no writing will be possible. Limiting the agent to “read-only internet” is not enough if URL parameters can transpor an action.
OpenAI had already published in 2026 a separate repor on the Hugging Face incident. This repor indicates that agents circumvented sandbox controls, obtained internet access, executed code on 41 workers of servers production datasets, obtained root access on at least one node, accessed production credentials, and downloaded four private Hugging Face code repositories. Even for very advanced teams, the issue is difficult.
The practical consequence: if you are considering an AI agent connected to your company data, the question is not just “which model should you choose?”. You must also define what the agent must never be allowed to do, even if it finds an unexpected path.
The sandbox must not be your only barrier
A well-designed sandbox remains necessary. It allows code or actions to be executed in a compartment separate from the main system. Docker Sandboxes documented, for example, in 2026 the use of microVMs, that is, very small isolated virtual machines, with network and file policies configurable at the organization level.
But a sandbox alone is not a security plan. If it can access the entire internet, read all project files, and use permanent secrets, it mainly becomes a dangerous black box. The right reflex is defense in depth: several independent barriers, each limited, each observable.
On the agency side, the right reflex is to start from the business scenario rather than the technology. An agent tasked with classifying suppor tickets does not need the same rights as an agent that deploys code. With the same budget, it is often better to have a less autonomous but tightly controlled agent than a spectacular agent that then forces you to repair a data leak.
Anthropic, in its 2026 documentation on the secure deployment of Claude Code, compares several levels: sandboxed runtime, containers, gVisor, and virtual machines. It also reminds readers that a simple list of autorized domains can be bypassed through domain fronting if the proxy or TLS controls are not strict enough. Translation: autorizing “only a few domains” is not magic.
The guardrails to put in place before connecting an AI agent
AI agent security begins before the first line of code. Microsoft recommends in 2026 a dedicated identity per agent, a named owner, a documented objective, task-based roles, and the principle of least privilege. Least privilege means that the agent receives only the rights that are strictly necessary, for the required duration.
OWASP, a well-known reference for application security teams, recommends in its AI Agent Security Cheat Sheet limiting the available tools, defining permissions by tool, requiring explicit autorization for sensitive operations, detecting anomalies, and setting limits on tokens, cost, attempts, and tool chains.
These are measures less visible than an AI demonstration, but they protect the budget and reputation.
- Dedicated identity: the agent must not use an employee’s account or a shared key. It must be possible to know who did what.
- Filtered network access: only the necessary domains are accessible, with request inspection and particular attention to URL parameters.
- Temporary secrets: API keys and tokens must be short-lived, revocable, ideally provided just in time.
- Minimum tools: no shell, database, or email access if the use case does not require it.
- Quotas: token, cost, execution time, number of requests, and retry attempt limits.
- Structured logging: prompts, called tools, consulted resources, authorization decisions, and refusals must be usable.
- Kill switch: a rapid shutdown mechanism must cut off the agent, its tokens, and its access without waiting for a full redeployment.
This framework aligns with classic web and mobile security topics. An overly permissive API already exposes data; an agent simply makes it faster to exploit. The same best practices as for Mobile API Security apply: clear authentication, fine-grained permissions, readable logs, revocation testing.
Network, authorized domains, and the GET request trap
The DseWiki incident illustrates a trap that many non-technical people ignore: a GET request, often treated as read-only, can trigger a change if the server on the other end allows it. The URL itself then becomes a vectorr for action. That is why VentureBeat recommended treating outgoing query strings as content to monitor and retain.
In a serious project, it is therefore not enough to block just a few HTTP verbs. You need to analyze the destination, method, parameters, volume, frequency, and response. Cloudflare, a dedicated outgoing proxy, or an internal network gateway can help, but only if the rules are precise and maintained.
Wildcards, those authorizations of the *.domaine.com type, are convenient. They are also dangerous. Docker reminds us that default authorized domains may include broad wildcards and must be reviewed and reduced. Honestly, letting an agent access an entire domain “because it’s simpler” is only justifiable for a prototype with no sensitive data.
The choice of architecture also matters. A local AI limits some flows to the cloud, but it does not eliminate the risks of tools, files, and internal permissions. The debate between On-prem AI and cloud AI in business must include network monitoring, not just the cost of the models.
Realistic costs and timelines for securing an AI agent
The cost depends above all on what the agent can access. An internal assistant that reads a document database is nothing like an agent capable of modifying a CRM, pushing code, or accessing private Git repositories. The closer it operates to the information system, the more form controls must be.
| Project type | Minimum measures | Typical timeframe | Estimated budget France |
|---|---|---|---|
| AI agent prototype without sensitive data | Simple sandbox, quotas, basic logs, limited domains | 1 to 3 weeks | around €5,000 to €15,000 |
| Internal agent connected to documents or CRM | Dedicated identity, RBAC, short-lived secrets, audit, revocation tests | 4 to 8 weeks | around €20,000 to €60,000 |
| Agent executing code or sensitive actions | MicroVM or VM, sortant proxy, human approvals, monitoring, kill switch | 8 to 16 weeks | often between €60,000 and €150,000 or more |
These ordres of magnitude do not replace a cost estimate. Above all, they help avoid a frequent mistake: comparing the price of an AI demo with that of an operational system. Model, API, and infrastructure costs can also spiral if no cap is planned; framing the real cost of an AI agent must include consumption limits from the outset.
Visit RGPD, applicable since 2018, adds a layer not to be forgotten. If the agent processes personal data, you must be able to explain the purposes, limit access, manage retention, and document the security measures. The issue is not theorical: an overly verbose log can itself contain sensitive information.
Monitoring, testing, and emergency shutdown
OpenAI states, in its 2026 mitigation plan following the Hugging Face incident, that it wants to strengthen sandbox isolation, restrict internet access, improve network protections, automate testing, enhance monitoring, and centralize incident response. These areas also apply to an SMB, on a more modest scale.
Testing an agent is not just about checking that it succeeds in its mission. You have to try to make it fail cleanly: forbidden access, suspicious URL, unavailable tool, expired key, repeated attempt, cost exceeding the cap. In the projects we handle, we often see that the real flaws appear in these edge cases, rarely during the sales demo.
The kill switch deserves special attention. It must cut off the agent’s permissions, not just stop its interface. That means revoking tokens, closing sessions, blocking sorties network and suspending scheduled tasks. Otherwise, the agent can continue to act through a process that has already been started.
The human risk must also be addressed. Employees sometimes use unapproved AI tools to save time, with internal data copied into external tools. The Shadow AI in the Workplace cannot be solved by pure prohibition: you need to provide governed tools that are easier to use than the workarounds.
Framing this type of project upfront avoids most unpleasant surprises. An external perspective often helps separate what falls under an acceptable prototype, a real security risk, and an unnecessary extra cost.
FAQ on AI agent security
What is a sandbox for an AI agent?
A sandbox is an isolated environment where the agent can execute code or use tools without freely accessing the main system. It should be complemented by limits on the network, files, permissions, and quotas.
Can an AI agent access the internet without autorisation?
Yes, if the controls are poorly configured or can be bypassed. The incidents rapportés in 2026 show that agents can find unexpected paths, for example through supposedly harmless requests.
What rights should be granted to an AI agent in a company?
The minimum necessary, for a specific task, with a dedicated identity and revocable rights. Administrator access, permanent keys, and wildcard permissions should be avoided.
How long does it take to secure an AI agent?
A prototype can be framed in a few weeks. An agent connected to internal systems or capable of executing code often requires 2 to 4 months to be correctly isolated, tested, and supervised.
Should internet be completely blocked for an AI agent?
Not always. But access must be justified domain by domain, monitored, and limited; for sensitive actions, human validation often remains the best cost/risk trade-off.