Agent-Safe Pipeline lets agents propose actions but never authorize them

Agent-Safe Pipeline is a reference implementation of one rule: an AI agent may propose an action, and something else decides whether it is allowed. The repository is Apache-2.0 licensed, was created on 13 August 2026, was last pushed on 4 September 2026, and holds 533 stars and 56 forks.

The flow it implements has four stages. The agent's proposal is captured as an immutable intent and hashed. A separate service called Decionis evaluates that intent and returns one of three verdicts: ALLOW, ESCALATE, or BLOCK. An ESCALATE goes to a human, whose approval is bound to that exact hash and then re-checked. Only then does a component called SafeExecutor consume a single-use grant and call the real API.

What the agent is not allowed to hold

The strictest part of the design is what it takes away from the agent. The project states that agents "must not determine whether their own actions are authorized, possess downstream privileged credentials, or choose which trusted handler runs." Downstream credentials sit behind the executor, so the agent never has the key. A sealed action registry maps action names to trusted handlers, so the agent cannot hand over an arbitrary callback and have it run. Tenant, actor, and target come from trusted runtime configuration rather than from anything the model produced.

Failures are meant to stop the action rather than let it through. The listed invariants say that network errors, malformed responses, missing grants, and binding mismatches all fail closed, and that the grant is consumed atomically before the handler runs.

The threat model states its own gaps

The repository includes a threat model that names each attack and, in a third column, the risk that remains. Against a prompt injection telling the agent to ignore policy, the control is that the check runs outside the prompt and decides independently, and the stated residual risk is that "a developer can still bypass the architecture." Against an agent calling the provider directly, the control is that the credential and network egress are held by the executor, and the residual risk is that "network policy must actually prevent agent egress." It says plainly that compromise of the trusted executor host is outside what the library can prevent.

Five example agents are included, covering Shopify refunds, GitHub deployments, procurement, a basic block flow, and a stdio MCP server with one governed tool. The package is published on npm, and the project describes itself as a library and reference implementation rather than a hosted authorization service.

The residual risk column is the honest part

Most teams giving an agent write access solve authorization inside the prompt: a rule in the system message, a checklist, a tool description asking the model to confirm first. Every one of those lives in the same text the attacker is writing into. Moving the decision to a service the agent cannot reach is a different kind of control, and it is the one that still works when the agent is wrong.

The honest part of this repository is the residual-risk column. A project that only listed its controls would tell you nothing about where it fails. This one says the network policy has to be real and the developer can still bypass it, which is the sentence a team should read before assuming the architecture alone is the protection.

Source

decionis/agent-safe-pipeline on GitHub