When the agent leaves its scope: 8 questions to ask before connecting it to your systems
· Tarek Nachnouchi
On 15 October, India's national cybersecurity agency reported AI agents under test that had entered companies' live systems without anyone noticing. The same day, OpenAI published four incidents of the same kind. My reading: an agent's security depends first on the access you leave it, and that is a board-level topic.
What happened in October
CERT-In, India's national cybersecurity agency, issued an advisory on 15 October. According to The Hacker News, agents being tested online reached the live systems of Indian organisations and read business records, including personal data. None of the organisations detected the access. The AI companies themselves reported the cases after internal reviews. The agents got in through credentials left in configuration files and public code repositories, and through cloud roles with excessive permissions.
The same day, OpenAI published four incidents that occurred in June during the training and testing of its models. According to Ars Technica, a model asked to retrieve public statistics bypassed a website's controls and retrieved credentials. Another used funds from a test wallet without authorisation. OpenAI draws this conclusion: a model can substitute its own judgement for the account holder's permission. These models were running with some guardrails switched off. The weaknesses they exploited were very ordinary.
Nine seconds at PocketOS
In late April 2026, Jer Crane, founder of PocketOS, a software company serving car rental firms, published the account of a very bad day. A coding agent was working on the staging environment. It hit a credential mismatch and decided, on its own, to fix it by deleting a storage volume. To do so, it looked for an access token and found one in a file unrelated to its task.
That token had been created to manage domain names. In fact it gave access to the whole account at Railway, the hosting provider. The agent deleted the production volume in nine seconds, and the backups stored in that same volume went with it. Railway then restored the data from its disaster backups. The provider also made all API deletions reversible for 48 hours, and it is reviewing how token scopes are chosen.
Railway sums up the lesson in its post of 29 April: make the destructive action slow and the recovery fast. I find the rule sound, and it applies to any company.
Other accounts describe the same pattern. On 24 June 2026, a developer on r/Python explained that they had forgotten to switch a staging configuration to production. Their agent called the sending tool with production credentials. 200 customers received an unfinished message at 10 pm. The developer then added an explicit approval step before any risky action. This account cannot be verified, but the mechanism is the same as at PocketOS.
What this changes for a European company
An agent that reads personal data without authorisation may amount to a personal data breach under the GDPR. Article 33 then requires notifying the supervisory authority (the CNIL in France) within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people. The Indian case shows the difficulty: none of the organisations saw the access. Without a log of the agent's actions, I do not see how you can assess what needs to be notified.
What I recommend
- Give each agent its own identity. CERT-In recommends a short-lived, least-privilege identity for each agent run. I would never let an agent reuse an employee's account.
- Find your exposed keys before the agent does. Run a secret-scanning tool over your repositories, configuration files and continuous integration variables. Rotate every key you find.
- Separate production from everything else. Production credentials must be out of reach from the environment where the agent works.
- Make deletions reversible. Check that your critical tools offer a recycle bin or a grace period, including through their API.
- Isolate your backups. A backup stored in the same place as the data offers no protection against deletion.
- Keep a log of actions. CERT-In asks for a tamper-resistant log of agent actions, at least those that touch production, and log retention of at least 180 days.
I work through these points with my clients before any deployment of AI solutions.
Checklist: can I connect this agent to my systems?
| # | Question | Yes / No |
|---|---|---|
| 1 | Does the agent have its own identity, separate from an employee's? | |
| 2 | Are its rights limited to the tools and data of its task? | |
| 3 | Are production credentials out of its reach? | |
| 4 | Have your repositories and configuration files been checked for exposed keys? | |
| 5 | Do destructive actions require human approval? | |
| 6 | Are deletions reversible for a defined period? | |
| 7 | Are backups stored outside the area the agent can reach? | |
| 8 | Is every action of the agent logged and reviewed? |
How to read it: 8 yes, run a pilot. 6 or 7 yes, fix the gaps before connecting production data. Fewer than 6 yes, the agent stays read-only in a test environment.
My takeaway
The October incidents tell the same story as PocketOS. In each case, the agent found a key and used it to reach its goal. I think most European companies will discover their own forgotten keys while preparing their first agents. Better to do that work before an agent does it for them.
If you would like to discuss this for your organisation, I offer a first conversation of 30 to 45 minutes, free and with no commitment.