Governance

The Governance screen is where workspace administrators control who can do what, review every access decision, and maintain a tamper-evident record of all significant events.

The screen is divided into three groups in the left-hand section rail:

Access control

For how roles, capabilities, and capability-gated actions fit together, see Access control. Sensitive actions — approving a human-in-the-loop step, deciding a release gate, granting break-glass access, and reading the audit ledger — require the matching capability and are denied for roles that lack it.

Roles

The Roles section shows the RBAC (role-based access control) configuration for your workspace. A role is a named set of capabilities.

Capability matrix A table lists every role in the workspace as a column, and every registered capability as a row. Check or uncheck a checkbox to grant or revoke a capability for that role. Changes are staged locally; click Save to persist them.

Default role A dropdown at the top selects the default role assigned to new members. Users who have not been explicitly assigned a role receive the capabilities of the default role.

Role management

• Create role — enter a name and click Create.
• Delete role — click the delete button on a role column header. Deleting a role removes all assignments to it.

Policies

The Policies section shows two things:

Operator roles table A read-only view of the canonical surfaces (screens) and actions (RPC methods) each system role is allowed to access. This is driven by the system configuration and cannot be edited here.

Workspace isolation profiles For each workspace, you can set an isolation level:

• None — no isolation applied; the workspace shares resources freely.
• Standard — default. Network and resource isolation between workspaces.
• Strict — maximum isolation; additional constraints on cross-workspace data access.

Change a workspace's isolation level using the dropdown in the table row. Changes take effect immediately.

Egress allow-list The egress allow-list editor is located at Tools > Egress (linked from this section). Click the link to jump there to manage outbound network allow/deny rules.

Membership

User and team CRUD moved to the dedicated Teams screen (Settings › Teams). Use Teams to invite members, assign roles, and manage team membership. Access (this screen) remains the policy overview — capability matrix, isolation profiles, audit, and break-glass.

Audit trail

Audit

The Audit section is a signed HITL ledger — an append-only log of every human approval, rejection, and escalation in the workspace. Each entry is chained with a SHA hash and signed with an ed25519 key, making the log tamper-evident.

Filters

• Actor — filter by the user or system that performed the action.
• Actor type — human or system.
• Kind — filter by event type (approval, rejection, escalation, etc.).
• Date range — restrict to a time window.
• Signed only — show only entries that have a valid chain signature.

Toolbar actions

• Verify chain — run the integrity check on the current ledger. A banner reports whether all chain links and signatures are valid.
• Export CSV / NDJSON — download the visible entries (requires audit:export permission).
• Export signed batch — download a cryptographically signed export bundle suitable for submission to compliance reviewers.
• Verify exported file — upload a previously exported signed batch file to verify its integrity offline.
• Print — browser print of the visible log.

History

The History section shows governance-specific events filtered from the broader audit ledger:

• RBAC role changes (rbac.roles.set)
• Access denials (rbac.denied)
• Workspace isolation changes
• Break-glass grants, revocations, and expirations

Each row shows the sequence number, timestamp, actor, event kind, workspace, subject, and a summary of the payload. Click Open in Audit to jump to the full audit entry.

Governance posture card

A Governance posture summary card on the Dashboard shows the current live security mode at a glance:

• Sandbox — whether agent tool calls are sandboxed.
• Egress N — number of active egress rules.
• Firewall — whether the network firewall is active.
• Audit — audit logging status.
• Cost-metered — whether cost limits are enforced.

Each chip is a shortcut to the relevant configuration screen.

Break-glass access

In situations where normal RBAC would block an urgent action, an administrator with access.breakGlass permission can grant temporary elevated access. Break-glass events are recorded in the History section and automatically expire after the configured duration. See Workspaces for break-glass configuration.

Self-heal

Self-heal lets the runtime propose a recovery action when a flow node fails, instead of simply stopping the run.

• Off by default. Self-heal is strictly opt-in. Enable it in Settings → Orchestration.
• Recovery proposals. When a node fails, the runtime proposes a recovery action — for example, retry the node or switch model — based on the failure.
• Require approval. Optionally require a human to approve a recovery verdict before it is applied. When approval is required, nothing is auto-applied until a reviewer signs off.
• Max auto-retries. Cap how many times the runtime may auto-retry a node before it gives up and escalates.

Compliance and consent

Compliance is a first-class nav item under Governance. Data-subject consent records (GDPR Article 6 basis tracking) remain in workspace privacy settings (config › Privacy).

Activation and retention metrics

Activation and retention metrics are strict opt-in. Nothing is collected until the workspace owner consents in Settings → Privacy. While consent is unset or disabled, every metric event is dropped.

When enabled, only stable categorical fields (ids, event kinds, bucketed timings, provider categories) are captured. No prompts, secrets, code contents, or PII/PHI are ever recorded.

Related screens