The category

Execution Authority

Decionis decides what has authority to happen. Customer policy decides whether this exact action may proceed; Presence supplies action-bound human evidence when required; the execution outcome becomes verifiable proof.

Start free

Three boxes, not two

Identity proves who. Guardrails judge content. Authority decides the action.

Most teams evaluate with two categories in mind and assume the action is covered. The third box answers a question neither of the others asks — and it treats both of them as inputs.

Necessary. Not sufficient.

Identity and access

Who is acting, and what may it reach?

What it answers: Authenticates the person or the agent, issues and rotates its credentials, and decides what it may reach in general — roles, scopes, tokens, and the delegation chain from a human to the agent acting for them.
What it cannot answer: Whether the action in front of it should happen. A correctly logged-in agent with the right role can still stack discounts below cost, and a valid token can still spend past the budget it was granted under.
What it hands to Decionis: The principal, its delegation and its scopes — the inputs the authority check reads, from the identity layer you already run. Nothing here is replaced.

Examples: Okta · Microsoft Entra · Auth0 · WorkOS

Decionis vs identity and access management

Necessary. Not sufficient.

Guardrails and AI security

Is this input or output unsafe, hostile, or out of policy?

What it answers: Filters prompts and responses, detects injection, leakage and anomalous behaviour, and scores the risk of what a model is about to say or has just said — inside the AI layer, in real time.
What it cannot answer: Whether the resulting action may execute, or who approved it. An agent can reach the same tool from outside the guardrail, and a perfectly clean output can still be a purchase nobody authorised.
What it hands to Decionis: Risk and intent signals, as evidence inside the evaluation. A guardrail verdict is a fact the policy reads; it is not the decision, and it leaves no record a counterparty can check.

Examples: Guardrails AI · Check Point (Lakera) · F5 AI Guardrails · Amazon Bedrock Guardrails · NVIDIA NeMo Guardrails

Decionis vs model guardrails

The third box

Execution Authority

May this exact action execute, now, under whose approval — and can that be proven afterwards?

What it answers: Evaluates the proposed action against the organisation's own policy before it commits, holds it for a named person when the rules require one, and signs a record of what was permitted that someone who does not run Decionis can re-derive.
What it cannot answer: Who the actor is, or whether a prompt was hostile — it consumes both from the boxes beside it. It is the organisation's instrument for the organisation's policy, not an arbiter between the organisation and its counterparties.
What it hands on: A signed Decision Dossier and an execution grant bound to the exact action — what the downstream system executes, and what an auditor, a bank or a buyer verifies against a published key.

Decionis

The category, in full

Identity and guardrails are inputs to authority, not rivals to it. Decionis sits above your identity layer and beside your guardrails — not instead of either.

The map folds the seven-layer control stack into three questions. One layer belongs to no box: execution itself — the downstream system’s commit — is what all three exist to govern.

The map on one page, to print or send →

Three properties make it authority.

It binds the exact action

Authority covers one canonical payload, target, actor, policy state, signal state, and commit window. A changed action needs a new decision.

A person's approval travels with the action

When the rules say a human decides, that approval is bound to the specific action and carried into execution — not left in a chat thread for someone to reconstruct later.

Every answer leaves proof

Each exercise of authority is recorded and signed, so anyone — your auditor, your bank, your buyer — can verify what was permitted, under which rule and whose approval, without taking your word for it.

Why this holds

Your decision record writes itself.

Every other approach asks someone to write decisions down and keep them current. That habit reliably lasts a few weeks. Decionis never asks: every time the gate authorizes, holds, or blocks an action, the record is written as a side effect of doing the job. Run it for a month and you have a decision record whether or not anyone maintained anything.

Nobody has to remember

The record is a byproduct of authorizing the action, not a separate task someone owes you at the end of the week.

It cannot go stale

It describes what was actually permitted, when, and under whose approval — not what someone intended to write down afterwards.

Anyone can check it

Each entry is signed, so an auditor, a bank, or a buyer verifies it against a published key instead of taking your word for it.

This is also why rules files aren't enough. Anthropic's own documentation says Claude treats memory files as “context, not enforced configuration”, and that when two rules contradict each other it “may pick one arbitrarily”. Injection is not enforcement.

Evaluated outside the system it governs

Independent, in two specific senses.

Every adjacent tool is embedded in the stack it evaluates — a gateway watching its own traffic, an identity provider auditing its own tokens. The authority has to stand outside that, and the word has exactly two honest meanings.

The architectural claim

