Decionis
Technical note··9 min read

Execution Authority: implementation, not aspiration.

In one week Broadcom, JetStream and ChainIT each moved to the execution-time boundary. Good: the category exists. This note compares what each announcement establishes against twelve capabilities of an execution authority, cites the primary source for every cell, and shows the same protocol reaching agents, runtimes and enterprise systems — with the corpus and verifier that let you check the Decionis column yourself. A fourth column, added 14 September, reads an open-source reference implementation against the same twelve rows; two more, added 22 September, read a mainstream gateway's verifiable-evidence release and a commerce execution-governance launch against them.

Festus Jejelowo · Decionis, Inc. · ORCID

One week, three announcements

Between 31 August 2026 and 2 September 2026 three companies published the same boundary. Broadcom made AgentMinder generally available: each agent action is authorised against its declared mission, intent, context and risk before it reaches an enterprise resource, with existing authorisation infrastructure reused through AuthZEN and an OpenTelemetry audit trail (Broadcom — unveils AgentMinder (investor-relations release), 31 Aug 2026, retrieved 7 Sep 2026). JetStream announced Clearance, which evaluates every agent action at the gateway before it runs, down to tool parameters and across sequences of actions, against a versioned contract it calls an AI Blueprint (JetStream — Clearance: zero trust for AI actions (announcement), 2 Sep 2026, retrieved 7 Sep 2026). And ChainIT published Provable Authority and the ChainIT Authority Protocol: authority determined before one exact action, a canonical transaction digest over the material fields, human step-up, single-use execution authorisation and an append-only record of what was authorised and what occurred (ChainIT — launches Provable Authority (announcement), 2 Sep 2026, retrieved 7 Sep 2026).

We are encouraged by this. Independent teams arriving at authority at execution time is how a category gets drawn, and each of these announcements says, in its own vocabulary, that a valid credential and a safe-looking prompt are not the same thing as authority for the action about to happen. That is the argument this site has been making, and it is better made by four companies than by one.

A fourth column, from open source

A week later the same boundary appeared from the developer side. oneproof published onedoor, the AADP reference implementation: an Apache-2.0 policy decision point in which every agent action is checked against a ratified policy before anything touches the world and answered permit, deny, propose or dry-run, with single-use permits, a two-phase decide-then-report exchange, an append-only record that names the policy digest, an MCP proxy as an enforcement point, and an individual-submission IETF Internet-Draft, AADP, that any implementation can be read against (oneproof — evidence infrastructure for AI agents (site), launch week of 8 Sep 2026, retrieved 14 Sep 2026). Its cells cite the draft, the README, the changelog and the project’s own per-requirement conformance statement rather than an announcement, and its review boundary is stated beside the others.

Two of the project’s own sentences do the matrix’s work for it. The draft’s current permit is a bearer capability, and an action-bound signed permit carrying a digest of the exact authorized action is named as a planned addition; and cryptography — chained rows, Ed25519 signatures, anchoring — is opt-in and off by default. Both are stated plainly, and both are where the rows below separate a per-action authorization from an authority that survives the execution boundary.

Two more columns: a gateway that proves its decisions, and a commerce oracle

Eight days later the boundary was drawn by a mainstream gateway and by a commerce product. Traefik Labs announced Traefik Hub Sovereign Trust Plane: the gateway delegates authority through token exchange, asks the customer’s own policy decision point over OpenID AuthZEN and enforces the answer inline, and then commits every decision to an append-only transparency log with an independent witness and a verifier that runs on the customer’s machine (Traefik Labs — Sovereign Trust Plane (solution page), retrieved 22 Sep 2026). Leviathan Matrix launched TURABON and the Domain Oracle: a proposed purchase or API call becomes a Critical Action, the Domain Oracle answers Allow, Approval Required, Recovery Required or Block, human approval is bound to an action fingerprint, and an execution chain from authorization to receipt is kept for replay (Leviathan Matrix — TURABON launch announcement, 17 Sep 2026, retrieved 22 Sep 2026). Both keep the decision away from the thing that acts: Traefik by authoring no policy, TURABON by keeping execution authority independent of the agent that proposes.

