Human authority

Proof-of-human infrastructure for Execution Authority

The check placed at the point where trust becomes irreversible: a verified, present person on their own device, bound to this exact action, sealed in a record you can verify without us.

Decionis decides whether the action may execute. When policy says a person must decide, Presence — the adaptive human verification layer — verifies that the authorized person is really present on their own device, and seals a signed Presence Record that Decionis re-checks before the action commits.

Presence - adaptive human verification layer. Presence evaluates behavior, device trust and liveness, stepping up verification only when needed before sensitive actions execute.

Run a presence check Talk to us about production

The demo needs no signup. Production enforcement is sales-assisted.

Four controls, and only one of them checks the person

Every team already runs the first three. The gap is not a missing control — it is a question nobody asks before the irreversible step.

Identity

Which credential was presented?

Your identity provider proves a password, an SSO session or a passkey was used. It says nothing about who is participating in this action right now.

Approval workflow

Did an account click approve?

Your ticketing or chat approval records that an account accepted the step. A stolen session, a forwarded link or a synthetic voice on the call clicks the same button.

Detection

Does the recording look synthetic?

Post-event scoring tells you what happened after the payment has moved. It is an incident report, not a control.

Presence and Decionis

Is the authorized person really present, on their own device, for this exact action?

A Presence Check seals a signed Presence Record — approver identity, role, action digests, expiry — and Decionis re-checks it before the action commits.

The dossier's execution binding carries a verifiable reference to the Presence Record, re-checked before the action commits. A Presence approval is not a transferable human ALLOW: it resolves one held action, once, and an earlier approval cannot be presented to execute the next one.

Three patterns to put a person in front of first

Every chain is an ESCALATE, because that is what proof-of-human infrastructure resolves — or leaves held. It is not a fourth verdict.

An agent's step handed to a person

Human Approval Gatevendor.payment

A procurement agent moves to pay a vendor above the authority delegated to it. Policy says a named person must decide — and the approval has to come from that person, not from whichever session holds their credential.

Policy: Payment above delegated authority requires a verified, present approver on their own device; the approval carries this payment's binding digest and resolves only this action.

Procurement agent
vendor.payment
Identity ✓ · access ✓ · signals ✓
Decionis
ESCALATE
Presence Check → signed Presence Record
Decionis re-evaluates
ExecutionBinding to this payment

A privileged access grant

Adaptive Step-Upaccess.grant

A help-desk flow is about to grant an administrator role after a convincing call. The reset path trusts a voice; the grant is the consequential step.

Policy: A privilege grant requires Adaptive Step-Up for the operator authorizing it — device proof and liveness before the change applies — and the sealed Presence Record is re-checked before commit.

Help-desk operator
access.grant admin
Identity ✓ · ticket ✓
Decionis
ESCALATE
Adaptive Step-Up on the operator's own device
Decionis re-evaluates
ExecutionBinding to this grant

A payroll run after a bank-detail change

Human Approval Gatepayroll.run

Payroll diversion is a bank-detail change with a payday deadline. The run is scheduled; the change landed yesterday; nobody has yet been asked whether a person really made it.

Policy: A payroll run that follows an unverified bank-detail change requires a verified payroll authority before the run — and if no Presence Record arrives, the run stays held.

Payroll system
payroll.run
Identity ✓ · change detected
Decionis
ESCALATE
No Presence Record
Stays held — no execution grant

When the verdict is ESCALATE, resolve it with a verified human

What runs today, and what does not.

Runs over the MCP today

decionis.request_presence_verification and decionis.get_presence_verification_status run against a held ESCALATE. They cannot bypass a BLOCK, they refuse Shadow Mode evaluations, and the action stays held until a new Decionis verdict returns PROCEED.

Runs on the Presence property today

The demo runs the real engine with no signup and hands you the signed Presence Record it seals; the sandbox runs deterministic allow, block and escalate fixtures in Shadow Mode. You wire the ceremony — a Presence Check requires local device authentication before a hardware-key signature — and Decionis verifies the Record.

The asynchronous loop

The asynchronous authority loop runs as a managed escalation: on an ESCALATE with escalation.mode MANAGED, Decionis requests the Presence Check itself, the integration subscribes to the managed_escalation.* and authority.escalation_resolved events or polls the status, and the grant is minted when the ceremony verifies. The managed mode is chosen per evaluation, and production enforcement is sales-assisted. Nothing beyond that is claimed, because nothing beyond that is built.

Stated plainly, so the integration you plan is the integration that exists. The MCP surface itself is documented at the MCP server docs, and Presence appears as a named rollout component on the fintech lane.

Where this is written down and built in the open: Presence's own site names the category Human Presence Infrastructure and publishes its machine summary at presence.decionis.com/llms.txt. Its posture today: live demo and sandbox; production enforcement sales-assisted. The demo runs the real engine; the sandbox runs deterministic fixtures in Shadow Mode; the quickstart and API reference are where an integration starts, and @decionis/presence-mcp gives an MCP client the same operations.

Check it rather than believe it: every Presence Record is Ed25519-signed and verifies offline against published signing keys; the evidence index lists every artifact a skeptic can fetch, run or reproduce; and the shadow-mode methodology says why a watch-only verdict is still a measurement. On the Decionis side, Presence Evidence semantics in the open reference implementation says what a Presence Record establishes at the execution boundary, and the evidence index says which control belongs to which layer. Human authority bound to the action: a verified person resolves an ESCALATE, and the approval carries the action's binding digest.

Presence before privilege.

Start in watch-only on the Presence property, measure what would have been challenged, then enforce on the band of actions that justify the friction. Production enforcement is sales-assisted.

Start Now Talk to us about production