Sentinel is live: the independent action-gate for AI agents

Sentinel is live today

Today, Montana Labs is launching Sentinel: our independent action-gate for AI agents. Sentinel is built for the moment when an agent is no longer just drafting or suggesting, but is about to do something that matters in production. Move money. Update a record. Send a message. Trigger a workflow. Call an external system. At that boundary, teams need more than model confidence. They need an independent control point they own.

That is what Sentinel provides. The product puts a self-hosted sidecar between an agent's decision and the action itself, evaluates the proposed action against policy and systems of record, and returns one of three outcomes: ALLOW, BLOCK, or ESCALATE. Every decision creates a signed provenance record. The signing identity lives with the gate, not with the agent. And if the gate is unreachable, the SDK fails closed by default. The result is a product teams can actually use to slow down risk without shutting down automation.

Sentinel is the trust layer between your AI agents and the actions that matter.Montana Labs

What the product includes

Sentinel is going live with the core pieces platform teams need to put it into a real stack. The public docs and repository describe a self-hosted sidecar, a thin HTTP API, TypeScript and Python SDKs, a CLI for scaffolding and verification, signed provenance, and a deployable packaging story across standalone binaries and Docker. It is designed to be inserted at the action boundary rather than replace the agent framework a team is already using.

The check model is also practical. Sentinel combines fast synchronous checks like schema validation, policy rules, and data-boundary controls with slower checks such as reconciliation against systems of record, sanctions logic, predicate checks, and optional second-opinion model review. Outcomes are aggregated with a strict precedence of BLOCK over ESCALATE over ALLOW. That means teams can stop obviously unsafe actions early and only spend extra time where the decision genuinely needs deeper verification.

• Self-hosted sidecar with a separate signing identity from the agent.
• Thin SDKs for TypeScript and Python so teams can gate actions without re-architecting everything.
• CLI and deployment paths aimed at real environments, not just demos.
• Policy and connector hooks so the gate can reconcile actions against business truth, not prompt text alone.

Where Sentinel fits in a production stack

Sentinel is not trying to be another agent framework, chat wrapper, or observability-only layer. It is meant to sit in the narrower and more important place between proposal and execution. That makes it especially relevant for teams building agents that touch payments, customer operations, healthcare workflows, support actions, outbound communications, infrastructure changes, or internal tooling that can cause real damage when a wrong action gets through.

For those teams, the product story is simple: keep the agent flexible, keep the execution path governed, and keep the evidence durable. The optional adjudication protocol goes a step further by turning an ALLOW into a signed, single-use, expiring authorization receipt bound to the exact action and context. That is a strong feature for teams that need more than policy checks and want a tighter link between what was approved and what was actually executed.

1. 1An agent proposes a consequential action.
2. 2Sentinel evaluates it against policy, connectors, and optional review logic.
3. 3The gate returns ALLOW, BLOCK, or ESCALATE and signs the result.
4. 4If needed, execution can be bound to a single-use authorization receipt.
5. 5Operations and audit teams can verify later what was decided and why.

Why we built it this way

We built Sentinel this way because too many agent stacks still ask buyers to trust the same system that is making the decision to also certify the decision. That is not a comfortable position for platform teams, and it is not a serious answer for high-stakes workflows. Sentinel gives teams a separate place to own policy, verification, and auditability without throwing away the benefits of agents. It is designed to help companies move faster with automation while keeping a clear line around what is permitted, what needs review, and what should never proceed.

This launch also says something about how Montana Labs thinks about applied AI engineering. We do not believe production trust comes from nicer demos or softer language around guardrails. We believe it comes from architecture. Separate trust boundaries. Real policy evaluation. Reconciliation against systems of record. Signed evidence. Fail-safe defaults. Sentinel is our product expression of that belief, and today it is live for teams that want a more credible way to govern agent actions.

If you already have agents in testing or production, the best first use case is the workflow that currently feels one step too risky to automate end to end. That is exactly where Sentinel belongs. It is live today, and it is built for the teams that want agents to do more than assist while still keeping the action boundary under control.

• Sentinel docs
• Sentinel GitHub repository
• Sentinel README
• Get in touch with Montana Labs