The two columns separate on the same rows as the others. Traefik’s evidence is about the gateway: what it allowed or refused, under which policy, and that the record was not rewritten afterwards. Its own release says application records supply the business outcomes and names attestation as a later pillar. TURABON’s receipt names an approval binding and an audit hash, and its pages describe no verifier that a party outside the platform could run. Gateway decision integrity answers what the gateway allowed and whether its record was altered afterwards; execution-bound authority answers whether the action that executed was the exact action authorized, and what it did.

So this note is not a rebuttal. It is a matrix. Our focus has moved to the harder question: once the action has executed, how does anyone prove that the action which ran remained the action that was authorised — and who is allowed to check? Gateway authorization is not execution-bound authority. The rows below are the capabilities that question turns on. Every Decionis cell links the artifact that implements it. Every vendor cell either cites the announcement that states it or reads “not found in reviewed public materials” — because a company may well implement something it has not yet published, and this note only reads what is public. Checked 2026-09-22.

Twelve capabilities, six columns

ChainIT: The whitepaper is behind a form and the developer documentation URL linked from the announcement returned 404 on the review date, so the column reads only the announcement. Broadcom: Read from the investor-relations release and its newswire syndication; product documentation was not part of the review. JetStream: Read from the launch announcement; the product is pre-GA and no technical documentation was published with it. oneproof: Read from the README, CONFORMANCE.md and CHANGELOG.md at tag v0.7.0, the AADP Internet-Draft (-00 and -01 texts; -02 on the datatracker) and the oneproof.dev site. The user manual and the source code were not part of the review and nothing was installed or run; the conformance statement's header is dated 20 August 2026 against version 0.4.0, and where it and the 0.5.0 changelog differ the changelog is cited. Traefik Labs: Read from the solution page, the press release and the AuthZEN middleware documentation (early access from v3.21.0-ea.3). The Prove pillar's product documentation was not yet published on the review date, and the initial evidence capability is stated to cover gateway logs and access logs; the cells are re-read at general availability. Leviathan Matrix: Read from the launch announcement and the product page on leviathanmatrix.com; turabon.io renders no readable text to a fetcher. No technical documentation, schema, verifier or receipt sample was located, so every cell reads the two marketing pages.

