Abstract

Security systems for AI agents focus on whether an action may be attempted. Meta’s Muse/Sentinel architecture, published on 8 September 2026, is a strong example: the agent runs in an isolated runtime environment, a host-side service called Sentinel approves each connector action and outbound network request, real credentials stay on the host and are inserted only after approval, and data-flow (taint) tracking sends sensitive operations to the user for confirmation.

Approval to attempt an action, however, does not prove what actually happened afterwards. A payment may be only partly completed. A confirmation message may be lost, causing the system to retry and duplicate the action. A request may be redirected to a different destination. A genuine success receipt from one action may be reused to justify a different one. Permissions may be revoked between approval and execution. These are general distributed-systems risks for any AI agent platform; Meta’s public description does not state how each connector handles them, and no flaw in Meta’s system is claimed.

This disclosure describes a method for staged, evidence-dependent execution of high-risk actions. Instead of performing a large or irreversible action in one step, the system first performs a small, bounded real action through the approved path. An independent protected observer, outside the agent’s control, produces an authenticated receipt describing what actually occurred. A validation component, the Interim Effectuation Validator, checks that receipt: that it is authentic, that it belongs to this exact action, step, destination, and execution point, that the observed result matches the expected result, that it is fresh and has not been used before, that current policy and revocation status still allow continuation, and that the action stays within its maximum approved scope. Only if every check passes does the validator, in one atomic step, consume the receipt, advance to the next step, and issue a single-use authorization that only the next execution point can use. That execution point rechecks current conditions before acting. If the receipt is missing or unclear, the system pauses and queries the authoritative system by transaction ID instead of retrying blindly, and classifies the earlier step as completed, not completed, partially completed, or still unknown. Every alternative route to the same effect, such as direct API calls, command-line tools, background jobs, admin or debug interfaces, must be closed or pass through the same check. Low-risk, reversible, or read-only actions continue as single-step operations.

The disclosure applies this method to sensitive messaging (send a small test capsule, verify the recipient, then release the decryption key), payments (authorization or hold, verified, then capture), cloud deployments (canary release, signed health telemetry, then wider rollout), and physical actuators (bounded safe movement, protected sensor reading, then expanded movement).

Contents of the PDF files: a 7-chart visual guide covering the overall architecture, the seven-element staged chain, the validator’s checks and atomic transition, reconciliation of missing or ambiguous results, ten residual-risk classes with mitigations, the evidence ladder and timing window, and four application scenarios; followed by the full 42-page research paper with threat analysis, a comparison table of documented and proposed controls, assurance profiles, a fault-injection test harness, negative test cases, privacy considerations, limitations, pseudocode, and a reviewer checklist. Patent pending: Indian Patent Office application 202631117633.

More details and downloads: https://zenodo.org/records/23730878

Keywords: AI agent security; agentic AI; Meta Muse; Meta Sentinel; staged execution; multi-phase transaction; step-wise authorization; progressive authorization; evidence-based authorization; effect verification; execution verification; delivery receipt; signed receipt; transaction receipt validation; proof of execution; post-execution verification; conditional continuation; receipt-gated workflow; Interim Effectuation Validator; protected observer; independent observer; attestation of effect; single-use token; one-time authorization; capability token; atomic commit; atomic state transition; compare-and-swap; idempotency key; duplicate transaction prevention; retry safety; lost acknowledgement; at-most-once execution; exactly-once execution; partial failure; partial commit; transaction reconciliation; reconciliation by transaction ID; replay protection; nonce; monotonic counter; revocation check; TOCTOU prevention; policy enforcement point; reference monitor; egress proxy; forward proxy; credential isolation; credential injection; surrogate credential; taint tracking; data-flow tracking; sandboxed agent runtime; tool call authorization; connector security; fail-closed; human-in-the-loop approval; canary deployment; progressive rollout; payment authorization and capture; two-phase payment; encrypted message key release; actuator safety interlock; sensor feedback control; zero trust; prior art; defensive publication

CPC: G06F 21/52 (monitoring program integrity during execution); G06F 21/53 (execution in restricted environment); G06F 21/604 (access control policy tools); G06F 21/6218 (protecting access to resources); G06F 9/466 (transaction processing); G06F 11/1474 (saving, restoring, recovering, or retrying in transactions); G06F 8/65 (software deployment, updates); H04L 63/10 (controlling access to network resources); H04L 63/0807 (authentication using tickets or tokens); H04L 9/3213 (authentication using tokens); H04L 9/3247 (digital signatures); G06Q 20/40 (payment authorization); G05B 19/4155 (numerical control characterized by programme execution); G06N 20/00 (machine learning)

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS