Abilities, not access: what an AI agent should be allowed to do to a website

The instinct, when you first give an agent a job, is to hand it the keys. SSH, FTP, database credentials, the same access a human developer would get. It feels generous and it feels simple.

It is a category error, and the reason has nothing to do with trusting the model.

The problem with raw access

A filesystem is an unbounded surface. An agent with write access to your theme directory can do the thing you asked and also, in the same breath, edit a file it misidentified, leave a half-written PHP block that white-screens the site, or make a change nobody can find later because it never went through a reviewable record.

None of that requires bad intent. It requires only an ordinary mistake in an environment where mistakes are unbounded.

A permission you can forget you granted is a permission you have granted forever.

What a bounded surface changes

Shilpi exposes 30 tools over MCP. Each one does a specific thing: create a page, upsert a class, read the site inventory, upload a font. The agent cannot do anything else, because there is nothing else to call.

Three properties follow from that, and all three matter more than the security framing suggests:

1. Every action is a record. A page saved through save_page has revisions. A class upserted through manage_classes is in a registry you can list. There is no change that happened somewhere you cannot look.
2. Validation runs before the write. A PHP snippet is syntax-checked and test-run before it can be enabled. A font file is checked against its real signature, not its extension. The tool refuses bad input rather than accepting it and failing later.
3. The work gets better. This is the counterintuitive one. An agent given site_info and a class registry reads them, and then extends the system it found. An agent given a filesystem tends to write new CSS from scratch, because nothing pointed it at what already existed.

The permission that is temporary on purpose

PHP is the exception that proves the model. Registering a post type or hooking a filter genuinely needs code, so Code Hub exists, but writing PHP is off by default and has to be switched on deliberately at Shilpi › Security.

The Security screen then shows a count of how many temporary permissions are open, with one button that closes all of them. That counter is the actual feature.

What this looks like in practice

You turn the MCP server on, sign the agent in over OAuth, and paste the house rules. It reads the site, builds what you asked for, and reports what it created and what it reused. You read the structure tree, check the tokens, and press Save.

Then you go to Security and close the door. The whole loop takes a minute, and the site is in a state you could hand to a client that afternoon.