CapabilityDecionisChainITProvable Authority and the ChainIT Authority ProtocolBroadcomAgentMinderJetStreamClearanceoneproofonedoor, the AADP reference implementationTraefik LabsTraefik Hub Sovereign Trust PlaneLeviathan MatrixTURABON and the Domain Oracle
Pre-execution authorizationIs the action decided before it executes, rather than logged after?implementedEvery consequential action is evaluated against the organisation's own policy bundle before commit and answered ALLOW, ESCALATE or BLOCK. Execution AuthoritystatedAuthority is determined before one exact action executes.statedEach agent action is authorised before it reaches an enterprise resource.statedEvery agent action is evaluated before it runs.statedEvery action is evaluated against the policy table before anything touches the world; the verdicts are permit, deny, propose, dry-run, observe or replay (AADP §3.2).statedEach API request or MCP tool call is sent to the customer's policy decision point over AuthZEN and the decision is enforced before the request is forwarded; a deny returns a 403, or a JSON-RPC error for MCP.statedCritical actions are checked before an external execution route is allowed and answered Allow, Approval Required, Recovery Required or Block.
Deterministic, versioned policyDoes the same policy revision and the same inputs always give the same verdict?implementedThe verdict is a deterministic function of the policy revision, the request and the supplied facts; policy revisions are immutable and the revision is recorded in every dossier. Policy decision graphstatedDeterministic pre-execution controls over versioned authority policies are stated.not foundnot found in reviewed public materials; Authorisation against mission, intent, context and risk is stated; the evaluation method is not.not foundnot found in reviewed public materials; The Blueprint is versioned; evaluation is described as a reasoning engine, and determinism is not stated.statedDeterminism over the full evaluation input is normative (AADP §9); policies are data, a content digest of the policy is stamped on every audit row, and superseded policy must be retained (AADP §10).not foundnot found in reviewed public materials; the gateway authors no policy and enforces whatever the customer's decision point answers; determinism and versioning belong to that engine and are not stated for the gateway.not foundnot found in reviewed public materials; policy, budget and workflow-order checks and a policy version on the receipt are stated; how the Domain Oracle evaluates, and whether the same inputs always give the same answer, is not.
Exact-action bindingIs the authorisation tied to the exact material fields of the action that will execute?implementedExecutionBinding 1.0 binds the dossier to the canonical payload digest, execution target, policy identity and digest, material signals, validity window and nonce. Execution authority evidencestatedA canonical transaction digest binds payer, payee, destination, amount, currency or asset and rail.not foundnot found in reviewed public materialsnot foundnot found in reviewed public materials; Tool parameters are evaluated; a commitment carried to the downstream execution is not described.not foundnot found in reviewed public materials; parameters are bound-checked and the permit is a bearer capability in the current revision; an action-bound signed permit carrying a digest of the exact action is described as a planned addition (AADP §1.2; conformance item A10).not foundnot found in reviewed public materials; the AuthZEN request is built from token claims and request fields by a CEL mapping; a commitment to the exact payload carried through to the downstream call is not described.not foundnot found in reviewed public materials; approval is bound to a stable action fingerprint so a changed amount, vendor, policy, tool or scope does not reuse it; what the fingerprint covers and how it reaches the executing provider is not described.
Canonical payload commitmentIs the digest computed over a published canonical form, so anyone can recompute it?implementedPayloads and bindings are canonicalised with RFC 8785 (JCS) and digested with SHA-256; the profile is named inside the dossier so a verifier recomputes it without asking Decionis. Verify a Decision Dossiernot foundnot found in reviewed public materials; A canonical digest is stated; the canonicalisation profile and algorithm are not.not foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materials; a canonical serialisation and digest of the action payload is not stated for the current revision.not foundnot found in reviewed public materials; cryptographic fingerprints of gateway and access logs are committed to the transparency log; a canonical digest over the action itself is not stated.not foundnot found in reviewed public materials; an action fingerprint and an audit hash on the receipt are stated; the canonical form and the algorithm are not.
Pre-commit revalidationImmediately before commit, is the authorisation checked again against current policy and signals?implementedThe claim step revalidates the signed dossier, the current policy revision, material signals, human approval, target, payload, expiry and nonce before the action is released. Claim before commitnot foundnot found in reviewed public materials; Single-use authorisation is stated; a revalidation step at commit is not.not foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsstatedA resumed approval is re-evaluated as a new decision and a kill switch engaged after approval still denies (AADP §8); a directly permitted action executes on the permit, and a separate check at commit is not stated.not foundnot found in reviewed public materials; the decision is enforced on the request in flight; a separate revalidation against current state before the downstream commit is not described.not foundnot found in reviewed public materials; a changed action is stated not to reuse an earlier approval; a revalidation step against current policy and state at the moment of execution is not described.
Replay-resistant, single-use grantCan an authorisation be presented twice, or for a different action?implementedEach grant carries a nonce that is claimed once, within a lease; a second claim, an expired lease or a substituted payload is refused and recorded. Execution authority evidencestatedSingle-use execution authorisation is stated.not foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsstatedA permit id is single-use and a second report for it is rejected; the request id is the idempotency key; a granted approval is consumed on use (AADP §7–8). The conformance statement records sender-constrained permits as an open item (A2).not foundnot found in reviewed public materials; delegated tokens are scoped and exchanged per hop; a single-use, nonce-bound authorisation for one action is not described.not foundnot found in reviewed public materials; duplicate-payment protection and duplicate windows are stated; a single-use, nonce-bound authorisation for one action is not.
Human authority bound to the actionWhen a person approves, is the approval tied to the exact action, not to a session?implementedPresence resolves an ESCALATE with a verified human whose approval carries the action's binding digest and is revalidated before the nonce is claimed. Presencenot foundnot found in reviewed public materials; Human step-up is stated; that the approval is bound to the transaction digest is not.not foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsstatedThe propose verdict creates an approval with a deadline; who approved and when is recorded, the approval is single-use and the action is re-evaluated on resumption (AADP §8); binding of the approval to a digest of the exact action is not stated.not foundnot found in reviewed public materials; human approval is not part of the three pillars; the decision point may implement it, and the gateway does not state a binding of an approval to the action.statedApproval Required pauses the action for a person, and the approval is bound to the action fingerprint so a changed amount, vendor, policy, tool or scope does not silently reuse it.
Effect evidenceAfter execution, is the observed outcome recorded with a digest of the actual response?implementedFinalisation records CONFIRMED, FAILED or INDETERMINATE with the request digest, a response digest for confirmed effects, the observer and its version, and how the effect was observed. Effect evidencenot foundnot found in reviewed public materials; An append-only record of what was authorised and what occurred is stated; a response digest is not.not foundnot found in reviewed public materials; An OpenTelemetry audit trail is stated.not foundnot found in reviewed public materialsstatedThe enforcement point reports success, failure, timeout or not_attempted against the permit, and the intent row is durable before the permit returns, so a crash leaves an intent with no result (AADP §5.3, §9); a response digest or an observer identity is not stated.not foundnot found in reviewed public materials; evidence covers what the gateway allowed or refused; the press release states that application records supply the business outcomes, and a response digest for the executed action is not described.not foundnot found in reviewed public materials; receipts carry intent, policy, approval, execution evidence and outcome, and a recovery trail preserves the case when execution fails or evidence is missing; a response digest and an observer identity are not stated.
Signed input snapshotAre the exact inputs the verdict was reached on signed alongside the verdict?implementedThe inputs snapshot is built once, signed with the dossier and stored verbatim, so a verifier can replay the decision from what was actually evaluated. Decision Dossiernot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsstatedEach evidence entry carries the request, verdict, reason, both tiers, a timestamp and the policy digest and must be sufficient to re-derive the verdict (AADP §10); Ed25519 signing of rows is an opt-in extra, off by default (README; changelog 0.5.0).not foundnot found in reviewed public materials; the decision, the policy that answered and the reason are written to the same tamper-evident record as the request; a signed snapshot of the inputs the decision point evaluated is not stated.not foundnot found in reviewed public materials; the receipt records the policy version and the approval binding; a signed snapshot of the inputs the Domain Oracle evaluated is not stated.
Offline verificationCan a party who does not trust the operator verify the evidence with the service off?implementedAn open verifier checks the Ed25519 signature, recomputes the digests and refuses the negative cases, from two files and a published key set, with no account and no call to Decionis. Verify without an accountnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsstatedWith signing on, a receipt verifies against a key id supplied from outside the store and otherwise reads self-consistent; a Merkle root a deployer publishes lets a third party check an exported receipt's membership (README; changelog 0.5.0). Chaining, signing and anchoring are opt-in and off by default.statedAn open verifier checks inclusion and consistency proofs and the witness signature on the customer's own machine, without trusting Traefik; the record it verifies is the gateway's decision log.not foundnot found in reviewed public materials; receipts are described as verifiable and auditable with an audit hash; a verifier a party outside the platform can run was not found.
Portable SCITT-profile evidenceCan the evidence leave the vendor's format and be checked by someone else's tooling?implementedA dossier and its execution lifecycle export to the SCITT Agent Action Capsule draft-04 profile with a COSE-signed producer envelope; a draft-pinned compatibility claim, not conformance to a published standard. SCITT-compatible exportnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materials; the log is built on C2SP tlog-witness and Tessera; a SCITT or other portable evidence profile is not stated.not foundnot found in reviewed public materials
Public verification corpusIs there a published corpus a reviewer can run the verifier against today?implementedA synthetic corpus of signed dossiers, including the cases a verifier must refuse, is archived with a DOI under Apache-2.0 with its signing key deliberately published. Corpus DOInot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materialsnot foundnot found in reviewed public materials; the oneproof suite publishes sample receipts, a reference verifier and ten rejection vectors for its separate stage-receipt format (preview, 11 September 2026); a corpus for onedoor decision receipts was not found.not foundnot found in reviewed public materials; a Traefik-operated public witness is available at launch; a published corpus of decision records to run the verifier against was not found.not foundnot found in reviewed public materials

