Govern overview

One gate for every write

Every write that a flow, a dead-letter retry or an agent makes through a connector passes through one gate. The gate checks your policies, asks a person when one is needed, enforces limits and records hash-chained evidence before the provider is called. Reads always run.

The gate answers with one of three decisions:

A write must also be switched on for its connection. A connection can only perform the write operations you ticked when you set it up (see Connections).

Risk tiers

Nexra gives every connector operation a risk tier. The tier is set by Nexra on the server and shown on each operation, so a caller cannot lower it.

Payments run as you set them up. Payments run through your own payment account, exactly as you set them up. Add approval rules or limits if you want them, and daily reconciliation shows what moved. Payouts, transfers, refunds and charges are turned on per connection and managed in Connect → Money movement; payments that Nexra Agent or an AI tool starts always wait for a person. Other R4 writes, such as deletes and bank transactions in a ledger, are refused: no policy, grant or approval can allow them, and every attempt is recorded as evidence with the rule risk_tier_r4_denied. Creating a payment in Xero or QuickBooks Online, for example, never runs through Nexra. Editing an existing payment record moves no money, so it is R3.

Policies

Open Govern → Policies to choose what happens to each write. A policy applies to one connection or to the whole workspace, and to one operation (for example invoices.create) or to every write (*).

The most specific active policy wins, and policies are never merged:

Each policy sets an effect (allow, require approval or deny) and can add:

Policies are switched off, never deleted, and every change is written to the audit log.

A good starting point: one workspace policy on every write that allows writes but requires approval at R3 and above. Messages, billable calls and payment links then wait for a person; ordinary record updates run. Add an allow policy for an exact operation when it should always run.

Amount limits

For an operation that carries an amount, set the amount field, its currency, a per-action limit and a rolling 24-hour limit. Amounts are exact decimals in the same unit as the field, so a limit on a field in pence is in pence.

Grants

A grant lets one flow or one agent credential write through one connection, for a set of operations, until it expires (at most 366 days). Each grant records who created it and why.

Turn on Require grants for every write in Govern → Grants, or set Require a grant on a single policy. A write without an active grant is then refused before any policy rule is checked. Revoking a grant stops that caller immediately; revoked grants stay on record.

Test a policy before you save it

Every policy has Test this policy. Choose an operation, paste a sample input and test it against your saved policies or your unsaved changes, optionally as a specific flow or credential. Nothing is written, reserved or approved.

The same dry run is available over the API:

POST /api/console/connect/governance/decisions/explain
Content-Type: application/json

{
  "connectionId": "<connection id>",
  "operationKey": "payment_links.create",
  "input": { "amount": 800, "currency": "GBP", "reference": "ORDER-1001" },
  "principalType": "mcp_credential",
  "principalId": "<MCP credential id>"
}

{
  "decision": "deny",
  "rule": "amount_per_action_exceeded",
  "reason": "The amount 800 GBP exceeds the per-action limit of 700 GBP.",
  "riskTier": "R3",
  "policyId": "<policy id>",
  "effectSource": "connection_operation",
  "amount": {
    "value": "800",
    "currency": "GBP",
    "perActionLimit": "700",
    "rolling24h": { "used": "300", "reserved": "0", "limit": "1000" }
  },
  "grant": { "id": "<grant id>", "expiresAt": "2027-03-31T00:00:00.000Z" },
  "grantRequired": true,
  "inputError": null,
  "evaluatedAt": "2026-10-09T09:12:44.120Z"
}

Add "policy": { … } to test an unsaved draft. When the input itself would be refused by the provider, inputError says why and the decision is still reported.

Approvals bound to the exact action

An approval covers one write, once. Its digest binds the workspace, the connection, the operation, the normalised input and where the write came from (the flow record and step, or the agent credential). A different amount, record, connection or caller produces a different digest, so the approval does not cover it.

In a flow, a record that needs approval waits in the dead-letter queue while other records carry on. Approving it in Nexra resumes that record automatically and writes it once.

The approvals inbox

Open Govern → Approvals. Requests are listed oldest deadline first, with the action in plain words, the risk tier and who can approve. Each request shows:

Before you approve, tick each check: the amount, party and target record are what you expect; the details are correct and complete; and you would make this change yourself. Billable operations and operations that send messages add their own check. A note is required to reject.

Keyboard shortcuts

Nothing is decided by a single key. Approving still needs every check ticked, and rejecting still needs a note.

Decide over the API

POST /api/console/connect/governance/approvals/<approval id>/decision
Content-Type: application/json

{
  "decision": "approve",
  "reviewedDigest": "9c41f0a7e2b6…",
  "note": "Matches the signed purchase order."
}

reviewedDigest is the binding.digest from GET /api/console/connect/governance/approvals/:id. Refusals carry a code: reviewed_digest_required, approval_digest_mismatch, note_required, self_approval_forbidden, approver_role_required, not_pending or expired.

Measures

Govern → Overview shows what is waiting for a person, the median time to decide, denied writes by rule and whether the evidence chain still verifies, over the last 7 or 30 days. See Prove overview for the same measures over the API.

Who can do what

API

All routes are under /api/console/connect/governance. Lists return {items, nextCursor}; pass nextCursor back as cursor until it is null.

A policy body looks like this:

{
  "connectionId": "<connection id>",
  "operationKey": "invoices.create",
  "effect": "require_approval",
  "approverRole": "APPROVER",
  "approvalExpiresInMinutes": 240,
  "maxRecordsPerRun": 200,
  "amountPath": "lines.0.amount",
  "amountCurrency": "GBP",
  "perActionAmountLimit": "2500",
  "rolling24hAmountLimit": "20000",
  "minRiskTierForApproval": "R3",
  "grantRequired": false
}

Next