Governance

Every tool call Fibonacci makes, and every tool call an external agent asks about, is decided against your organization’s rules before it runs. A call is allowed, denied, or held for a human to approve, and the decision is recorded. What makes the rules useful is that they know where data came from, not just which tool is being called.

An example

One rule: “Anything that sends data out needs approval if it touches both web content and internal data.”

Step	The workflow calls	Fibonacci sees	Decision
1	`google_docs_read` (the roadmap)	output labelled `internal`	allow
2	`web_search` (a partner FAQ)	output labelled `untrusted`	allow
3	`slack_send_message` with `{{roadmap}}` and `{{faq}}`	inputs carry `internal` + `untrusted`	held for approval

If the FAQ page carried a prompt injection telling the model to post the roadmap, no single call looks wrong; the rule fires because of what the message is made of. An admin sees the held call in Approvals with the exact message, the rule and the labels, and approves or rejects it.

Five ideas

1. Side effects

Every tool declares one: read (fetches data), write (changes something in a connected system: a ticket, a card, a page) or egress (delivers content to people or places: a message, an email, an invitation, a comment). Rules and the read_only role constraint key off this, never off a tool’s name. The tool catalog lists each tool’s side effect.

2. Labels

Data carries labels such as internal, confidential, untrusted and pii.

Tools label what they return. Docs, Sheets, files, Jira, Trello and GitHub code are internal; web search results are untrusted; GitHub issues are both internal and untrusted, because anyone who can open an issue writes that text.
Label rules add labels, e.g. “reading sheet cust-2026 is confidential”.
Labels follow the workflow. A step’s inputs carry the labels of every step it depends on or references with {{…}}. Parallel branches don’t share labels.

3. Rules

Action rules match on side effect, tools, labels and parameters, and return a verdict: allow, require_approval or deny. When several match, the most restrictive wins.

{
  "kind": "action",
  "name": "Confidential data never leaves",
  "match": {"side_effect": ["egress"], "labels_any": ["confidential"]},
  "effect": {"verdict": "deny"}
}

4. Approvals

A held step pauses the run where it is. Approving resumes it on the worker from that point. Steps that already finished never run again, and the approval covers that exact call (tool plus parameters) and nothing else.

5. Receipts and audit

Every tool call writes a decision with the rule that made it and the labels involved: GET /api/v1/runs/{id}/authorization. The audit log is append-only and hash-chained, and the database rejects edits to it. GET /api/v1/organizations/{id}/audit-events/verify recomputes the chain and reports the first entry that doesn’t match. Before a run starts, Fibonacci analyses the whole plan. If a rule would definitely deny a step, the run is refused up front (403) and nothing executes. POST /api/v1/workflows/{id}/authorization-preview shows that analysis without running anything.

Rules

Rules belong to an organization. Fibonacci ships templates, and nothing is active until an org saves a rule.

GET  /api/v1/governance/rule-templates
GET  /api/v1/organizations/{org_id}/governance/rules
POST /api/v1/organizations/{org_id}/governance/rules           # owner
PATCH /api/v1/organizations/{org_id}/governance/rules/{rule_id}
DELETE /api/v1/organizations/{org_id}/governance/rules/{rule_id}

Adopt a template:

{"template_key": "untrusted-plus-internal-egress"}

Template	What it does
`untrusted-plus-internal-egress`	Approve sends that mix web content with internal data. Egress whose inputs carry both `untrusted` and `internal` needs approval. Covers web search and GitHub issues.
`confidential-no-egress`	Confidential data never leaves. Deny any egress whose inputs carry `confidential`.
`pii-external-email`	Approve emailing PII outside the company. `gmail_send` with `pii` to a domain not in your list needs approval. Replace `example.com` with your domains.
`confidential-out-of-shared-trackers`	Confidential data stays out of shared trackers. Deny creating or editing Jira issues and Trello cards whose inputs carry `confidential`. Those are writes, not egress, so `confidential-no-egress` doesn’t cover them, but boards and projects are often widely shared.

Rule fields

Field	Meaning
`kind`	`action` (returns a verdict) or `label` (adds labels)
`match.side_effect`	Any of `read`, `write`, `egress`
`match.tools`	Only these tool names
`match.labels_any` / `labels_all`	The call’s input labels include any / all of these
`match.params`	Conditions on the call’s parameters (below)
`effect.verdict`	`allow`, `require_approval` or `deny` (action rules)
`effect.add_labels`	Labels to add to the tool’s output (label rules)
`effect.approver_role`	Who may approve: `admin` (default) or `owner`
`priority`, `enabled`	Ordering and on/off