“Stated” means the cited announcement establishes the capability; the cell also says where the statement stops. “not found in reviewed public materials” is exactly that, and not a claim that the vendor lacks it.

What the rows add up to

Read down the Decionis column and the twelve rows are one lifecycle. An intent becomes a deterministic verdict; the verdict is bound to the exact action; the binding is claimed once, immediately before commit; the action executes; the observed effect is recorded with a digest of the real response; all of it is signed together; the record can leave in a standards-profile envelope; and anyone can verify it with our service switched off.

  1. 01Intent — an agent, workflow or person proposes one exact action
  2. 02Deterministic authority — policy revision + request + supplied facts → verdict
  3. 03ExecutionBinding — verdict bound to payload digest, target, policy, signals, nonce
  4. 04Pre-commit claim — single-use claim, revalidated against current state
  5. 05Execution — the downstream system performs the bound action
  6. 06Effect evidence — observed outcome with request and response digests
  7. 07Signed dossier — Ed25519 over inputs, verdict, binding and effect
  8. 08SCITT capsule — optional draft-04 export with a COSE producer envelope
  9. 09Offline verification — anyone recomputes and refuses, with the service off

Authority that survives the execution boundary.

The lifecycle is numbered because the order is the point: each artifact commits to the one before it, which is what lets the last step happen without trusting the party that ran the first eight. Vendors converging on the execution-time boundary validate the category; the question that remains is whether the action that executed stayed the action that was authorized, and who can check.

