SyntrumDocs
Open app

The three planes

Governance in Syntrum looks like a lot of switches — roles, modes, guardrails, per-tool dials — but it's really one model with three planes. Every permission question you can ask is one of these three, and they all resolve through a single cascade.

The three questions#

Plane The question it answers What it governs
1. Human (RBAC) Who can do what in the dashboard? Members: Owner / Admin / Operator / Viewer
2. Agent autonomy How much may an agent do without a human? Supervision mode + the sensitive-action categories
3. Tool permissions Which tools does an agent hold, and what may it do with each? Tool attachment + the per-tool dial

Keep them straight and the whole product gets simple:

  • Plane 1 is about people. It's the role matrix on the Team page: Owners own the blast radius, Admins write the rules, Operators live inside the rules (clear approvals, chat, start/stop), and Viewers only look. Notably, editing policy is itself a permission — only Admins and Owners can change safety or supervision settings.
  • Plane 2 is about an agent's independence. It's the supervision mode — Inherit / Strict / Balanced / Autonomous — covered in Supervision & modes and Agent autonomy.
  • Plane 3 is about a specific tool on a specific agent. It's the four-position dial in Tool permissions.

The one cascade#

Planes 2 and 3 resolve together for every action an agent attempts, through one rule evaluated server-side at the moment of action:

Workspace floor → Agent mode → Tool pin

  • Inherit by default. Nothing is pinned unless you deliberately pin it. An unpinned agent follows the workspace; an unpinned tool follows the agent.
  • Strictest wins. Where levels disagree, the more cautious one applies. Precedence for non-block values is tool pin → agent mode → workspace default.
  • Block is a floor. A block at any level can be tightened by a lower level but never loosened. No mode and no tool pin can turn a workspace block into an allowed action.

The one-line version, printed right in the product: "Reads always flow; supervision gates writes." An agent can always observe. What the cascade decides is whether a write — a send, an update, a delete — runs on its own, waits for you, or is refused.

A worked example#

Say your workspace sets External messaging → Allow but Payments → Block, and you have a Sales agent with Gmail attached:

  • Sales agent on Inherit, Gmail on Autonomous → sending an email runs on its own (workspace allows it, nothing tightens).
  • Same agent, but you pin Gmail → Asks first → now every email waits for your approval, even though the workspace allows external messaging. The tool pin tightened.
  • The agent tries a payment action → blocked, no matter what its mode or tool pin says. The workspace block is a floor.

You can confirm any of these before trusting them with the Test an action simulator — see Supervision & modes.

Where the cascade is enforced and recorded#

  • Enforcement point — Approvals. When the cascade says "approval," the action becomes a card in your Approvals queue and the task parks until you decide. When it says "block," the action is refused.
  • System of record — Audit. Every decision is logged with its provenance — which rule, at which level, set by whom. See the Audit log.

Policy is enforced on the server, always. The dials and pickers in the UI are how you express intent — they are never the thing that actually gates an action. That's why a Viewer seeing a control doesn't mean a Viewer can bypass it.

Provenance — "why did my agent ask?"#

Because every decision carries its source, you can always answer why an agent stopped for you. An approval card and the simulator both tell you the level that decided — workspace, agent, or tool — so a held action reads like "Decided at the tool level" or "Held because Gmail on this agent is pinned to Require approval."

This turns governance from a black box into something you can reason about: if an agent is asking too often, you know exactly which plane to loosen; if it's acting too freely, you know exactly which plane to tighten. Provenance is explored further in Agent autonomy.

What's next#