Decionis
Use case · AI agent guardrails

Let the agent work. Gate what it executes.

A working recipe for putting a deterministic gate between an AI agent and its consequential actions — deploys, refunds, migrations, tool calls — with shadow mode first, human escalation built in, and a signed record of every decision.

The recipe

Three steps, shadow first

1

Name the actions that can hurt you

Not the agent's words — its executions: production deploys, database migrations, refunds and payouts, checkout mutations, permission changes. Start from the risky-action catalogue and pick the three you would least like to explain.

2

Put the gate in the loop

Agent frameworks call the decisionis gate as an MCP tool before the real tool runs; CI agents go through the govern GitHub Action; everything else calls evaluate-decision over the API. The agent proposes, the gate judges.

3

Watch in shadow, then enforce

Shadow mode evaluates every proposed action against policy without blocking anything, so you see what would have been held before you turn enforcement on — and when you do, ESCALATE routes the ambiguous cases to a person instead of guessing.

Asked directly

The questions teams bring to this page

Where does the gate actually sit for an MCP-based agent?

As a tool the agent must call before consequential tools: the hosted MCP server at protocol.decionis.com/mcp exposes decionis.evaluate_decision (org API key auth), and the @decionis/mcp package runs the same check locally over stdio for Claude Code, Codex, and Copilot hooks. The verdict comes back before the real action runs.

MCP setup

What happens when the agent proposes something ambiguous?

ESCALATE. The action is held, a person who holds the authority gets it in Slack, Microsoft Teams, or Webex, and no execution grant is issued until they approve. The agent is not trusted to resolve its own gray areas — that is the point of the gate.

Escalation and overrides

Do I have to trust the gate's own account of what happened?

No — every verdict is recorded in an Ed25519-signed Decision Dossier verifiable against a published key, without an account. When an agent-initiated change is questioned later, the dossier is the answer: what was proposed, which policy version judged it, what the verdict was, who approved it.

Verify a dossier

What should the first policy actually say?

Less than you think. The starter shape: block the irreversible (schema drops, deletes over a threshold), escalate the expensive (payouts, refunds, production deploys outside a window), allow the rest — and let shadow-mode reports tell you where the thresholds really belong before you tighten anything.

The risky-action catalogue

Is this the same thing as prompt guardrails?

No. Prompt and output filters shape what a model says; this gates what an agent does. The two compose — filter the language, gate the execution — but only one of them stops a well-phrased, wrong action from reaching production.

The governance model

Start where nothing can break

Shadow mode evaluates your agent's real actions against policy and reports what would have been held — no blocking, no workflow changes, and a signed dossier for every evaluation from day one.

Install shadow mode