Skip to main content

Capability Control and Approval

Granting a capability, tool access, a resource permission, a role assignment, a key issuance, is itself a governed action. Before a grant takes effect, a capability-grant gate evaluates it on several axes at once and can grant it, send it for human review, or deny it.

The axes of a grant decision​

The gate composes four criteria into one decision:

CriterionWhat it checks
Grantee trustA coherence trust signal for the grantee. The gate refuses to fabricate trust: insufficient trust data routes to review, not to a grant.
Net potential gainThe grant action is run through the Net Potential Gain (NPG) gate; a negative net potential gain denies, insufficient data routes to review.
Capability sensitivityAn operator-assigned tier: low, medium, high, or critical.
Blast radiusThe estimated number of entities the grant could affect, with a hard maximum and a warning fraction per sensitivity tier.

The composition is deterministic and strictest-wins: high severity on any criterion denies; medium on any routes to review; only when every criterion is clear is the grant issued. Blast-radius ceilings tighten as sensitivity rises, a low-sensitivity grant may reach many entities, a critical one only a very few.

Human approval as a first-class step​

Review is not an error path; it is a designed verdict. A critical-sensitivity grant routes through human review by default, even when every per-criterion check would otherwise pass, the platform's default protects against a silent critical grant. In the data-exchange lifecycle, the same principle appears as an explicit request → approve / deny → provision flow, so a person is in the loop at the point access is decided.

Commercial and revenue actions are gated the same way: an action that changes pricing, renewal, or take-rate is routed through a policy gate before it takes effect, judged for its net effect and for extraction pressure rather than waved through.

When one approver is not enough: N-of-M dual control​

Some operations should not be one person's decision, however senior. For those, the platform can require M distinct approvers out of N eligible ones to each cryptographically sign off before the operation runs.

Two properties make this more than a workflow state machine.

It is operation-agnostic. A quorum is keyed by an arbitrary (operation kind, operation reference) pair, so any sensitive operation can demand one without the governance layer needing to know what that operation is. There is no enumerated list of quorum-able actions to extend.

A signature binds one operation instance. The request carries a hash over the canonical form of the operation's parameters, and each approval signs that. An approval therefore cannot be lifted off one operation and replayed onto another, or onto the same operation with the parameters quietly changed after the fact. Approving "delete these three objects" is not approving "delete everything".

PropertyHow it holds
Signed, not recordedEach approval is an Ed25519 signature, using the platform's existing approval primitive rather than a new crypto path
Approver is the callerThe approving identity is the authenticated caller, never a field in the request body. There is nothing to spoof
Separation of dutiesThe requester cannot approve their own request, and the same approver cannot count twice. Enforced both as a friendly check and as a uniqueness constraint in the store
Re-verified at the point of useThe operation's own execute seam re-verifies the quorum cryptographically rather than reading a status flag. A "quorum met" record is not what authorizes the act; the signatures are
Verifiable on every cellThe approval ledger converges across the organization's nodes, so a governed decision is checkable identically anywhere. Convergence does not weaken the threshold, it still takes M live signatures
Deny-closed by defaultA request that does not pin a size takes a default of two distinct approvers, never one

That fifth row is the one to hold on to. Storing "this was approved" and trusting it later is the failure mode this design is built to avoid: a status flag is something an attacker can flip, whereas M valid signatures over a specific parameter hash is something they have to actually forge.

The whole path is local. Approvals are signed and verified on the cell, so multi-party control holds on a sovereign or disconnected deployment with no external approval service to reach.

The operator surface​

OperationEndpoint
Open a requestPOST /api/public/v1/admin/governance/quorum/requests
Record one signed approvalPOST .../quorum/requests/{request_id}/approve
Read the re-verified statusGET .../quorum/requests/{request_id}
Where this is reachable today

The quorum service and the operator surface above are live and general. Its first built-in consumer is sensitive-tier join admission, the check that admits an entity into a compartmented clean room or a high-impact-level engagement, which now resolves its quorum server-side and fail-closed rather than on a flag the caller asserts.

That consumer is wired to the admission gate and exercised by tests, but the clean-room join route that would host it in production does not yet run through the gate. So today the quorum's live surface is the operator route and the service behind it, and the compartmented-join case is ready rather than reachable from the clean-room console.

The read side of governance​

Governance has a read side, not only an enforcement side. You can ask what would be denied, or what a principal can currently reach:

  • Grant resolution answers "does this principal hold access?" directly off the canonical grant graph, and can resolve a whole page of listings at once for discovery.
  • Offer discovery is the read side of the data exchange: a need-to-know-gated listing of what a caller may request, annotated with the caller's standing.
  • A reach introspector computes a principal's effective reach across the grant graph, direct grants, group and workspace expansion, and role privileges, as a blast-radius report, flagging an unbounded reach (a wildcard or admin privilege) or a cross-workspace reach for review.

Budget as an attenuation axis​

For agents, a spending budget is one of the axes a grant attenuates along: a sub-agent's budget must fit within its parent's, so authority over cost narrows down a delegation chain just as scope and clearance do (see Authorization and delegation).

Design status

Capability control is described by mechanism. The capability-grant gate is a cell-side control; the edge enforces authorization through its own default-deny policy engine and the NPG gate. The revenue policy gate governs commercial and billing actions. It is not a per-agent compute-budget limiter.