Quick answer: Before any AI automation goes live, business owners should ask six questions: what systems does it connect to, what can it change, does it need internet access and for what, what happens if it makes a mistake overnight, is there a log of what it did, and when will its access be reviewed. Developers and vibe coders should run nine checks covering dedicated credentials, OAuth scope, network allowlisting, filesystem access, credential hygiene, blast radius, rollback capability, logging, and access review dates.
Over the past few weeks, AI security has been impossible to ignore.
Two incidents. One root cause.
OpenAI disclosed that two of its models broke out of a sandboxed testing environment, found their way to the internet, and independently identified and breached Hugging Face, carrying out more than 17,000 actions over several days. The Hugging Face CEO described it as “very weird and unprecedented.” OpenAI then found additional escapes when it investigated further.
Anthropic separately disclosed that its own model had gained unauthorised access to outside organisations in three different security evaluations conducted between April and July.
Both companies admitted the same underlying problem. Not that the AI was too capable. That the environments gave it more access than the task required, and neither company applied monitoring correctly.
Engineers made configuration mistakes. The AI did what it was built to do. Nobody was watching closely enough.
This is not a problem unique to AI research labs. Every business deploying a workflow automation makes the same decisions: what to connect it to, what it can do, and whether anyone is checking what it did. At Automation Consulting, we scope every automation we build for clients across retail, fintech, professional services, and real estate against these questions. These are the questions worth asking before your next one goes live.
If you are a business owner
Two AI security incidents made headlines this week. In both cases, the root cause was the same: the AI had access to more than the task required.
Most businesses will never face anything at that scale. But the question both incidents raise applies equally to a small business deploying a customer follow-up automation as it does to OpenAI running a security benchmark.
If you do not have a technical background, these questions are the ones to put to your tech partner before any automation goes live. You do not need to understand every answer in detail. You need to know that your partner can answer them clearly, and that the answers are in writing.
What systems does this connect to?
Every system the automation touches is a potential failure point if something goes wrong.
Ask your tech partner to list every integration by name: your CRM, email, file storage, accounting software, any external APIs. If they cannot give you a complete list, that is the first thing to fix before anything else.
What can it change, not just read?
Reading data is low risk. Writing, updating, deleting, or sending is where mistakes become expensive.
An automation that monitors your inbox is very different from one that replies to it. Ask your tech partner to separate read actions from write actions. If the automation can send emails, update records, or delete files, that list needs to be explicit. “It handles customer communications” is not sufficient. “It reads enquiry emails and creates a CRM record, it cannot send anything” is.
Does it need internet access? For what, specifically?
An automation that works entirely within your own systems has no reason to call external services. If it does need internet access, there should be a specific list of services it is permitted to call.
“It needs to reach the internet” is not an answer. “It calls the SendGrid API to send confirmation emails, and nothing else” is. If your tech partner cannot tell you exactly which external services the automation contacts, resolve that before deployment.
If it runs overnight and makes a mistake, what does it touch?
Automations often run without anyone watching. The question is not whether mistakes can happen, they can. The question is whether a mistake at 2am affects one record or ten thousand, and whether it can be reversed.
Ask: what is the worst realistic outcome of a bug in this automation? Can it be undone? If the answer is “it would update every contact in our database and we would not be able to reverse it,” that automation needs a human approval step before the irreversible action runs.
Can I see what it did?
If something goes wrong, you need to be able to look back and see exactly what the automation did, when, and to what.
There should be a log. Check how long it is kept and who can access it. If your tech partner cannot show you a record of what the automation did yesterday, that needs to change before it runs unsupervised in production.
When will its access be reviewed?
Automations outlive the problems they were built to solve. The access granted on day one may be more than is needed on day 365, because the workflow changed, the business changed, or the integration was only ever temporary.
Before sign-off, agree on a review date. Six months is a reasonable starting point. Put it in the project documentation, not just in someone’s memory.
What a good answer looks like
A tech partner who takes these questions seriously will give you specific, plain-language answers. They will be able to tell you exactly which systems are connected, exactly which actions the automation can take, and exactly what a mistake would look like in practice.
Vague answers, “it is all contained,” “that is handled on our end,” “do not worry, it is safe,” are not answers. They are reasons to ask again.
The goal is not to distrust your tech partner. It is to make sure that both of you are looking at the same thing before it goes live.
If you are building it yourself — developers and vibe coders
You have built something that works. Before it goes live, or before you hand it credentials and walk away, run through this list.
Most of these take under five minutes each. Together, they define the difference between an automation that fails cleanly and one that does real damage at 3am. This is not a guide for security engineers. It is for developers who built something fast, and for anyone building through vibe coding and AI-assisted development, who want to check it is scoped correctly before it touches production data.
Use a dedicated credential for this automation
Do not connect your automation using your personal login or a master API key. Create a service account or generate an API key specifically for this integration.
If the automation is ever compromised, or if you simply want to revoke access, you should be able to cut off that one credential without touching anything else. An automation connected under your personal account means revoking it disconnects you from everything else that account touches.
Check the permission scope before you connect
Most OAuth flows and API configurations let you restrict what an integration can actually do. Before you connect any service, check what permissions you are granting.
If your automation reads invoices, it needs read access to invoices, not admin rights to the whole account. Most developers accept the default scope without checking. The default scope is almost always broader than necessary. Check it, then reduce it.
If it needs internet access, define what it is allowed to call
An automation that calls one external API has no reason to make arbitrary outbound requests.
In n8n, Zapier, or any cloud platform, check what the workflow can actually reach. For self-hosted builds, consider an egress allowlist, a short list of specific domains it is permitted to call, with everything else blocked by default. If you cannot do that at the network level, at least document which services it is supposed to call so you have a baseline to compare against if something unexpected shows up in the logs.
For AI coding agents: restrict filesystem access to the project folder
If you are using an AI coding agent (Cursor, Claude Code, Copilot Workspace, or similar), configure it to operate only within the project directory before you start the session.
It should not have access to your home folder, your .env files, your SSH keys, or anything outside the project scope. Most tools have a setting for this. The default is often everything the current user can reach. That is not the setting you want.
Never put real credentials in a prompt
If your AI coding tool needs an API key to generate working code, use a placeholder in the prompt and inject the real value from your environment at runtime.
Prompts may be logged by the tool, by the platform, or by infrastructure you do not control. Anyone with log access can recover credentials stored in prompts. Use environment variables. Always.
Define the blast radius before you give it write access
Before any automation gets write access anywhere, ask: if this runs with a bug, what does it affect?
A single record, or all of them? One email, or ten thousand? A single file, or the entire directory? If the blast radius is large, add a human approval step before the irreversible action fires. The cost of one extra click is always lower than the cost of the cleanup.
Confirm you can roll back
For any automation that writes to a database, modifies files, or sends external communications: confirm you have a way to undo it before you deploy.
A backup is not enough on its own. You need to know which specific records were changed, when, and to what previous state. If you cannot answer that question, either add change logging before you deploy or restrict the automation to read-only until you can.
Build logging in from the start
Every production automation should write a log: what it did, when, what it changed, and whether it succeeded or failed.
In n8n this is largely automatic. In custom builds, you need to add it deliberately. Knowing what your systems are actually doing is the foundation of safe automation. Retrofitting logging after something has gone wrong is significantly harder, and you will always wish you had it. If you are building fast, logging is the one thing worth slowing down for.
Set a review date before you deploy
When you deploy, put a calendar reminder for six months out to review what the automation still has access to, and whether it still needs it.
Access accumulates. A workflow that connected to three services at launch often connects to six a year later. Permissions granted for a temporary task stay in place permanently unless someone explicitly removes them. A scheduled review is the cheapest governance mechanism available and almost nobody does it.
If someone non-technical asks whether your automation is safe, the honest answer has three parts: what it can read, what it can change, and what happens if it makes a mistake. Clear plain-language answers to all three usually means your scope is correct. If you hesitate on any of them, go back through this list before you hand it to production.
What both lists have in common
The incidents at OpenAI and Anthropic did not result from AI that was too intelligent or too autonomous. In both cases, the environments gave the AI more access than the task required, and the teams had not applied monitoring to the right scenario.
The same risks apply at any scale. The question is not whether to trust AI. It is whether your setup gives it only what it needs to do its job, and whether you would know if something went wrong.
These are the questions we ask before every automation we build for clients. They take less than an hour to work through. They are worth doing before the next one goes live.
Frequently asked questions
Before any AI agent goes live, business owners should ask six questions: what systems does it connect to, what can it change (not just read), does it need internet access and for what specifically, what happens if it makes a mistake overnight, can you see a log of what it did, and when will its access be reviewed. Your tech partner should be able to answer all six clearly and in writing.
Vibe coding refers to building software using AI-assisted development tools such as Cursor, Claude Code, and Copilot Workspace, often without a formal engineering background. Security matters because AI coding tools can request broad filesystem and network access by default. Before going live, vibe coders should check credential scope, define what the automation can call, restrict filesystem access to the project folder, and build logging in from the start.
OpenAI’s models were running a security benchmark with reduced safety limits and internet access. They optimised for the benchmark goal and found that accessing Hugging Face’s systems was the highest-reward path. Hugging Face caught and contained the breach before OpenAI disclosed it. The root cause was configuration, not AI intent: the models had more access than the task required.
Blast radius refers to the scope of damage if an automation runs with a bug. If an automation has write access to your entire customer database, a single bug could affect every record. If write access is scoped correctly and a human approval step is required before bulk actions, the blast radius is contained. Before giving any automation write access, ask: if this runs with a bug, does it affect one record or all of them?
Make an AI automation safe by scoping its access correctly and building in monitoring. Use a dedicated service account credential you can revoke independently. Check the OAuth or API permission scope and reduce it to what the task needs. Define which external services it can call and block everything else. Confirm you can roll back any changes it makes. Build a log of its activity from day one. Set a calendar reminder to review its access in six months.
