The UN doesn’t usually complain about web traffic. But a few months back, the small team running UNCTAD’s statistics site (the UN’s trade and development data hub) did exactly that: OpenAI’s crawler had hit their pages more than 16,000 times over three months, and getting it to stop politely turned out to be surprisingly hard. They wrote about it half amused, half exhausted, and the internet mostly filed the story under “OpenAI being sloppy.”
I filed it differently. By 2027, thousands of small and mid-sized businesses will run autonomous agents on n8n, Zapier, and Make, and most of them will have pretty much the same containment the UN had: good intentions and a hope. AI agent security is going to stop being optional for SMBs, and I’d rather we all build the boring safety stuff while it’s still a choice, not a mandate.
Some of this will feel familiar if you’ve read our guide to workflow reliability. Think of this as the sharper, security-shaped end of the same problem.
What the UNCTAD scans actually tell us about intent vs. behavior
The detail that matters: nobody at OpenAI decided to hammer a UN website. GPTBot is a crawler doing crawler things, probably with a crawl budget set by someone who never thought about a small statistics site in Geneva. The intent was benign. The behavior, from the outside, looked like a brute-force attack.
That gap is the entire AI agent security problem in miniature. When you deploy an agent, you deploy behavior. Your intent doesn’t ship with the workflow. The agent inherits your goals and none of your judgment, and it pursues those goals with a persistence no human would consider reasonable.
Pedants will point out that GPTBot is a scraper, not an agent, so the comparison is unfair. I think it holds anyway, because the failure pattern (autonomous, persistent, indifferent to context) is exactly what agent failures look like. And I can say that with some authority, because last October I was the OpenAI in my own much dumber story.
The setup was simple. An n8n workflow took 200 inbound leads, enriched each one through a paid API, summarized the results with OpenAI, and dropped everything into the client’s CRM. I had left the HTTP node’s retry setting on with max tries at 25, because at the time I genuinely believed more retries meant more robustness. Around 2 a.m. the enrichment API started rate-limiting us, every remaining lead got hammered 25 times, my error workflow (built to be helpful) re-ran the whole batch, and by the time the 3:14 a.m. Slack alert woke me up we’d fired 4,300 requests and burned about $180 in API spend. On 200 leads.
The intent was “enrich leads.” The behavior was “brute-force an API for six hours.” Nobody was malicious. Nobody on the receiving end cared either.
And I’d love to tell you I built guardrails that same night. I didn’t. The workflow sat in production for two more weeks, because a client project was due and, honestly, nothing else had broken. That’s exactly how these things survive until they really break.
If you’re new to agents, spend time on how multi-agent systems behave in production before you hand them tools. Behavior is what you ship.
Rate limits can’t catch tools that spawn sub-tasks
The reflex answer to a story like UNCTAD is rate limiting. Cap requests per hour, done. That works when you have one actor with one budget. Agents break the assumption, because modern agents can spawn work: one run triggers three sub-tasks, a sub-task retries, a retry queues a cleanup job, and your tidy per-account rate limit sits there looking innocent while the queue behind it keeps growing.
January gave me a cleaner example, on Zapier this time. A client’s agent watched a Google Sheet for new leads, researched each one, and wrote its findings back to a spreadsheet. Which spreadsheet? The same one. New row appears, research happens, output row appears, which is a new row, which gets researched. 1,900 rows in about 35 minutes. They blew through their Zapier plan’s monthly task cap before 7 a.m. on the fourth of the month.
Every execution in that chain was small and reasonable on its own. The aggregate was insane. Rate limits judge each action individually; agents fail collectively.
Containment has to sit above the level where the fan-out happens. Which brings me to the three layers I now build into everything.
Three containment layers you can build this week
Ordered by how much grief they save you.
Budget ceilings: give every run a wallet
Hard caps, per run, on whatever costs money or stability: dollars, tokens, API calls, rows touched, minutes elapsed. Per run, not per month. My rule of thumb is five times the cost of a normal run, so an enrichment pass that should cost $0.40 gets a $2 ceiling. When the run hits the ceiling, the workflow stops and tells a human instead of “trying again.”
Don’t try to do this in the prompt. I’ve written before about why prompt engineering can’t fix structural problems, and “please don’t spend too much” in a system prompt is a wish, not a ceiling. The cap has to be a counter the workflow can’t argue with.
Tool allowlists: default deny
An agent should only see the tools you’ve explicitly wired into it. Default-allow is how you end up with a research agent that can POST anywhere on the internet because someone attached a generic HTTP tool “just in case.” I did exactly that. Last year I gave an internal research agent a generic HTTP tool for one edge case, forgot about it, and found it three weeks later calling endpoints I’d never imagined. Nothing bad happened. It easily could have. The allowlist is the agent’s whole world, so size it like one.
Human-in-the-loop gates: the expensive-door rule
Autonomous for anything reversible and cheap. Human approval for anything irreversible or expensive. Drafting a reply, fine. Sending 400 emails, deleting records, moving money, publishing to the website, those go through a gate. The gate can be dumb: a Slack message with two buttons, or a workflow that pauses until someone replies. The point isn’t sophistication, it’s that five seconds of one human sits between the agent’s decision and the world.
How this maps to n8n (and where Zapier leaves you)
n8n makes all three layers pretty buildable, which is one reason I keep recommending it for agent work. The timeout setting sits quietly in the workflow settings and nobody touches it, which kind of amazes me; every agent workflow I build now gets 30 minutes, hard stop. Node-level retries have a max-tries field, and after October mine sit at 3, never 25. Error triggers catch failed runs so a dead workflow pings you instead of silently looping. If you’re on the AI Gateway, its credit system doubles as a spend cap; if not, a Redis or Postgres counter at the top of the workflow does the same job. The agent node enforces the allowlist for free, since an agent can only call tools you’ve physically connected to it, so the discipline is just resisting the generic HTTP tool. And the sub-workflow orchestration nodes, the ones that let an agent spawn and wait for child workflows, are exactly where fan-out lives, so each child run should carry its own timeout and budget.
I might be behind on exact node names, n8n renames things constantly. The concepts are stable.
Zapier is a different animal. Your plan’s task cap acts as a crude global budget ceiling, and there’s real value in that; a friend of mine called it “a kill switch made of money” after the January incident. Filters and Paths give you basic gating. But per-run ceilings and tool allowlists inside Zapier’s agent features are, as of this writing, thinner. For genuinely autonomous agents I want infrastructure where I can set hard caps myself.
An actual kill switch
All three layers lower the odds of a bad run. The kill switch ends one in progress. Mine is a bit embarrassing in its simplicity: an admin workflow that calls the n8n API and deactivates a list of workflow IDs, triggered by a Slack slash command. One command from my phone and every agent workflow is down in about ten seconds. Every client build gets the same thing now, and I treat it like any other reliability practice: documented, tested once a month. An untested kill switch is just a rumor of a kill switch.
What the EU rules mean if you’re not technical
Now the part that turns prudence into urgency. I’m not a lawyer, and the rulebook keeps moving, the dedicated AI Liability Directive actually got shelved in early 2025, which tells you how unsettled this space still is. But two things are solid enough to plan around. The revised EU Product Liability Directive explicitly treats software and AI as products, and it phases in around the end of 2026, meaning damage caused by a workflow you built can land on whoever put it in the market. And the AI Act’s obligations roll in through 2026 and 2027, including transparency duties, telling people when they’re dealing with AI, from August 2026. That timing is why I keep calling the UNCTAD story a preview of 2027.
If you own the business but don’t build the workflows, none of this requires you to read regulation. It requires asking whoever builds your agents three questions. Can we cap spend per run? Can the agent use tools we haven’t explicitly listed? Where’s the off switch, and who besides you can pull it? Vague answers are your signal. “My freelancer set it up” will not be a defense, and honestly, it shouldn’t be.
And there’s something I find genuinely encouraging here: the containment layers double as your paper trail. Allowlists show you limited what the agent could touch. Logs show you watched what it did. Approval gates show a human in the loop for consequential decisions. Due care, it turns out, is buildable. If you’re building toward an agentic workforce, these gates are basically its HR policy.
I could be wrong about how fast any of this lands on small agent deployments. Maybe SMBs stay under the radar for years and this post reads as paranoia in retrospect. But the math is lopsided: the UNCTAD story costs you nothing to learn from, and the fix is a weekend of work, not a quarter.
Go check what your agents can actually touch. Add one timeout tonight. My October self insists the 3 a.m. Slack alert is not worth the optimism.
Talk soon,
Damian
