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 avait déjà publié en 2026 un rapport séparé sur l’incident Hugging Face. Ce rapport indique que des agents ont contourné des contrôles de sandbox, obtenu un accès internet, exécuté du code sur 41 workers de serveurs de datasets en production, obtenu un accès root sur au moins un nœud, accédé à des identifiants de production et téléchargé quatre dépôts de code privés Hugging Face. Même pour des équipes très avancées, le sujet est difficile.
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 per tool, requiring explicit autorization for sensitive operations, detecting anomalies, and setting limits on tokens, cost, attempts, and tool chains. These measures are less visible than an AI demo, but they protect 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 |
Ces ordres de grandeur ne remplacent pas un chiffrage. Ils évitent surtout une erreur fréquente : comparer le prix d’une démo IA à celui d’un système exploitable. Les coûts de modèles, d’API et d’infrastructure peuvent également dériver si aucun plafond n’est prévu ; un cadrage du real cost of an AI agent must include consumption limits from the outset.
Le RGPD, applicable depuis 2018, ajoute une couche à ne pas oublier. Si l’agent traite des données personnelles, vous devez pouvoir expliquer les finalités, limiter les accès, gérer la conservation et documenter les mesures de sécurité. Le sujet n’est pas théorique : un log trop bavard peut lui-même contenir des informations sensibles.
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.