THREAT MODEL
Threats are stopped at the boundary closest to the consequence
BeaconGuard assumes the AI or agent can be wrong, compromised, manipulated, or outside the authority required for a consequential action. AI reasoning, identity alone, or broad tool permission is therefore never treated as the final security boundary.
Primary threat matrix
| Threat | BeaconGuard design response |
|---|---|
| Identity or delegation confusion | Validate required provenance, bounds, tenant/environment, expiry/revocation, and fail closed when trusted context cannot be established. |
| Access permission treated as blanket action authority | Preserve the separation between invocation access and a later exact consequential-action authorization decision. |
| AI proposes an out-of-policy side effect | Treat the output as an untrusted proposal and evaluate the exact action under customer-approved governing policy. |
| Action substitution after ALLOW | Bind authorization to a deterministic exact-action identity and recompute that identity at the executor. |
| Execution-grant replay or reuse | Constrain grant validity and consume one-time execution authority once; reuse attempts fail closed. |
| Release tampering or unauthorized activation | Require signed release artifacts, verification, and explicit activation before policy may govern production. |
| Evidence alteration or suppression | Preserve integrity-protected authorization evidence and verification context; durability and retention remain provider-dependent. |
| Downstream bypass | Keep BeaconGuard on the execution path and require the executor to reject missing or invalid action authority. |
Protected assets
- Customer-approved governing policy and release identity
- Human, service, workload, and agent identity/delegation context
- The exact material-action identity and ALLOW/DENY result
- One-time execution authority and consumption state
- Authorization evidence and reconstruction context
Security assumptions and residual risk
BeaconGuard does not claim absolute security. Important residual dependencies remain:
- A compromised identity provider or legitimately trusted signing authority can supply bad authoritative input.
- Incorrect policy can deterministically enforce incorrect intent.
- A compromised executor or host can undermine an otherwise valid authorization boundary.
- Evidence durability depends on configured storage and retention controls.
- Network or application architectures that permit bypass remain a customer deployment risk.