I gave an agent the keys to my blog. These are the rules.

This article was not pasted into an admin panel. It was uploaded and published by an AI agent (Claude), from a conversation, through a door I built for it myself: a content API and an MCP server made for this site. Writing the plumbing took a morning; working out which rules to give it took longer than writing the code. The rules are the part worth talking about.

The timing is not incidental either. On 28 July the final version of the new MCP specification ships, the protocol that makes this possible, and the release candidate already shows where things are heading: less laboratory experiment, more serious infrastructure.

What MCP is, in plain terms

MCP (Model Context Protocol) is an open standard that defines how an AI model connects to external systems: databases, applications, files, or, in this case, the content manager behind a blog. Before standardised sockets existed, every appliance needed its own custom wiring into the wall. MCP is the standardised socket: the owner of a system builds one plug (an "MCP server") and any compatible AI client can connect, whether that is Claude, ChatGPT or a code editor.

The history is short and says a lot. Anthropic published the standard in November 2024. In December 2025 it donated it to the Agentic AI Foundation, under the Linux Foundation, with OpenAI and Block as co-founders and AWS, Google, Microsoft, Cloudflare, GitHub and Bloomberg as supporting members. A 20-month-old protocol rarely gets that list of rivals around one table. And the specification shipping on 28 July addresses distinctly grown-up problems: stateless servers that scale behind an ordinary load balancer, authorisation aligned with OAuth 2.0, and a formal deprecation policy with 12 months' notice. That is the vocabulary of something that expects to stay.

Why this matters to anyone running a small site

An agent is only useful when it touches real systems, and the usual ways of letting it do that are bad. Automating the browser on top of an admin panel breaks at the first layout change. Direct database access hands over the whole house to something that only needed the letterbox. The alternative MCP makes viable is narrower: expose a small set of verbs, with types and rules, and nothing else.

In this site's case, the agent sees 12 tools: create an article, edit, publish, unpublish, translate, upload an image, list, and little more. It does not see users, it does not see configuration, it does not see the other pages of the site. The contact surface is the one I designed, not the one it discovers.

What MCP is not

MCP is not intelligence: it is plumbing. A badly steered agent with good tools still gets things wrong, just with more reach. And MCP is not security in itself. OWASP documents "tool poisoning", malicious instructions hidden in tool descriptions that the agent executes without the user ever seeing them, and prompt injection remains at the top of the risk lists for applications built on language models. Giving an agent write access amplifies the consequences of every one of those failures.

The practical conclusion is not "never connect an agent to anything". It is this: do not entrust security to the prompt. Asking a model "please do not delete anything" is not a security policy; it is a wish.

How I did it, in practice

The rule that organised everything: every protection lives on the server, where the agent cannot reach it. The agent can be talked into things; the API cannot.

This site runs on Wagtail (a content manager built on Django). The way in is an API of roughly 700 lines with the rules baked into the code, and the MCP server is 225 lines that merely translate. The rules that matter:

• Everything is born a draft. Creating or editing never touches the public site. Publishing is a separate, deliberate call, which is what allowed this text to be reviewed before it became visible.
• Deleting only works on drafts that were never published. Content that has been public requires unpublishing first and a human confirmation in the admin panel.
• One token, with limited powers. The key lives in a server environment variable; without it, the API does not even exist (it responds as if the routes were not there). Rotating the key is a one-line change.
• Its own signature. The agent's operations are attributed to a dedicated user, "claude-api". In the revision history I can tell, article by article, what I did and what it did.
• Physical limits. Images validated by the real content of the file, 15 MB maximum, 120 requests per minute.

None of this is exotic. It is the same principle you apply to an intern on their first day: their own credentials, drafts by default, and destructive actions stay with the boss. The novelty is that this intern writes at 200 words per second.

What I would do now (and what I would not)

If you run a small operation, the sensible path starts with reading: an MCP server that lets an agent look things up (orders, stock, content) already saves hours and risks little. The second step is reversible writes, like this blog's drafts. What I would still not give an agent: deleting, paying, or any action that cannot be undone with one click, a theme I have covered before in the piece on agentic commerce, where the industry is learning the same lesson in reverse order.

MCP is a bet, not magic: the bet that the connection between models and systems becomes boring, standardised, auditable infrastructure. Judging by the code it took to write this morning, and by the fact that this text got here on its own, it is a bet already worth putting small chips on.

mcp #agents #ai