How it works

Every payment, change or API call is decided before it commits.

Your agent or system proposes an action. Your policy decides whether it runs, waits for the person you name, or stops. You get a single-use permit and a signed record for that exact action, and the same action against the same policy always gets the same answer.

What is Execution Authority?

Execution Authority answers one question before an action commits: may this exact action run now, under your policy and the approvals it requires? Your identity system proves who is acting and your guardrails judge content and risk. Execution Authority decides whether the resulting payment, change or API call may commit, and leaves a signed record you can verify.

Your policy decides on the exact action, as it stands now.
Any approval it requires is bound to that one action.
A single-use permit is checked before the action commits.
You keep signed evidence of the decision and what happened.

Inspect the authorization and execution sequence

Your identity system, guardrails and downstream application retain their existing responsibilities.

Where the check sits

At the point where the action would commit, in the system that runs it. Your systems keep running the actions.

AgentSafe · Production

In front of your agents' API calls

The gateway checks every write before it is sent. It goes through once, waits for your approval, or is refused.

Commerce Gate · Production

At checkout and on marketplace orders

Walmart, Shopify, WooCommerce and Adobe Commerce: the discount, order or refund that breaks your margin rules is stopped or held.

Govern · Production

Before a deploy reaches production

The GitHub Action checks the change in your pipeline, in shadow first, before it merges or ships.

API and MCP server · Production

Inside your own code

One call before the action you want protected. Your code runs it only on an allow, and keeps the signed record.

Business Central · Private beta

Before a payment posts

A permit bound to the exact payment line, so an approval can't be moved to another vendor or amount.

Every integration and its status: Integrations.

What happens in one decision

Every decision is recorded for audit, learning, and continuous improvement.

Stage 1

Signals

The proposed action plus the evidence around it — actor, amount, counterparty, cost basis, inventory, prior decisions — normalized into one contract regardless of which surface it arrived from.

Stage 2

Policy

The rules in force at that instant, resolved from the policy graph and pinned by version, bundle hash and effective window so the decision is reproducible later.

Stage 3

Verdict

A deterministic ALLOW, ESCALATE or BLOCK — the same signals against the same policy always produce the same verdict.

Stage 4

Action

Execution proceeds, halts, or waits on an approver, and the signed Decision Dossier is written to the ledger either way.

Three answers

The answer is the judgement. What happens next depends on where the check sits: the same answer holds a checkout, an ERP posting or an agent's tool call in the way that system allows.

ALLOW

Authorized

The action is within policy on the evidence presented. It executes, and the dossier records the authority it executed under.

ESCALATE

Needs approval or more info

The action needs authority the requester does not hold, or evidence the request did not carry. It waits for whoever can supply it. When that is a person's approval, Presence, the escalation layer built into Decionis, verifies the approver for this exact action.

BLOCK

High risk or out of policy

The action breaches policy or crosses a risk threshold. It does not execute, and the dossier records which rule stopped it and on what evidence.

What the system you connect can do with an answer

Allow
Block
Require Approval
Throttle / Limit

Three things make it authority, not advice

It covers the exact action

A decision covers one action: its target, amount, actor and the policy in force at that moment. Change the action and it needs a new decision.

Your approval travels with it

When your policy says a person decides, that approval is bound to the one action and carried into execution, not left in a chat thread.

Every answer leaves proof

Each decision is signed, so you, your auditor or your bank can check what was permitted, under which rule and whose approval.

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. You keep both: the authority check sits above your identity layer and beside your guardrails, not instead of either.

Decision intelligence determines what an AI wants to do. Execution authority determines whether it is permitted to happen. As AI gets faster and more autonomous, identity becomes a weaker proxy for authority.

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 →

Seven questions, one control stack

Every layer you already run stays. They answer different questions and pass evidence forward; none of them decides whether this action may commit.

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?

What it doesn't replace

Not an identity system

Identity proves who is acting and IAM decides what they may reach. A correctly logged-in agent with the right role can still stack discounts below cost. You keep your identity layer; it becomes an input.

Compare

Not model guardrails

Guardrails shape what a model says. They don't decide whether the resulting action may execute, and an agent can reach the same tool from outside them.

Compare

Not a policy engine

A policy engine answers when asked and hands the answer back. Here the action can't proceed without the answer, a person is pulled in when your rules require one, and the result is signed.

Compare

Not an orchestration framework

Your orchestrator runs the agent and carries the pause where a person approves. It doesn't decide whether the action needs a person, or whose approval counts.

Compare

Not alerting

An alert tells you what already happened, after the money moved. The check runs before the action commits.

Compare

Every comparison: Compare governance controls.

Your policy, drafted from your own history

You don't start from a blank page. Your own records are checked, a policy is drafted from what was found, and nothing goes live until a person you name approves it.

Walmart: Beta · Business Central: Private beta

Drafted from what happened

Your last 90 days are checked, and each limit in the draft cites the findings behind it. The same findings always give the same draft; no language model writes it.

Before anything goes live

Replayed on your own records

The draft runs against the same records, so you see which actions it would have held, allowed or stopped. Nothing is sent or executed.

Your team: Production · Managed: Private beta

Approved by a person you name

Run it with your own team, where a second person approves every change and the author never can. Or have it managed for you and give the one approval that releases it; any edit you make hands it back to your team.

Every release is signed, so you can always tell which version decided an action and who approved it. Prefer to start elsewhere? Begin from a policy pack, or write your own.

Around one decision

One decision is a single call. Around it sit the policy that was in force, the person who approved, the action that ran, and the signed record that outlives it.

Every step is observable, explainable, and auditable.

1
Detect
A high-stakes action is proposed on some surface.
2
Evaluate
Signals are gathered and checked against the policy in force.
3
Decide
A deterministic verdict is issued — allow, escalate, or block.
4
Execute
The action proceeds, waits for authority, or is stopped.
5
Record
A signed Decision Dossier preserves what was decided and why.

Want to see it refuse something? Run a live decision with no account.

Reference diagrams

The diagrams behind this page, each downloadable as SVG. Reuse them in your own architecture reviews.