Parameter operators: equals, in, not_in, contains, startswith, domain_in, domain_not_in.

Label rules

{
  "kind": "label",
  "name": "Customer sheet is confidential",
  "match": {
    "tools": ["google_sheets_read"],
    "params": {"spreadsheet_id": {"equals": "https://docs.google.com/spreadsheets/d/1AbC…/edit"}}
  },
  "effect": {"add_labels": ["confidential"]}
}

Paste links. Google Docs, Sheets, Slides and Drive links match the bare file ID a workflow uses, and the other way round.
No placeholders. A whole value like <YOUR_SHEET_ID> is rejected when you save (422) with a message to replace it.

Approvals

Approvals are opt-in: set approvals_enabled in the org’s governance settings. Risk is assessed and audited either way.

Endpoint	Purpose
`GET /api/v1/approvals`	The inbox (your orgs)
`GET /api/v1/approvals/{id}`	One request: the step, its exact parameters, the rule and labels
`POST /api/v1/approvals/{id}/approve`	Approve; a paused run resumes on the worker
`POST /api/v1/approvals/{id}/reject`	Reject; the run is cancelled with the reason
`POST /api/v1/approvals/{id}/cancel`	Withdraw your own request

Who hears about it

If your org has connected Slack (Organization → Integrations → Add to Slack), the Fibonacci bot sends DMs:

When something waits, to every admin and owner who can decide it (owners only when it needs an owner). The message says what is waiting (the tool and step, the workflow, or the agent), the rule and data labels or the risk reasons, who asked and when it expires, and links straight to it in Approvals.
When it’s decided, to the person who asked: who approved or rejected it, their reason, and what happens next.

Slack messages never include the call’s parameters, which can hold customer data; the link opens them behind sign-in. People are found in Slack by their Fibonacci email. If Slack is briefly unavailable or rate limiting, each message is retried once; a message that still can’t be sent is logged, and the request is always in the Approvals inbox. Turn the messages off with slack_approval_notifications: false. The Approvals inbox and the dashboard badge also refresh on their own. Besides rules, whole runs can need approval by risk level. Fibonacci scores a workflow from the tools it uses (sending messages and email is high; creating channels, pages, tickets and cards is medium; reading company data is medium), and runs at or above approval_required_from wait for approval before they start.

Organization settings

GET   /api/v1/organizations/{org_id}/governance
PATCH /api/v1/organizations/{org_id}/governance     # owner

Field	Default	Meaning
`approvals_enabled`	`false`	Whether held steps and risky runs wait for approval
`approval_required_from`	`high`	Lowest risk level that needs approval: `medium`, `high` or `critical`
`approval_ttl_hours`	`72`	How long a pending approval stays actionable (1–720)
`critical_requires_owner`	`true`	Critical-risk runs need an owner, not just an admin
`self_approve_owner`	`false`	Whether owners can approve their own requests
`require_approval_for_external_comm`	`false`	Any run that touches an external system needs approval
`require_approval_for_public_writes`	`false`	Gate public writes
`require_approval_for_permission_changes`	`false`	Gate permission changes (e.g. Drive sharing)
`slack_approval_notifications`	`true`	DM approvers on Slack when something waits, and the requester when it’s decided (needs Slack connected)
`external_tools`	`{}`	Per-tool overrides for external agents: `{"mcp__crm__export": {"side_effect": "egress", "output_labels": ["pii"]}}`

Tool policies

Block a tool, or narrow what it may do, for the whole org or for one role (owner, admin, member, viewer). In the dashboard: go to Governance → Tool permissions. Pick who the policy applies to and the tool, then set its access and limits. The editor only shows the settings that can affect that tool: a GitHub tool offers allowed repositories, and Slack offers channels and a message length. You can paste a github.com link for a repository. Each role’s row shows the limits that apply once the org’s policy is combined with it, and warns when the two leave nothing allowed. Owners make changes; admins see the policies. Through the API:

