Decionis
Start Now

Execution pattern

Privileged access grant

Grant the narrowest scope that works, and expire it.

Run a live decision — no account
Category
IdentityCommon in SaaS & platforms · Fintech & payments · Healthcare · Public sector
Works through
sdk · servicenow · workday
Proof
Signed Decision DossierVerifiable against our published JWKS.
Deploy
Shadow Mode firstMeasure on your own traffic before anything is stopped.

What executes

An access request grants elevated or root scope to a person, contractor, or service.

What normally goes wrong

Access is granted broadly because narrow is slow, and revocation depends on someone remembering. Standing privilege accumulates until it is the incident.

The decision

The signals available at the moment of the action, and the rule that judges them.

Signals

  • Scope requested versus scope needed
  • Duration and whether expiry is set
  • Employment or contract status
  • Whether the approver is independent of the requester

The gate

Refuse standing privilege where just-in-time access would serve, and refuse any grant without an expiry.

ALLOW

Access is granted, scoped and time-boxed.

ESCALATE

A broad or long-lived request waits on the resource owner.

BLOCK

The grant does not happen — for example root scope to a contractor.

The Protocol — Deterministic. Contextual. Explainable.Four stages left to right. Input signals — user or agent identity, context and data, tools and resources, spend and budget, policies, history and reputation, and environment — enter the Decionis Protocol. Inside, the protocol normalizes context and intent, evaluates policies and rules, runs a deterministic risk and policy engine, and explains the reason and evidence. It emits a verdict: ALLOW (authorized), ESCALATE (needs approval or more info), or BLOCK (high risk or out of policy). The verdict drives an enforcement action: allow, block, require approval, or throttle and limit. Every decision is recorded for audit, learning, and continuous improvement.INPUT SIGNALSUser / Agent IdentityContext & DataTools / ResourcesSpend / BudgetPoliciesHistory & ReputationEnvironmentDECIONIS PROTOCOLNormalizeContext & IntentEvaluatePolicies & RulesRisk & Policy Engine(Deterministic)ExplainReason & EvidenceVERDICTALLOWAuthorizedESCALATENeeds approvalor more infoBLOCKHigh risk orout of policyACTIONSAllowBlockRequire ApprovalThrottle / Limit
Four stages left to right. Input signals — user or agent identity, context and data, tools and resources, spend and budget, policies, history and reputation, and environment — enter the Decionis Protocol. Inside, the protocol normalizes context and intent, evaluates policies and rules, runs a deterministic risk and policy engine, and explains the reason and evidence. It emits a verdict: ALLOW (authorized), ESCALATE (needs approval or more info), or BLOCK (high risk or out of policy). The verdict drives an enforcement action: allow, block, require approval, or throttle and limit. Every decision is recorded for audit, learning, and continuous improvement.

The policy pack that decides this pattern

The bundles the Decionis evaluator ships, with every rule in the order it is tried.

Workday HR Governance

Dual-gate governance for Workday HCM business processes — state admission (completeness, effective date, worker status, termination reason, compensation structure) and execution authority (authorized role, segregation of duties, compensation thresholds, pay-equity review, offboarding coordination, works-council consultation) before they execute.

workday · workday-hr-governance-v1 · 14 rules

Every policy pack the evaluator ships

Prove it, then deploy it

A verdict you cannot check is an opinion, and a gate you cannot measure first is a risk of its own.

View the signed proof

Every verdict on this pattern produces a Decision Dossier: the signals it saw, the policy version that judged them, and an Ed25519 signature anyone can check against our published JWKS — without an account, and without trusting us.

See an example dossierVerify one yourself

Deploy in Shadow Mode

Run this gate against your own traffic while it stops nothing. You get the verdicts it would have returned and the actions it would have held, so the decision to enforce is made on your numbers rather than ours.

How Shadow Mode worksTry the scenario first

Related patterns

Teams that hit this one usually hit these next.

Payroll and HR process release

Check the run before it commits, not in the reconciliation.

Prevent destructive production changes

Make deleting production a decision, not a command.

Procurement approval

Check delegated authority before the purchase order posts.

Related concepts

This pattern is one answer to each of these.

Agent Permissions

How do I decide what an AI agent is permitted to do?

Execution Governance

How do I govern execution across systems without rebuilding controls in each?

AI Approval

How do I require human approval before an AI agent acts?

Agent Permission Scope

Why did the agent have permission to do that?

What to do next

The same five steps for every pattern in the library.

  1. Simulate this recipe

    Run the policy against a realistic action in the browser. Push it past what the rules allow and watch the verdict come back. No account.

  2. View the signed Decision Dossier

    See exactly what was decided and why: the rule that fired, the evidence it read, the policy version in force, and an Ed25519 signature you can verify yourself.

  3. Deploy in shadow mode

    Measure what the policy would have caught on your own traffic without touching the live path. Every recipe defaults to shadow, so the first deployment carries no execution risk.

  4. Connect a real workflow

    Point the same policy at the system where the action actually originates — a checkout, an ERP posting, a Zap, an agent's tool call.

  5. Share the verified result

    Publish the proof: a public verification link, an embeddable badge, a PR comment, or an anonymized shadow-mode finding. This is how the next person discovers Decionis.

← All execution patterns