How the Assistant Touches Your Site Safely
Tovu ships with an AI assistant that can genuinely change your site — write a page, publish a post, edit a theme file, change a setting. That should make you slightly nervous. Here is exactly what stops it from doing something you did not ask for.
The assistant has no database access
This is the load-bearing design decision. The assistant cannot open your SQLite file, cannot run shell commands against your site directory, and cannot call internal functions. Every single thing it can do to your site exists as a registered tool in a catalog — a named, documented, individually-reviewed operation with a declared input schema.
If an action is not in the catalog, the assistant cannot perform it. Not "is discouraged from" — cannot. There is no general-purpose escape hatch behind the specific tools.
Every call goes through one gate
Tool calls do not run directly. They are routed through a single executor that is deny-by-default: a tool runs only if it has been explicitly registered and permitted for this site. That gate is also where each call is classified by risk and where the audit record is written.
Because there is exactly one path, there is exactly one place to enforce policy — and no second path that quietly skips it.
Destructive actions stop and ask you
Some operations are marked human-gated. When the assistant calls one, the call does not proceed — it opens a confirmation dialog in your admin and waits for you to answer. Deleting a post works this way: the assistant asks, the deletion happens only if you click Delete, and if you cancel or simply walk away, nothing is deleted.
The assistant cannot approve its own dialog, and it cannot route around one by using a different tool.
Deletions are soft, and changes are reversible
Deleting a post or page marks it as trashed rather than destroying the row. It disappears from your lists and from the public site, but it is still there and can be brought back by reverting the change set that removed it.
Everything is logged
Each attempt — the tool name, the input, the result, whether it was denied, confirmed, cancelled or timed out — is recorded in your site's own database. That log lives in your folder, next to your content. It is yours to read, and it is a genuine record rather than a summary the assistant wrote about itself.
Why bother with the catalog at all
It would have been far less work to hand the assistant a terminal. The reason we did not is that "the AI has full access and we trust the prompt" is not a security model — it is a hope. A catalog gives you something you can actually inspect: a finite list of the things the assistant is able to do, each one written and reviewed deliberately.
It also makes the assistant better. A tool with a clear description and a strict schema is far easier for a model to use correctly than an open-ended shell, which is why the assistant tends to do the right thing on the first try rather than flailing.
This is MVP software and we will keep tightening it. But the shape is deliberate, and it is the part we are least willing to compromise on.