GET    /api/v1/organizations/{org_id}/tool-policies                              # admin or owner
PUT    /api/v1/organizations/{org_id}/tool-policies/{tool_name}                  # owner
DELETE /api/v1/organizations/{org_id}/tool-policies/{tool_name}                  # owner
GET    /api/v1/organizations/{org_id}/role-tool-policies                         # admin or owner
PUT    /api/v1/organizations/{org_id}/role-tool-policies/{role}/{tool_name}      # owner
DELETE /api/v1/organizations/{org_id}/role-tool-policies/{role}/{tool_name}      # owner
GET    /api/v1/governance/tool-constraints                                       # which settings each tool takes

{"allowed": true, "constraints": {"allowed_channels": ["#eng", "#alerts"]}}

On a role policy, "allowed": null keeps the org’s access and only adds limits. false blocks the tool for that role.

Constraint	Effect	Applies to
`read_only`	Only tools whose side effect is `read`	Any tool that writes or sends, agent tools included
`allowed_channels`	Messages and uploads only to these channels	Tools with a `channel`: Slack, Discord
`max_message_length`	Longest message allowed, in characters	The message a tool sends: `text` (Slack, Trello comments) or `content` (Discord, a Notion page body)
`allowed_repos`	GitHub tools only on these repositories, checked on the repository each request actually reaches: links, `owner/name#7` references and search filters included. Searches across a whole org, a user or all of GitHub are refused, and so is a file path or ref containing `..`.	GitHub tools

GET /api/v1/governance/tool-constraints returns this table for every tool, which is what the dashboard uses. For external agents, a policy names the agent’s tool (Bash, Write, or mcp__<server>__<tool>), and only blocks and read_only apply. Without any policy, a tool works as soon as the person running it has connected it. Policies only ever narrow that, including for someone who saved their own token: a personal token only decides which credential a call uses, never whether a role may make it. Role constraints narrow the org’s: lists intersect, limits take the minimum, and read_only holds if either side sets it. An org block always wins.

Quota

GET   /api/v1/organizations/{org_id}/quota     # limits and live usage
PATCH /api/v1/organizations/{org_id}/quota     # owner: overrides

Limit	Free	Pro	Enterprise
`exec_per_hour`	60	100	1000
`concurrent_jobs`	5	10	50
`max_queued`	100	100	500
`max_runtime_seconds`	300	1800	7200
`max_retries`	3	5	10
`monthly_cost_usd`	50	50	500

A run over quota is refused when it’s queued (429), with the limit it hit.

Workflow versions and the registry

Every execution runs a frozen version of the workflow, so a run is reproducible even if the workflow is edited later.

GET  /api/v1/workflows/{workflow_id}/versions
GET  /api/v1/workflows/{workflow_id}/versions/{version_id}
POST /api/v1/workflows/{workflow_id}/versions/{version_id}/rollback           # new version from an old one
POST /api/v1/workflows/{workflow_id}/versions/{version_id}/approve-template   # owner: add to the org registry
GET  /api/v1/organizations/{org_id}/workflow-registry
POST /api/v1/workflow-registry/{entry_id}/deprecate
POST /api/v1/workflow-registry/{entry_id}/archive

Reporting

Endpoint	What
`GET /api/v1/organizations/{org_id}/governance/summary`	Dashboard numbers
`GET /api/v1/organizations/{org_id}/approvals/report`	Approval statistics over a window
`GET /api/v1/organizations/{org_id}/audit-events`	The audit log, paginated
`GET /api/v1/organizations/{org_id}/audit-events/verify`	Recompute the hash chain

External agents

The same rules for Claude Code and any MCP client

Security

Production hardening and secrets

Getting Started

Core Concepts

Advanced Guides

Updates

An example

Five ideas

1. Side effects

2. Labels

3. Rules

4. Approvals

5. Receipts and audit

Rules

Rule fields

Label rules

Approvals

Who hears about it

Organization settings

Tool policies

Quota

Workflow versions and the registry

Reporting

External agents

Security

​An example

​Five ideas

​1. Side effects

​2. Labels

​3. Rules

​4. Approvals

​5. Receipts and audit

​Rules

​Rule fields

​Label rules

​Approvals

​Who hears about it

​Organization settings

​Tool policies

​Quota

​Workflow versions and the registry

​Reporting

External agents

Security

An example

Five ideas

1. Side effects

2. Labels

3. Rules

4. Approvals

5. Receipts and audit

Rules

Rule fields

Label rules

Approvals

Who hears about it

Organization settings

Tool policies

Quota

Workflow versions and the registry

Reporting