DATA FLOW / TRUST BOUNDARIES
Each boundary establishes a different kind of authority
BeaconGuard separates context, proposal, authorization, execution, and evidence so permission in one layer cannot silently become authority in the next.
Boundary contracts
| Boundary | Establishes | Does not establish |
|---|---|---|
| Identity / delegation | Who or what is acting, for whom, and within what bounds | Final permission for every consequential action |
| Invocation | Which MCP tool, A2A path, API, or application capability may be reached | Authority for every side effect that capability can produce |
| AI / agent proposal | The exact candidate result or action to be evaluated | Execution authority |
| BeaconGuard authorization | ALLOW or DENY for the exact material action under governing policy | Business-system execution |
| Executor / system of record | Validated side effect and resulting authoritative business state | Policy authority |
| Evidence / verification | Integrity, historical context, and reconstruction material | Runtime permission to execute |
Core data flow
- Validate required identity, delegation, tenant/environment, freshness, and replay context.
- Admit the required invocation path; the AI or agent produces a proposed consequential action.
- Canonicalize the exact material action and resolve the current governing policy authority.
- BeaconGuard returns ALLOW or DENY and records authorization evidence.
- ALLOW may issue one-time execution authority bound to the exact action; DENY issues none.
- The executor recomputes the action identity, consumes valid authority once, and writes resulting business state.
Residual responsibilities
- Customer identity and delegation-authority security
- Network and host hardening and prevention of alternate execution paths
- Executor enforcement and system-of-record integrity
- Release-signing key custody and policy-governance correctness
- Evidence-provider durability, retention, and any append-only controls