Skip to content
Orgabot

Orgabot is in private alpha. Request access, or join our Discord.

← All documentation
The organization

Governance and approvals

Approval queues and role inboxes, the autonomy envelope a CISO agent may triage inside, the tamper-evident ledger, and the security properties that hold it all together.

Autonomy never outruns governance. A sensitive action does not fail and does not silently proceed: it becomes a pending request routed to the inbox of the role that must sign off.

The approval queue

orgabot approvals | approve <id> | deny <id>                        # mission-level
orgabot organization approvals <org> [--status pending|executed|denied|all]
orgabot organization approve <org> <requestId> [--as-role <eligible-role>]
orgabot organization deny <org> <requestId> [--reason "text"]
orgabot role inbox <org> <role>

Approval records live in the local operational store (~/.orgabot/operational.db). A request carries what is being asked for, who asked, which role must decide, and what is still outstanding.

Where an approval is stored

The operational store answers every approval read and takes every approval write; there is no JSON copy and no fallback. If the store cannot answer, the read fails rather than quietly reading a file next to it, because two stores answering the same question is the exact condition ADR 0063 exists to prevent. A malformed approval id is refused before any lookup, in every code path.

Separation of duties is enforced in code, not by convention. The requester cannot be the approver, and a producer cannot waive its own verification gate.

For a genuinely solo organization, orgabot organization solo-approval <org> on allows self-approval. It is audited and it is an explicitly degraded control, not the default.

The autonomy envelope

A CISO agent may auto-decide grants inside a bounded envelope. The default escalates everything.

orgabot organization approval-autonomy <org> [--auto-approve <scopes>|none] [--auto-deny <scopes>|none]
                                          [--repos a,b|any] [--on|--off]
orgabot role duty add <org> ciso "approval-triage" --interval 6h

Triage is a duty, so it only runs when something invokes orgabot duty run-due. Its recommendation is visible on the request; the envelope decides whether that recommendation can act on its own.

What always requires authority

  • Editing a branch: auto-approved.
  • Opening a PR, merging, deploying, spending, granting access: policy or explicit approval.
  • Changing what a role may reach: an approval, and a sensitive one gets independent least-privilege review.

Authority policies themselves are inspectable and editable under review:

orgabot organization policy list <org>
orgabot organization policy set <org> <policyId> [--allow-add a,b] [--budget N|none] [--approval-risk tier]

The audit trail

Every mission writes an append-only audit log of what it did and the authority it acted under. Organization grants and structural changes additionally land in a hash-chained, tamper-evident ledger:

orgabot organization ledger verify [org]
orgabot organization ledger anchor [org]
orgabot organization ledger anchor-verify <digest> [org]
orgabot organization ledger repair-fork <org> --reason "why this is a proven concurrency fork" [--yes]

Anchoring prints a digest you can record somewhere out of reach (a git commit, a timestamping service), so later tampering is detectable rather than merely unlikely.

If verification finds a historical two-head fork from simultaneous writers, repair-fork previews the evidence by default. After review, --yes first persists the operator's immutable approval, then preserves both branches and appends one entry joining their heads. It cannot be used to bless altered or replayed entries, unknown parents, or an unrecognized graph as valid.

Security properties worth stating plainly

  • No authority from natural language. Workers act only through brokered, policy-checked tools. Mission-brief context is labeled by trust level; repository text and issue text are data, never instructions.
  • Credentials never reach the model. Secrets live in the OS keychain, are injected at execution, and are redacted from logs.
  • Root-boundary defense. The project registry refuses symlink and .. escapes out of a project root.
  • Fail-closed everywhere it matters. A missing grant holds the work; it does not silently downgrade to your personal identity.
  • A fallback never expands authority. Every fallback path is a strictly smaller or equal grant than the one it replaces.

Two review mistakes that keep recurring

Both showed up repeatedly in Orgabot's own security reviews, and both are worth checking for before writing a gate:

  1. Absence of evidence read as evidence. An unreadable source is not proof that the thing is gone. A cached negative is not an observation.
  2. The checked party controlling the check. If a record's own claim decides whether it is valid, the check is decoration.

Configuration snapshots

orgabot organization config snapshot <org> [--label "text"]
orgabot organization config list <org>
orgabot organization config diff <org> <a> [<b>|live]

A point-in-time capture of org structure, so "what changed since it worked" is answerable.

← Connectors and toolsContext and memory →