Why your AI agent needs guardrails before it needs tools
Opinion4 min read

Why your AI agent needs guardrails before it needs tools

There’s a gold rush happening right now in AI tooling. Every week, a new MCP server drops — connecting agents to Slack, GitHub, Stripe, Notion, you name it. The pitch is always the same: “Let your agent do more.” Nobody’s asking the obvious follow-up: “And what happens when it does something wrong?”

Timothé Husson

Timothé Husson

March 10, 2026

There’s a gold rush happening right now in AI tooling. Every week, a new MCP server drops — connecting agents to Slack, GitHub, Stripe, Notion, you name it. The pitch is always the same: “Let your agent do more.”

Nobody’s asking the obvious follow-up: “And what happens when it does something wrong?”

We’re building highways and handing out keys to cars with no seatbelts.

The problem isn’t access. It’s what comes after.

Connecting an agent to your Stripe account takes about 90 seconds. You paste a key, the MCP server exposes 30+ tools, and suddenly your agent can create charges, issue refunds, modify subscriptions, and delete products.

All of them. With no restrictions. At machine speed.

That’s not a feature. That’s a liability.

I’ve watched agents loop a Notion API call 400 times in under a minute. I’ve seen an agent with GitHub write access open 15 identical pull requests because it misread a CI failure. I’ve seen a support agent with Slack access send an internal pricing doc to a customer channel.

These aren’t hypotheticals. These are Tuesdays.

“But we have OAuth scopes”

Sure. OAuth scopes are great for telling an app what category of data it can touch. They’re terrible at telling an agent what it should actually do with that data.

“Write access to messages” doesn’t mean “post a summary in #engineering.” It means write access to messages. All of them. Every channel. Every DM. Every thread.

OAuth was designed for apps with deterministic behavior — click this button, call this endpoint. Agents don’t work that way. They reason, improvise, and occasionally hallucinate. Giving a non-deterministic system a deterministic permission model is like giving a toddler a credit card with a spending limit. The limit exists, but you’re still going to have a bad time.

Three things every agent setup is missing

After months of building in this space, I keep seeing the same three gaps. Almost nobody has them covered.

1. Policies that match how you actually think

When you onboard a new hire, you don’t hand them a list of API scopes. You say things like “don’t delete anything in production” or “always cc the team lead on client emails” or “never issue a refund above $200 without asking.”

These are policies. Human-readable, context-aware rules. Your agents need them too, and right now they have zero. The MCP protocol doesn’t support them. The servers don’t enforce them. Nobody even has a place to write them down.

2. A human in the loop — for the things that matter

Not every action needs approval. Reading a Notion page? Fine. Searching Linear tickets? Go ahead. But deleting a Stripe subscription? Sending an email to a list of 10,000 contacts? Pushing to main?

Some actions need a human to see them before they happen. Not after. Not in a log you’ll check next week. Before.

Out of 100+ MCP servers I’ve looked at, exactly one has any form of human-in-the-loop. One. The rest are fire-and-forget.

3. An audit trail that actually exists

When something goes wrong — and it will — the first question is always “what happened?” Most MCP setups can’t answer that. There’s no log of which agent called which tool, with what parameters, at what time, and what the outcome was.

You wouldn’t run a production service without logs. Why are we running production agents without them?

The seatbelt before the highway

The MCP ecosystem is moving fast, and that’s a good thing. Agents that can actually interact with your tools are genuinely useful. I use them every day.

But we’ve collectively decided to figure out the “connect everything” part before the “make sure nothing breaks” part. We’re building the highway before the seatbelts. And the speed is only going up.

That’s why we built Hodor. Not to slow agents down — to make them safe enough to actually trust. Policies that read like English. Approval flows for the actions that matter. A full audit trail of everything your agents do. A layer that sits between your agents and your tools, so you can give them access without giving them free rein.

Because the question was never whether agents should have access to your tools. It’s whether you should have control over what they do with it.