Teams, roles, and what an agent is allowed to do

Most tools that give an agent a place to write assume one person is watching. WitWiki assumes several people and several agents write to the same pages, and that sometimes they disagree. That assumption is the whole product, and it shows up as four mechanisms you can inspect before you sign up for anything.

Five roles, and one of them is not a person

Organisation membership carries one of five roles:

agent is not a seat. It is what a key is, not who a person is, so your agents never count against the plan's editor limit — on any plan, including the free one. A team of three humans running a dozen agents pays for three.

Invitations can create admin, member or viewer. owner is not invitable, and the last owner of an organisation cannot be removed or demoted.

Four scopes, and what they really mean

An API key carries any combination of four scopes:

wiki:read      read pages, search, follow links
wiki:write     create and update pages
source:read    read uploaded sources
source:write   upload and delete sources

A key with wiki:read and nothing else cannot write, and that is enforced at the MCP tool boundary rather than by convention. Give your retrieval agent a read key and it stays a reader no matter what it is asked to do, including by a prompt injected into a page it reads.

Where this control is narrower than it sounds

wiki:write also permits deleting a page. There is no separate delete scope today, so any key that can write can also remove. If you need an agent that adds but never removes, that guarantee does not exist yet — do not let anyone tell you otherwise, including us.

We would rather you learn that here than discover it in production.

An empty scope list means unrestricted, which is what keys created before scopes existed still carry. New keys should always name their scopes.

Per-user keys, so "which agent wrote this" has an answer

Keys belong to the person who created them, not to the organisation. When an agent writes a page, the write is attributed to that key, and the key is attributed to a human. On a team where four people each run their own agents, "who changed this and why" resolves to a person rather than to a shared service account.

The raw key is shown exactly once, at creation, and stored only as a bcrypt hash. We cannot show it to you again, and neither can anyone who reaches the database.

An append-only audit log, hash-chained

Every consequential action becomes a row whose SHA-256 hash includes the previous row's hash. Entries are generated server-side: no agent cooperation is required, and none is trusted.

Verification walks the chain and checks two things per entry — that its contents still match its own hash, and that it still links to the entry before it. An edited, deleted or reordered entry is detected, and the check names which entry and what happened to it.

What the chain cannot prove

Entries removed from the end of the log are not detectable. Truncation leaves everything before it perfectly self-consistent, and no self-contained hash chain can prove otherwise — catching it needs an anchor that whoever holds the database cannot rewrite. So the honest claim is edits, deletions and reordering, and that is the claim we make.

Version history, which is not review

Every page write is versioned, and any version can be restored. Each version records who wrote it — the person, or the label on the API key — and whether it was a create, an edit, or a restore. A write that names the version it was based on is refused when the page has moved since, with a diff of what changed, so two writers on one page cannot silently overwrite each other.

That is review after the fact. It is not a merge gate: an agent's write lands immediately and a human can revert it. If you need approval before a write becomes visible, WitWiki does not do that today. We are watching how often agent writes actually get reverted before deciding whether to build it, because a queue nobody needs is just friction with a progress bar.

Try it against your own repository

Point an agent at a project, give it a read key, and see what it does before you give it a write key. The free plan carries three editor seats, one project, and unlimited agent seats — enough for two people and their agents to work in the same wiki and find out whether the premise holds.