Governance & offboarding

Who owns what, how access is reviewed, and what happens when someone leaves.

Owners

Owner	Responsible for
Account owner (the Owner role)	The account, and who is invited as an owner or admin
Admins	Namespaces, sources, invitations, who reaches each namespace, and revoking keys
Namespace owner (a person you name)	What's indexed in one namespace, and who should reach it
Source owner (a person you name)	One source: its schedule, its errors and what it should include
Rollout owner and champions	Adoption, and the quality of the ledger

Workstate has no setting for a namespace owner or a source owner. They're roles you assign and write down, for example on your team page.

Review access

Review access every month during a rollout, then every quarter.

1. Seats, roles and namespaces. On the Team page, check that each person still needs a seat, and that only the few who need it hold the Admin role. In the Namespaces column, check that each person reaches only what they need, and take away anything they don't. Follow up with anyone whose Last used time shows no activity for a month.
2. Namespaces. On the Namespaces page, check that each namespace is still needed.
3. Sources. The Sources page shows only the namespace selected in the switcher, so select each namespace in turn. For each source, check that everyone who can reach its namespace may see everything it indexes. Check that the Atlassian account behind each Confluence and Jira source sees only what it should. Check the repository selection on the GitHub App's settings on GitHub.

Have an owner who holds every namespace run the review. The Namespaces column shows only the namespaces the viewer holds, and only an owner can change an owner's access.

SSO Coming soon, audit export Coming soon and per-document permissions Coming soon aren't available yet. Plan your own controls around that.

Keep keys safe

• Use one key for each machine or agent, labelled with where it's used. You can then revoke one without stopping the rest.
• Keep keys out of files you commit. A .mcp.json should refer to ${RAG_API_KEY}, not contain the key itself.
• Revoke keys you no longer use on the API keys page. A revoked key stops working at its next request.
• Review your keys every quarter. Keys don't expire, and each person can hold up to 25 live keys.
• If a key leaks, revoke it at once, then create a new one. Your other keys keep working.

Offboard someone who leaves

1. Revoke their keys. An owner or admin opens Team and selects the revoke button on the person's row. Its tooltip reads Revoke this person's keys. Every key they hold stops working at once, and colleagues aren't affected. An admin can't revoke an owner's keys, and the button is unavailable when the person holds no live key.

2. Take away their namespaces. In the same row, open the picker in the Namespaces column, and select each ticked namespace to take it away. This applies from their next request, so a key they create later reaches none of those namespaces. The picker lists only the namespaces you hold, and only an owner can change an owner's access. An owner who holds every namespace is best placed to do this step.

3. Hand over their open work. Have their successor ask an agent to find the topics they opened that are still open or proposed. Then the successor appends a handoff note to each topic and updates its current state. The prompt is illustrative:

   Search the ledger in projects [projects] for open incidents, defects and investigations, and proposed decisions, about [themes]. Call ledger_get on each, and list the ones opened by [email address], with their current state.

4. Replace credentials they supplied. If a Confluence or Jira source reads as their Atlassian account, an admin uses Replace token on the source's page with another account's email and token.

5. Check their row again a week later. See the warning below.

Offboarding doesn't remove the seat

Removing a seat Coming soon isn't available yet, and revoking keys doesn't sign the person out of the console. If they still control the GitHub account they signed in with, they can sign in again and create a new key. Once you've taken away their namespaces, that key reaches none of them.

An owner or admin who leaves keeps their role, because a role can't be changed. They're given every namespace created later. If they sign in again, they can still invite people, create namespaces and revoke the keys of anyone at or below their role.

A week after someone leaves, check their row on the Team page. A key prefix in the Key column means they hold a live key: revoke their keys again. Take away any namespace that appears in their Namespaces column. If an owner or admin left, repeat this check whenever a namespace is created.

What happens to their ledger entries

They stay, attributed to the person. The topics they opened and every entry they wrote keep their name, and nobody can rewrite them. That's what makes the ledger a record you can rely on.

If a topic must be hidden, an agent can archive it with ledger_archive. Archiving hides the topic from search, but it stays reachable by its id, and it can be restored.

Deleting an account Coming soon isn't available yet.

Remove content

To remove	Do this	What happens
A whole source	Delete it on the source's page (owners and admins)	Everything indexed from it, its files and its history are purged
One uploaded file	Delete it from the upload source (owners and admins)	A sync starts, and removes the file from search
One repository	Stop sharing it with the Workstate GitHub App, on GitHub	It's removed from the index at the next sync
A ledger topic	Archive it with ledger_archive	It's hidden from search, and can be restored
A whole namespace	Delete it on Namespaces (owners and admins)	Its sources, index and ledger are deleted. This can't be undone.

A review calendar

How often	Who	What
Weekly	Champions	The quality of the ledger in their team's projects
Monthly	Admins	Seats, roles, who reaches each namespace, failing sources, and the keys and namespaces of people who left
Quarterly	Account owner	Namespaces, what each source indexes, keys and admins

Next steps

• Team & invites
• API keys
• Security & privacy