Independent of the system it governs

The policy is evaluated outside the application that proposed the action, so the check survives the failure of the thing it checks. A floor enforced inside the tool that moved the price is gone the moment that tool is what went wrong.

The evidential claim

Independently verifiable

The verdict can be re-derived from the dossier by someone who does not run Decionis. A signature proves a record was not altered afterwards; re-derivation proves the answer was the one the policy required.

The second claim is checkable without an account: a public corpus of signed dossiers and an open verifier let anyone confirm that the verifier refuses what it should, and a published key set lets anyone verify a real record. Check a Decision Dossier yourself.

Independent describes where the check runs and who can recompute it. It says nothing about the commercial relationship: Decionis is a paid vendor, enforces its customer’s own policy, and issues no opinion of its own.

Independently checkable

Verify it with our service switched off.

Every claim on this page about evidence rests on one test: can a party who does not trust Decionis check the record without Decionis in the loop? The public corpus and the open verifier let you run that test now, with no account and no network call to us.

Step 1
Download the evidence
The Decision Dossier corpus — v0.1.3, Apache-2.0, archived with a DOI — is a set of signed dossiers with their inputs snapshot, execution binding and JSON-LD, plus the negative cases a verifier must refuse. The signing key is published on purpose, so you can regenerate the corpus instead of trusting the fixtures.
DOI 10.5281/zenodo.22312956
Step 2
Leave Decionis out of the loop
@decionis/verify is an open verifier that runs from two local files: the dossier and the key set. It recomputes the RFC 8785 canonical form, checks the Ed25519 signature and the execution-binding and dossier digests, and refuses anything altered. Disconnect if you like; it needs nothing from us.
@decionis/verify@0.2.0
Step 3
Verify the decision
The corpus proves the verifier behaves correctly, including when it should refuse. It does not prove that a production dossier verifies — that needs a real dossier and the live JWKS, and the repository documents that check separately rather than shipping a production artifact it should not have. The technical note walks through both halves, including the live key set a production dossier is checked against.
Verify a Decision Dossier without an account

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

For a regulated institution this is the test that matters: evidence that remains checkable by a party who does not trust the operator, and that stays checkable if the operator disappears.

Verify a dossier on this site Corpus on GitHub Production signing keys (JWKS)

What execution authority is not.

The adjacent categories are real and useful — they answer different questions, and Decionis is none of them.

Not an identity system

Identity proves who is acting, and IAM decides what they may reach in general. Neither asks about the action in front of it: a correctly logged-in agent with the right role can still stack discounts below cost. Authority answers for this action, now — and consumes your identity layer as an input rather than replacing it.

Decionis vs identity and access management

Not model guardrails

Guardrails shape what a model says — filtering prompts and outputs inside the AI layer. They do not decide whether the resulting action may execute, and an agent can reach the same tool from outside them. Authority sits on the action, whatever produced it.

Decionis vs model guardrails

Not a policy engine

Policy engines evaluate rules when something asks them to, then hand the answer back. Execution authority owns the moment itself: the action cannot proceed without it, a person is pulled in when the rules require one, and what was permitted is signed.

Decionis vs Open Policy Agent

Not a governance dashboard

GRC suites organize programs, policies, and evidence for people to review. They sit beside the work. Authority sits inside it — nothing reaches execution without passing through.

Decionis vs GRC suites

Not alerting

Alerting tells you what already happened. By the time the alert fires, the agent bought it and the money moved. Authority changes the outcome, not the report.

Decionis vs alerting tools

Not a runtime sandbox

Isolation limits how much damage code can do while it runs. That bounds the blast radius; it does not decide whether the action should happen, or who approved it. The two compose — authority comes first.

Decionis vs runtime layers

Seven questions, one control stack.

Every layer below is real, and every one you already run stays. They answer different questions and pass evidence forward without becoming the authority decision.

Identity

Who is acting?

Access (IAM)

What may they reach, in general?

Semantic security

What risk or intent signals were observed?

Execution authority

May this specific action execute, now, and under whose approval?

Human authority

Did the required person approve this exact action?

Execution

What did the downstream system commit?

Verifiable evidence

Can an independent verifier prove the chain?

Access is not authority. Intent detection is not authority. Approval is not authority until it is bound to execution. The resulting evidence chain is reproducible in the execution-authority evidence example.

Where Decionis gives you execution authority.

For AI agents

Agents propose; Decionis authorizes. Tool calls, purchases, and deploys need permission before they run — and a person's approval when the rules say so.

