The administrator security baseline

Eight settings, reviewed before the first member signs in, and where each one lives today. They explain F-SET-2 (organisation settings), F-ADM-1 (the admin dashboard), F-COMP-7 (the egress proxy), F-PLUG-5 (team plugin policy), F-SK-3 (organisation rules), F-NOT-3 (push notifications), F-BOT-10 (model routing) and F-BOT-8 (templates), and the review instructions F-APR-5's automatic reviewer reads.

Before the first member signs in

Organisation rules: the block list and the allow list

Two different lists answer two different questions, and only one of them has a screen today.

The recommended block sentences — no production deployments from this organisation, no external e-mail without review, no payments, never accept legal terms on the organisation's behalf — and the recommended allow sentences for routine, safe work go on Organisation → Rules (row 4 above) as ordinary organisation rules: they steer the run itself.

The automatic reviewer that decides an approval card reads a separate list, org_policies.review_instructions — team-wide instructions F-APR-5 calls for — but no screen or command sets it today. This page names that as a gap rather than pointing an administrator at a setting that does not exist (this spec's decision F-11); the reviewer's other source is each member's own automatic-review rules (row 5).

Members' own automatic-review rules

Every member carries their own automatic-review toggle, default on, on Settings → General. Turning it off disables only the rule-released automatic-allow path — everything that needed approval still asks. There is no organisation-wide lock on that toggle (D166, later).

Notifications

The two-gate rule F-NOT-3 describes waits for the mobile app (M7); nothing on main implements it yet, so this page names the switch that exists instead. A bot's own Notifications row — Get notified when this Bot finishes or needs input — is the first gate. A push reaching a member's phone needs that switch and the device's own notification permission; the phone half of the rule arrives with the mobile app (F-NOT-3, D166).

Delegation and the product switch

Work with people outside this organisation is off by default: while it is off, a bot never hands a task to somebody who is not a member, by mail or by a shared link.

Botseon for this organisation stops every run start for every member — chats, routines and channels alike — and deletes nothing; an administrator turns it back on when the reason for stopping has passed.

Both are recorded to the audit log (org.delegation_toggled, org.product_toggled).

What the audit log records

Organisation → Audit reads Who changed what in this organisation, newest first., with a Tamper check line (Verified unbroken … or A break was found …) and an Export control offering From, To, Request export, Download and Chain unbroken.

The action vocabulary an export carries:

Sign-up abuse controls

A new account on the hosted edition needs an address that can receive mail, and the same person cannot quietly hold two accounts on one mailbox.

Three guards run on Create an account, in this order, and the order is the point — each refusal costs less than the one after it:

1. The domain. A disposable or temporary-mail domain, or a domain that accepts no mail at all, is refused with Use an address you can receive mail on. — one sentence for both causes, which names neither the block list nor which of the two fired.
2. How many accounts one network has just made. More than five in a rolling hour is refused with the same sentence a rate-limited sign-in gets, so neither page ever confirms whether an address already has an account.
3. The per-address sign-in limit, unchanged, which the sign-in page has always used.

Addresses are compared by their canonical form, not the literal string typed: a +suffix is ignored, and for Gmail so are dots in the name. Someone who signs up as ida+work@example.com when ida@example.com already exists is signed into that existing account rather than given a second one. Nothing is merged, because there was only ever one account.

What is recorded, and what is not

Each refusal — and each alias sign-in, and each trial rejected for a duplicate card — appends one row to abuse_signals. A row holds a keyed hash and never an address, never a network address, and never anything about a payment card. The hash columns accept nothing but a 64-character digest, so a caller that passed a raw address would be refused by the database rather than stored. Rows older than 90 days are removed as new ones are written; nothing schedules a sweep. The table is not readable by the application role, and no bot, tool or plugin can reach it.

An organisation is named on a signal only where one exists — a refusal at sign-up happens before anyone is signed in — and where one is named, the organisation's own audit log carries a matching abuse.signal row.

The operator verbs

These are for whoever runs the deployment, not for an administrator of a single organisation, and they are cross-tenant:

botseon ops abuse domains add <domain>      # refuse new accounts on this domain
botseon ops abuse domains allow <domain>    # lift a refusal, including one the built-in list makes
botseon ops abuse domains list              # the current overlay, and the signal counts behind it

add and allow are both idempotent — running either twice, or allowing a domain that was never blocked, is not an error — and a domain moves between the two lists rather than joining both. They write an overlay beside the built-in list, which is read fresh on every sign-up, so a change takes effect without a redeploy. The built-in list itself is never edited by these commands.

list prints domains and counts per kind and no hash and no address: it reads aggregates only, so even this privileged report cannot become a way to ask whether one particular person tried to sign up.