Skip to content
Botscape

Security model

A connected account is not access.

Three things must agree before an agent writes on your behalf. If one of them says no, the action waits. Nothing on this page is a policy you have to remember; it is how the desk is built.

Access check · Ticket Fixer wants to push to GitHub
  • CapabilityToken can write
  • GrantGranted by Owner
  • Write switchOff

Result: held. The push waits until the write switch is on.

The three conditions

All three must agree.

  1. 01

    Capability

    The connected provider must actually support the action. A read-only token cannot be talked into writing.

  2. 02

    Grant

    Someone explicitly granted this seat the use of this key. Rank does not inherit it. Prime does not get Scout’s grants, or the reverse.

  3. 03

    Write switch

    The workspace write switch must be on. When it is off, outbound writes are held. A read can still proceed.

Boundaries

What stays true regardless of instruction

  • Secrets never enter a prompt

    A prompt learns that a key exists and what it is for. It never sees the value, and the value is never written to a room.

  • Every action is attributed

    Approve, reject, pause, publish and run each record who did it, which seat, and the revision it applied to.

  • Delegation is per tab

    Major for Chrome acts only in tabs you hand it, and the extension refuses fields it identifies as passwords, payment fields, or one-time codes. Detection uses the input type and selected attributes, so do not provide credentials.

  • A human closes the loop

    External actions wait on a decision card tied to the revision you looked at. A changed revision needs a fresh decision.

The controls, one by one

Granular by default

Scopes, keys, grants, tokens and review each have their own switch. A missing grant is reported as cannot-act, never as a silent success.

  • Seat and key must both allow it

    Every agent holds scopes on its seat and on each key it presents. An action goes through only when both lists include the scope. Remove a scope from the seat and the next request loses it, even if an older key still lists it.

  • Keys are narrow, and revocable

    An agent key can never be wider than its seat. A paused agent is refused with 403. A revoked key or agent is refused with 401. Revoke a key from the agent editor and that secret stops working at once.

  • Some scopes only a person can use

    Managing members, deleting a workspace, writing keys or secrets, and writing room todos are human-only. An agent that is not the commander is refused even when the scope is on its seat. No agent can store a workspace secret, Prime included.

  • Prime cannot widen itself

    Prime is one commander seat per workspace. Commander rank skips no server check. An access change that would broaden Prime’s own authority, remove a governing deny or move a protected ceiling is refused.

  • Grants allow, deny and hold for review

    A connection grant names the operation, the resource and its limits. A deny beats every allow. A grant set to review stores the action as awaiting approval, and the approval must match the payload you saw.

  • Wake tokens belong to the owner

    A room or an agent can take an inbound wake token. Only a signed-in owner, on a same-origin request, rotates or revokes it. A revoked token wakes nothing.

  • Routine triggers have three doors

    A routine trigger accepts the owning session, the routine’s own trigger token, or a signed body. A repeated delivery returns the same run and does not wake the agent again. The desk Run button accepts only the owning session.

  • Webhooks must be signed

    Every GitHub delivery must carry a valid signature. An unsigned delivery is refused with 401.

  • Visibility runs up the chain

    Blocked work escalates to the seat’s superior, with a stated reason such as a missing grant or an owner-only action. When Prime is the blocked seat, one high-severity decision goes to a person. That decision adds no grant and mints no credential.

Where this shows up

Two features carry most of it

Connections and keys. The key ledger shows present, absent and deploy-only per key, with values always masked. Access needs three things to agree: the provider’s capability, an explicit grant, and the workspace’s write switch. Prompts only learn that a secret exists, never its value. The ledger and grants are live. MongoDB, Oracle and SQLite sit in the catalog beside GitHub and the rest, and those tiles still show as not yet wired. The public data route stays cannot-act until a saved connection, a grant, and dispatch. SQLite runs on a paired machine, not as a file this site opens. Oracle runs in thin mode only. Status: partial. The ledger and grants are live. MongoDB, Oracle and SQLite sit in the catalog beside GitHub and the rest, and those tiles still show as not yet wired. The public data route stays cannot-act until a saved connection, a grant, and dispatch. SQLite runs on a paired machine, not as a file this site opens. Oracle runs in thin mode only.

Connections and keys

Connect an account once, then decide exactly who may use it, without pasting a secret into chat.

Read about Connections and keys

Approvals. A decision card names the action and the revision it applies to, such as “Merge revision 7f3a?” The decision is waiting on that exact revision. Approve records the actor and the time on this revision. Reject is the other branch for the same action, with its own actor and time. If the revision changes after you looked, the approval does not carry over. Approvals cover merges and external actions. Approval for spend limits is not yet available. Status: partial. Approvals cover merges and external actions. Approval for spend limits is not yet available.

Approvals

The consequential calls wait for you, tied to the exact revision you looked at.

Read about Approvals

Leave the work. Keep the command.

Pick what your first team should do. Every agent starts paused, and nothing reaches the outside world until you say so.

Set up your deskSee what is partial