Multiple enforcement surfaces, one authority protocol.

An authority protocol that lived in one gateway would be a gateway. The same semantics — the same verdicts, the same binding, the same dossier — reach the places agents, runtimes and enterprise systems actually execute. Each row’s status is read from the registry that owns it, so this table cannot promise a surface the registry does not.

SurfaceRoleStatus
AgentsAgent-Safe PipelineOpen reference implementation of exact-action authorization, lifecycle enforcement and audit evidence for agent pipelines.Apache-2.0 · v0.1.4
Claude and ChatGPT connectors (MCP)Authority where agents invoke tools: a decision before the tool call, from inside the assistant.production
RuntimesAgentSafe gatewayThe execution boundary as an installed gateway in front of any agent or API: consequential HTTP actions intercepted, asked of Decionis, forwarded exactly once on a single-use grant or held or refused, with chained evidence; a boundary test shows what reaches a target without it.Apache-2.0 · from the repository
Govern, the workflow gateCI execution: a deploy, a migration, an infrastructure change or an agent's action decided before the workflow step runs it, on GitHub Actions, GitLab CI, Jenkins or any runner; the command only on a claimed grant, an escalated step held for a person, the outcome finalized into the dossier.Apache-2.0 · 2.0.0 · decionis/govern@v2
Docker DesktopLocal and container execution: live decision evaluations and offline dossier verification inside the developer's runtime.installable
EnterpriseUniversal Commerce Protocol checkoutAgentic commerce execution: an authority decision bound to the exact checkout before the merchant commits.reference published
Verifying Provider ProfileSystem-of-record verification: the hop an owner controls in front of a core, or the core itself, verifies the executor's signed request and the authority's claim attestation, refuses what the authority never claimed, and answers with its own signed receipt of the effect, with vectors any implementation runs to claim conformance.Apache-2.0 · agent-safe.verifying-provider/1 v0.2 draft
Enterprise adaptersBusiness-system execution: SAP and ServiceNow, and the Zapier and n8n automation connectors, gated at the consequential-action boundary.validated · production · installable
Human authorityPresenceHuman authority bound to the action: a verified person resolves an ESCALATE, and the approval carries the action's binding digest.live
EvidenceDecision Dossier corpus and verifierIndependent evidence verification: the public corpus and the open verifier reproduce every check with the service off.@decionis/verify@0.4.0 · DOI 10.5281/zenodo.22692903

No identity provider, gateway, agent framework, cluster or enterprise application has to be replaced: the same execution-authority protocol sits at the consequential-action boundary in each of them.

Standards, drawn outside the architecture

None of the above depends on a standards body, and we keep it that way on purpose. Where Decionis touches a standard it is as a crosswalk, a contribution or a compatibility profile, and each relationship is stated in the one sentence it can bear:

Check the Decionis column yourself

Don’t take the left-hand column on trust either. The public corpus — v0.1.4, Apache-2.0, archived with DOI 10.5281/zenodo.22692903 — and the open verifier @decionis/verify reproduce every check in the offline verification row, including the negative cases a verifier must refuse. Download the evidence, leave our service out of the loop, and verify the decision:

npx -y @decionis/verify \
  --file dossiers/vectors/owned-execution-bound.json \
  --jwks dossiers/corpus-jwks.json

The corpus proves the verifier; a production dossier verifies against the live key set, and the technical note walks through both. If a row in the Decionis column does not survive that exercise, the row is wrong and we will correct it.

Sources

We are not a member, partner or certified implementer of any standards body named above. Vendor statements are read from the cited announcements on 2026-09-22 and re-checked as they are touched; if you are one of the vendors and have published something the matrix does not reflect, send the link and the cell will be updated with the citation.