The AI is not the security boundary

BeaconGuard assumes an AI or agent can be wrong, manipulated, compromised, or simply outside the authority required for a consequential action. The model's output is treated as a proposal—not permission to execute.

BeaconGuard security model showing an untrusted AI or agent proposal entering an independent exact-action authorization boundary. Validated identity, bounded delegation, and governing policy constrain the decision. ALLOW issues one-time execution authority, DENY issues none, and authorization evidence records the action, governing authority, and outcome.
The model or agent is never the final authority. BeaconGuard independently authorizes the exact action, fails closed, and separates execution authority from broad access permission.

Four security properties

Access is not action authority

Identity, delegation, and tool access establish context and reachability. The specific consequential action is authorized separately.

Authorization is exact-action bound

If the action changes after ALLOW, execution-side recomputation detects the mismatch and refuses execution.

Execution authority is single-use

ALLOW can issue one-time authority bound to the exact action. Reuse, replay, expiry, or revocation fails closed.

No silent bypass

Deployment and executor design must keep BeaconGuard on path and reject missing or invalid action authority.

Trust is explicit

Production authorization depends on validated identity and delegation context, verified governing policy authority, exact-action binding, replay state, and an executor that enforces the grant contract. Missing or unverifiable required state does not fall back to permissive execution.

Security boundaries BeaconGuard does not replace

BeaconGuard does not claim to make a compromised operating system trustworthy, make the model correct, or replace IAM, API gateways, MCP/A2A platforms, SIEM, or GRC systems.

Technical security review