Offensive agents: test containment before connecting AI to business systems
An agent’s security also depends on how quickly its access can be withdrawn. Google’s recent observations provide a starting point for the AI workflow containment tests proposed here by Underside.
1. Observed intrusions, with limits to the findings
On October 30, Google Threat Intelligence Group and Mandiant reported intrusions using frameworks including ARTEX. The report describes abuse of compromised credentials and automation across several stages. It characterises current uses as still early and often noisy. These observations do not establish that all attacks have become autonomous.
2. What changes for a Belgian or French company
Our recommendation to IT leaders: complement permission reviews with a timed access-withdrawal exercise. An SME can select one agent and name the person authorised to stop it. Mid-market and large organisations should coordinate operations, identity, security and the business owner. A public administration can add a service-continuity check. The proposed goal is to measure the time between an alert, a containment decision and the effective refusal of a new action.
3. Underside analysis: separate the model from its authority to act
We propose treating each connector as a security boundary. A local model or a European cloud does not remove the need to control the tools an agent can access. For RAG, distinguish corpus access, document retrieval and response exposure. For an Odoo Enterprise agent, separate reading, proposing and writing: approval should cover the exact action, its scope and its recipient. These scenarios are our recommendations; the report does not identify an Odoo compromise or a particular integration.
4. A reproducible containment exercise
In an authorised test environment using fictional data, trigger a harmless action through a dedicated identity. Then revoke access, stop the workflow and try to resume the task from an already populated queue. Check open sessions, still-valid tokens and scheduled operations separately. Record which actions are actually refused and which remain possible. Stopping the interface alone should not count as evidence of revocation. The business owner defines acceptable effects and blocking criteria before the exercise.
5. Preserve evidence and organise recovery
We recommend a common identifier connecting the user request, agent decision, tool call, authorisation and business outcome. Minimise sensitive data in logs and document who can view them. Assign responsibility for preserving evidence before restarting the service. Recovery should use a renewed identity and a verified configuration, then replay pending actions under human supervision to prevent duplicates, for example on a quotation or invoice.
6. A production-readiness criterion
For a private, cloud or hybrid deployment, request a containment demonstration that also covers external dependencies and service accounts. Set a risk-appropriate target time rather than adopting a universal figure. If a prohibited write remains possible after revocation, fix the access chain before the pilot. These tests complement security analysis; they do not certify sovereignty or compliance.
Operational priority: choose one workflow, name its owner and prove that revocation also blocks queued tasks, with usable evidence.
Define controls for an AI project