Can it pay?
Should this payment proceed now?
Execution control for autonomous systems
Sentinel stops an AI agent from treating access as permission by checking authority before a real action is allowed to proceed.
Built for teams giving AI agents or autonomous software consequential access to infrastructure, data, money, devices, or production systems.
Sentinel checks identity, authority and policy before a consequential action executes.
The control gap
Being able to call a tool does not mean the action should run. Sentinel asks the authorization question at execution time. Review the validated governance controls or follow the developer API path.
Should this payment proceed now?
Is this change authorized for this host?
Is this export in scope?
How it works
A Sentinel response alone is not proof of enforcement. The claim applies to the specific execution path placed behind the Sentinel boundary.
Proof before promises
The site grows by adding verified rows, not by adding claims. Every row carries a status, a boundary and an artifact.
| Path | Status | What was shown | Boundary | Artifact |
|---|---|---|---|---|
| Signed health-read decision | Tested | Verified REVIEW response; timeout denial recorded later. | Decision handling only. No downstream action executed. | Inspect artifact ↗ |
| Codex EET-1 · write_file | Tested | Execution log reports a 72-byte write; observer record matches target and time. | First-party file-write records. Raw permit signature not included. | Inspect EET-1 record ↗ Consistency checked; verification limits disclosed. |
| ESP32 farm control | Implemented | Actuator command placed behind the boundary. | Integrated prototype controller only; not a customer deployment. | Demo ↗ |
| CLARA · run_model |
Reference
Shadow
|
Design partner reference integration: Sentinel evaluated and recorded proposed actions; execution was not blocked. | Shadow governance only; not a customer deployment. | Case note ↗ |
| ROKO testnet · 100 ROKO validator bond | Tested | A user-authorized 100 ROKO validator-bonding transaction was confirmed on the live ROKO testnet. Sentinel subsequently located the transaction in read-only mode, generated canonical transaction and observation digests, and preserved linked temporal and audit-chain evidence. | Internal validation using a third-party testnet. Sentinel did not sign, broadcast, stake, transfer tokens, or connect to the wallet. Transaction verification only; not Sentinel enforcement evidence. | Inspect ROKO evidence ↗ |
| RC3 native execution fixture | Finding preserved · retest pending | 354/354 mediated reference checks passed. A later native-path test found state-changing paths outside the permit-verifying executor. | This row records the finding that triggered runtime-boundary hardening. It is not a post-hardening PASS. | Read case study ↗ Post-hardening native-path retest: not yet published. |
| Post-hardening native-path retest | Not yet published | No post-hardening PASS is claimed on this page. | A validated result will be promoted here only after a bounded retest produces a publishable artifact. | Pending validation artifact |
| Cross-assistant fintech authority | Tested — behavioral | Claude, Manus, and ChatGPT sessions exercised exact grants against disposable fintech tooling. Authorized actions executed and were verified; replay and scope-drift requests were not executed. | Assistant-side behavioral authority handling only. No hard host enforcement, native-tool interception, real financial system, or production customer deployment was demonstrated. | Read case study → |
Evidence status: Technical validation and bounded findings are published where artifacts exist. Public customer references and named external security assessments are not claimed here until they are publishable. No customer logo, audit vendor, or post-hardening PASS should be inferred from the absence of a published artifact.
Tested: evaluated within the stated scope. Implemented: a working integration.
Reference: a documented integration. Shadow: decisions recorded without blocking execution.
Who Sentinel is for
Sentinel is for organizations moving AI from answering questions to changing real systems. Use it when an agent can deploy code, alter infrastructure, access or move sensitive data, trigger financial operations, or control devices.
For a buyer, the question is simple: what is this agent allowed to do, who approved that authority, and can we prove what happened later? Sentinel sits before the side effect so that authority can be checked before execution.
Security, risk, compliance, operations, and engineering teams can review the boundary in plain language here. The API and implementation details follow below for developers.
Developers
Send the proposed action through /analyze. Sentinel evaluates identity, authority and policy, then returns a signed governance decision for the protected path to consume.
# request excerpt { "agent_id": "deploy-bot-7", "command": "{\"type\":\"restart_service\",\"target\":\"redis\"}" } # response excerpt { "decision": "review", "risk": "high", "risk_score": 0.90, "action_digest": "…", "replay_id": "…" }
Inside Sentinel

Founding Integration Pilot · Applications open
Name the agent or automation, the consequential action it already takes, the target system, and the exact point where Sentinel can sit before execution. Applications are reviewed before acceptance.
Pricing at a glance: Developer: Free · Startup: $199/month · Business: $999/month · Enterprise packages: $50k–$150k/year. View pricing →