For commerce

Discounts, price changes, and orders need authority before the order commits, across Shopify, WooCommerce, and the marketplaces.

For your own money

Shield gives your subscriptions and AI assistants a personal permission step — nothing spends without your yes.

Common questions

What is execution authority?

The right to act. Before a critical action runs — an agent's purchase, a payment release, an order below your margin floor — something has to decide whether it may proceed and under whose approval. Execution authority names that function, puts it in one place, and records every use of it.

Isn't this just a policy engine?

No. A policy engine answers a question when something asks it. Execution authority owns the moment: the action cannot proceed without it, a human is brought in when the rules require one, and what was permitted is signed so it can be checked later. Teams often run both — rules in a policy engine, authority at the point of execution.

Where does the human fit?

Exactly where the rules say, and nowhere else. Clear cases proceed instantly, which is what keeps systems fast. When policy calls for a person, the action is held and routed to someone with the authority to decide, and their approval is bound to that specific action. Where the rules demand that the approver be shown to be present — not merely logged in — Presence binds the approval to a passkey ceremony on the approver's own device.

Who needs it?

Anyone whose systems act faster than their approvals: teams handing agents real tools and real cards, stores whose pricing automations reach checkout directly, finance ops with payment jobs, and consumers whose assistants can spend for them.

Do we have to write our decisions down for this to work?

No, and that is the point. Approaches that depend on someone maintaining a decision log reliably decay within weeks, because the cost falls on the person making the decision and the benefit lands on someone else later. Decionis writes the record as a side effect of authorizing the action, so a month of running the gate leaves you a decision record nobody had to maintain.

Isn't a rules file — AGENTS.md, CLAUDE.md, .cursorrules — enough?

Those supply context and hope the model follows it. Anthropic's own documentation says Claude treats memory files as "context, not enforced configuration", and that if two rules contradict each other it "may pick one arbitrarily". Execution authority is the other half of that sentence: a deterministic check the action cannot route around, and a signed record of what was permitted.

How is an exercise of authority proven afterwards?

Something always decides — usually a person reading a document, sometimes nothing at all. Execution authority names that function explicitly and puts it in one place, so the answer is deterministic, carries a named approver when policy requires one, and is recorded rather than reconstructed.

Loading…

The category

Execution Authority

Start free

Three boxes, not two

Identity proves who. Guardrails judge content. Authority decides the action.

Most teams evaluate with two categories in mind and assume the action is covered. The third box answers a question neither of the others asks — and it treats both of them as inputs.

Necessary. Not sufficient.

Identity and access

Who is acting, and what may it reach?

What it answers: Authenticates the person or the agent, issues and rotates its credentials, and decides what it may reach in general — roles, scopes, tokens, and the delegation chain from a human to the agent acting for them.
What it cannot answer: Whether the action in front of it should happen. A correctly logged-in agent with the right role can still stack discounts below cost, and a valid token can still spend past the budget it was granted under.
What it hands to Decionis: The principal, its delegation and its scopes — the inputs the authority check reads, from the identity layer you already run. Nothing here is replaced.

Examples: Okta · Microsoft Entra · Auth0 · WorkOS

Decionis vs identity and access management

Necessary. Not sufficient.

Guardrails and AI security

Is this input or output unsafe, hostile, or out of policy?

What it answers: Filters prompts and responses, detects injection, leakage and anomalous behaviour, and scores the risk of what a model is about to say or has just said — inside the AI layer, in real time.
What it cannot answer: Whether the resulting action may execute, or who approved it. An agent can reach the same tool from outside the guardrail, and a perfectly clean output can still be a purchase nobody authorised.
What it hands to Decionis: Risk and intent signals, as evidence inside the evaluation. A guardrail verdict is a fact the policy reads; it is not the decision, and it leaves no record a counterparty can check.

Examples: Guardrails AI · Check Point (Lakera) · F5 AI Guardrails · Amazon Bedrock Guardrails · NVIDIA NeMo Guardrails

Decionis vs model guardrails

The third box

Execution Authority

May this exact action execute, now, under whose approval — and can that be proven afterwards?

What it answers: Evaluates the proposed action against the organisation's own policy before it commits, holds it for a named person when the rules require one, and signs a record of what was permitted that someone who does not run Decionis can re-derive.
What it cannot answer: Who the actor is, or whether a prompt was hostile — it consumes both from the boxes beside it. It is the organisation's instrument for the organisation's policy, not an arbiter between the organisation and its counterparties.
What it hands on: A signed Decision Dossier and an execution grant bound to the exact action — what the downstream system executes, and what an auditor, a bank or a buyer verifies against a published key.

