Agent-Safe Pipeline: an authorization boundary for agents that propose but cannot permit

The split between proposing an action and being allowed to perform it

Most agent frameworks treat the model's output as the decision. The agent calls a tool, the tool runs, and any authorization logic sits somewhere in the same process holding the same credentials. Agent-Safe Pipeline inverts that. The README states the rule directly: agents can reason, plan, and propose actions, but they must not determine whether their own actions are authorized, possess downstream privileged credentials, or choose which trusted handler runs. The project is aimed at teams building agents that touch money movement, deployments, refunds, procurement, or any MCP tool with real side effects. The audience is narrow on purpose. If your agent only reads data, the boundary described here adds ceremony without much benefit. If your agent can move USD 250,000, the repository's golden adversarial demo is written for exactly that scenario, with a remote Chief Risk Officer completing a FIDO2 plus liveness ceremony and one wire executing.

Intent capture, an independent verdict, and a grant that can only be spent once

The data flow in the README is short: agent to immutable intent, to Decionis, to ALLOW, ESCALATE or BLOCK, to SafeExecutor, to the API. Two things make that flow more than a diagram. First, the executor accepts a captured intent and a decision, and it does not accept an arbitrary callback from the agent. That is the structural difference from a middleware wrapper: there is no code path where the agent hands the executor a function to run. Second, a sealed ActionRegistry maps action names to trusted handlers and validates parameters before consuming a single-use grant. The grant is intent-bound, meaning it is tied to the captured intent rather than to a session or a user. The adversarial demo enumerates the failure modes this design is meant to catch: injected authorization fields, a fabricated ALLOW, an asserted approval, a swapped receipt, a post-approval amount change, a replayed grant, 25 concurrent claims, a shadow observation, and an expired grant. The demo exits 0 only when all eight attacks fail to execute. That exit code is the most useful artifact in the repository, because it turns a set of safety claims into something a CI job can check.

Getting the demo running and where the credentials live

The five-minute demo needs Node.js 22.14 or later and pnpm 9. The README gives the commands: clone the repository, run pnpm install --frozen-lockfile, then pnpm --filter @decionis/agent-safe-example-basic demo. The golden adversarial demo is a separate filter target, pnpm --filter @decionis/agent-safe-example-golden-adversarial demo, and it runs offline in a few seconds according to the README. The API shape in the README is three calls: intentCapture.capture(agentProposal, trustedContext), then gate.evaluate(captured), then executor.run(captured, decision). Production configuration is two environment variables, DECIONIS_API_URL and DECIONIS_API_KEY, and the README is explicit that they belong only in the trusted executor process and never in the agent runtime. The demos use what the README calls an explicitly non-production fixture authority, created by createFixtureAuthorityPair, which refuses NODE_ENV=production. A production integration switches to DecionisGate and DecionisGrantVerifier with server-side credentials. The three stages share the same IntentCapture, ActionRegistry, and handler code, so the wiring you write for the fixture is the wiring you keep.

Shadow mode is the honest part of the rollout story

The stage table lists Development, Shadow, and Enforcement. Shadow runs a ShadowPipeline over DecionisGate with mode set to SHADOW, and the stated purpose is to show what Decionis would have decided about actions that already run. No grant is ever issued in that mode. This matters because it separates two questions that teams usually answer at the same time and get wrong together: is the policy correct, and is the enforcement wiring correct. Shadow mode answers the first without risking the second. The repository also splits approval handling into two shapes. The presence-live-approval example binds enforcement to the real services with a FIDO2 or FIDO2-plus-liveness ceremony and needs real credentials. The presence-managed-approval example uses Decionis-managed Presence orchestration with Decionis-only polling and no Presence credential in the executor. Those are different operational postures, not cosmetic variants, and the choice affects who holds what secret.

What the repository is not, and where the boundary breaks

The README is unusually direct about scope. This is a library and runnable reference implementation, not a hosted authorization service, and not a substitute for provider-side identity, least privilege, network isolation, and incident response. The safety claims apply only when the documented trust boundary is preserved. That last clause is the real constraint. If the agent process can reach DECIONIS_API_KEY, or if the agent can register its own handler in the ActionRegistry, or if the executor and the agent share a process where the agent can call executor.run with a decision object it constructed itself, the guarantees described above do not hold. The fixture authority is a development convenience that refuses production, which means you cannot accidentally ship it, but it also means the demo does not exercise the real Decionis service. The commerce-mcp package is a client adapter over the published Decionis contract and, per the repository map, holds no policy and contains no marketplace client. Teams expecting policy logic inside that package will not find it.

How this differs from putting policy in an OPA sidecar or a gateway

The closest conventional alternative is a policy engine such as Open Policy Agent deployed as a sidecar, with the agent calling the engine before each tool invocation. The difference is where the enforcement point lives. An OPA sidecar returns a decision to the caller, and the caller is the agent process, so the agent remains the component that decides whether to honour the answer. Agent-Safe Pipeline moves the decision out of the agent's reach by making the executor the only component that can consume a grant, and by binding that grant to a specific captured intent. A second alternative is an API gateway doing authorization at the network edge. Gateways see HTTP requests, not agent intent, so they cannot bind an approval to the exact parameters that were approved. The post-approval amount change attack in the golden demo is the case that separates the two approaches: a gateway sees a valid request from an authenticated caller, while an intent-bound grant sees that the approved amount no longer matches the proposed one.

Version history, licence, and what maintenance looks like

The repository is at v0.1.3, released 2026-09-04, with two release candidates in the preceding weeks. That is a young version line, and the README links to a package README and several docs files for the complete enforcement example, shadow rollout, presence evidence, and the remote CRO walkthrough, which suggests the documentation is still being filled in around the code. The licence is Apache-2.0, which permits commercial use, modification, and redistribution provided you keep the licence and notice files and state significant changes; it also includes a patent grant. This is not legal advice, and the licence covers the reference implementation only, not the Decionis service you would call in the enforcement stage, which is governed by whatever terms apply to that service. The maintenance cost that matters here is operational rather than dependency-related: you are adding a network call to an external authority on the path of every governed action, and you are adding a human approval step for anything that returns ESCALATE. The ESCALATE path is where your latency budget and your on-call rotation will actually feel this design.

Editorial conclusion

Adopt Agent-Safe Pipeline if you already accept that an agent must never hold downstream credentials or choose its own handler, and you want the wiring for that claim in TypeScript rather than a design document. Do not adopt it if you need a hosted authorization service or a drop-in middleware layer: the repository is a library and reference implementation, and the demos run against a fixture authority that refuses NODE_ENV=production. Before committing, verify three things: that your agent runtime and your executor process can be separated so DECIONIS_API_KEY never reaches the agent, that you can run pnpm --filter @decionis/agent-safe-example-golden-adversarial demo green in your environment, and that the ShadowPipeline mode is available to you so you can observe what Decionis would have decided about actions that already run before you enforce anything.

Official sources

1. decionis/agent-safe-pipeline on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases