the guardrails

I built an MCP server that lets an AI agent actually work inside an enterprise system. Reading, configuring, creating records, through the official API. The question I got most often afterwards wasn’t whether people could have my code. It was: how do you do that safely?

That’s the right question. Turning an AI loose on a client’s live system can go spectacularly wrong. But the answer sits somewhere other than where most organizations go looking.

hands for an advisor

MCP stands for Model Context Protocol, an open standard that gives an AI model tools. Normally a model like Claude is good at one thing: generating text. It can’t do anything inside your systems. An MCP changes that. It’s the bridge between the model and an application, and it hands the AI a set of tools: bounded actions it’s actually allowed to perform, like looking up a record or staging a change.

The comparison that works for me: without an MCP, the AI is an advisor sitting next to you, telling you what to do. With an MCP, that same advisor gets hands.

And the moment an AI can perform actions, the risk shifts. A wrong answer in a chat is annoying but harmless. A wrong action in a live system touches real data, real customers, real processes. The upside is enormous, because work that normally happens by hand, click by click, becomes reproducible and fast. But so does the mistake.

the default mistake

The market’s reflex is to look for safety in the model. Better prompts, stricter system instructions, a sentence telling the agent to be careful. Or the other extreme: the agent gets no access at all and stays locked in a sandbox forever, where it harms no one and helps no one either.

Both versions miss the point. An instruction to a model is an agreement, not a guarantee. And an agent without access is an expensive chatbot.

The inversion: safety doesn’t live in how clever the model is. It lives in the discipline you build into the tooling itself. Every tool you hand an agent is a place where you can enforce rules the model can’t reason its way around. Not because the agent behaves itself, but because the tool allows nothing else.

six guardrails

This is the pattern I use. Six vendor-neutral principles that together form a safety harness. They work for SAP, for any CRM, and for just about any system with an API.

One: preview-then-apply. The agent can never write directly. Every change happens in two steps. First it shows exactly what’s about to happen, a human approves it, and only then does the agent execute. This single principle catches most accidents, because there’s always a human moment between intent and execution.

Two: production is a separate threshold. Working in a test or acceptance environment is one thing. Writing to a live production environment should require an explicit, extra confirmation. Make it impossible to end up there by accident.

Three: least privilege. The agent gets access only to what the task needs, and no more. Exactly the way you set up authorization roles for people: you don’t hand everyone admin rights. An agent that creates categories has no business being able to delete contracts.

Four: a full audit trail. Every action gets logged. What, when, with what result. Without a log you can’t tell after the fact what happened, and you can’t trace a mistake or undo it.

Five: read-back verification. Don’t blindly trust “done”. After an action, have the agent read back what’s actually in the system, and have it flag when the system quietly changed or dropped something. What you think happened and what actually happened aren’t always the same.

Six: a kill switch. Build in a fail-safe that steps in when things go wrong, for example stopping after a run of failed attempts instead of blindly carrying on. An agent without a kill switch turns a small problem into a big one.

limits as the condition for freedom

The thread running through all six is the same: when in doubt, ask, and keep the human in the loop. Not because the AI is dumb, but because the cost of a mistake in a real system is too high to leave entirely to automation.

Let’s be honest: this discipline isn’t free. Preview-then-apply means a human has to look, and a human who clicks approve a hundred times a day stops really looking at some point. The guardrails don’t excuse you from thinking about which actions genuinely deserve that human moment and which you can cover with the other five principles.

But the core holds. This discipline isn’t a brake on the value, it’s what makes the value possible. Organizations that frame their agents properly dare to give them more freedom, because they know the damage stays contained when something goes wrong. The team that chains its agent up out of fear, and the team that lets it run out of naivety, both get nowhere. The team that draws the lines sharply can let everything run inside those lines.

Responsible AI isn’t a marketing term and it isn’t a policy document. It’s a set of concrete choices you build into your tooling, before you let an agent loose on a real system. Trust in an agent, then, isn’t a feeling you let wash over you. It’s an architecture decision you make.