Decionis

The category, in full

Identity and guardrails are inputs to authority, not rivals to it. Decionis sits above your identity layer and beside your guardrails — not instead of either.

The map folds the seven-layer control stack into three questions. One layer belongs to no box: execution itself — the downstream system’s commit — is what all three exist to govern.

The map on one page, to print or send →

Three properties make it authority.

It binds the exact action

Authority covers one canonical payload, target, actor, policy state, signal state, and commit window. A changed action needs a new decision.

A person's approval travels with the action

When the rules say a human decides, that approval is bound to the specific action and carried into execution — not left in a chat thread for someone to reconstruct later.

Every answer leaves proof

Why this holds

Your decision record writes itself.

Nobody has to remember

The record is a byproduct of authorizing the action, not a separate task someone owes you at the end of the week.

It cannot go stale

It describes what was actually permitted, when, and under whose approval — not what someone intended to write down afterwards.

Anyone can check it

Each entry is signed, so an auditor, a bank, or a buyer verifies it against a published key instead of taking your word for it.

Evaluated outside the system it governs

Independent, in two specific senses.

The architectural claim

Independent of the system it governs

The evidential claim

Independently verifiable

Independently checkable

Verify it with our service switched off.

Step 1
Download the evidence
The Decision Dossier corpus — v0.1.3, Apache-2.0, archived with a DOI — is a set of signed dossiers with their inputs snapshot, execution binding and JSON-LD, plus the negative cases a verifier must refuse. The signing key is published on purpose, so you can regenerate the corpus instead of trusting the fixtures.
DOI 10.5281/zenodo.22312956
Step 2
Leave Decionis out of the loop
@decionis/verify is an open verifier that runs from two local files: the dossier and the key set. It recomputes the RFC 8785 canonical form, checks the Ed25519 signature and the execution-binding and dossier digests, and refuses anything altered. Disconnect if you like; it needs nothing from us.
@decionis/verify@0.2.0
Step 3
Verify the decision
The corpus proves the verifier behaves correctly, including when it should refuse. It does not prove that a production dossier verifies — that needs a real dossier and the live JWKS, and the repository documents that check separately rather than shipping a production artifact it should not have. The technical note walks through both halves, including the live key set a production dossier is checked against.
Verify a Decision Dossier without an account

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

For a regulated institution this is the test that matters: evidence that remains checkable by a party who does not trust the operator, and that stays checkable if the operator disappears.

Verify a dossier on this site Corpus on GitHub Production signing keys (JWKS)

What execution authority is not.

The adjacent categories are real and useful — they answer different questions, and Decionis is none of them.

Not an identity system

Decionis vs identity and access management

Not model guardrails

Decionis vs model guardrails

Not a policy engine

Decionis vs Open Policy Agent

Not a governance dashboard

GRC suites organize programs, policies, and evidence for people to review. They sit beside the work. Authority sits inside it — nothing reaches execution without passing through.

Decionis vs GRC suites

Not alerting

Alerting tells you what already happened. By the time the alert fires, the agent bought it and the money moved. Authority changes the outcome, not the report.

Decionis vs alerting tools

Not a runtime sandbox

Decionis vs runtime layers

Seven questions, one control stack.

Every layer below is real, and every one you already run stays. They answer different questions and pass evidence forward without becoming the authority decision.

Identity

Who is acting?

Access (IAM)

What may they reach, in general?

Semantic security

What risk or intent signals were observed?

Execution authority

May this specific action execute, now, and under whose approval?

Human authority

Did the required person approve this exact action?

Execution

What did the downstream system commit?

Verifiable evidence

Can an independent verifier prove the chain?

Where Decionis gives you execution authority.

For AI agents

Agents propose; Decionis authorizes. Tool calls, purchases, and deploys need permission before they run — and a person's approval when the rules say so.

For commerce

Discounts, price changes, and orders need authority before the order commits, across Shopify, WooCommerce, and the marketplaces.

For your own money

Shield gives your subscriptions and AI assistants a personal permission step — nothing spends without your yes.

Common questions

What is execution authority?

Isn't this just a policy engine?

Where does the human fit?

Who needs it?

Do we have to write our decisions down for this to work?

Isn't a rules file — AGENTS.md, CLAUDE.md, .cursorrules — enough?

How is an exercise of authority proven afterwards?