HOW IT WORKS
From agent request to authorized side effect
BeaconGuard uses a two-boundary model: request and invocation context first, exact consequential-action authorization second.
Boundary 1: invocation
Validate identity, delegation, freshness, replay state, tenant/environment, and capability access.
Boundary 2: action
Evaluate the exact material side effect under the current verified customer policy authority.
Passing the first boundary does not imply passing the second.
Runtime sequence
WORKFLOW DEMONSTRATION
See authorization, review, and one-time execution authority in practice
See how BeaconGuard handles a denied request, reviewer step-up, scoped authorization, one-time consumption, and attempted reuse.
Key mechanics
- Exact-action binding: authorization applies to the action that actually executes.
- One-time execution authority: a valid authorization is consumed once, not reused broadly.
- Verified policy authority: production decisions are governed by the current approved and activated release.
- Fail-closed behavior: invalid trust, mismatched action binding, or reuse attempts stop execution.