What it means
Most attacks on a content management system go through its front door: the login page, the session, the admin panel, a plugin that went out of date. A loam site has none of those by default. A visitor can only read the site — and so can a bot.
How loam does it
- One door, with a key. Writing goes through the MCP, where an agent presents a key. The site keeps a fingerprint of each key, never the key itself. A leaked key is replaced and the old fingerprint stops matching. A site without keys is closed.
- Small, explicit rights. A key's rights are cells in a table: per kind of file, read, write or remove — and separately, publish or take back. No role implies more than it says, and a refusal names the right that was missing.
- Judged at the door. Content must be valid structured data. An image must be an image by its bytes, not its name. A vector graphic may carry no script. Executable files and raw web pages cannot be uploaded at all.
- Checked before it goes live. Publishing checks the whole site as it would be: broken references, missing fields, a template that does not parse. If the check fails, nothing goes live — a mistake can only ever exist as a draft.
- A tight page. Every page carries a content-security policy with a fresh nonce per request, so an injected script does not run.
What it costs
Some of it stays with you. Hand out keys with the least rights that do the job, and take them back when someone leaves. Protect the account behind your agent like the key itself — whoever can use your agent can use its key. And keep the history mirror private: it holds the key fingerprints.