DEPLOYMENT & INTEGRATION

Keep the authorization boundary on the execution path

BeaconGuard deploys between the proposed consequential action and the enterprise executor that can create the side effect. The core deployment invariant is that the action cannot reach execution without crossing the BeaconGuard boundary.

BeaconGuard deployment topology showing a horizontal execution path from application or AI agent to proposed action, through the BeaconGuard exact-action authorization boundary, and to the executor. Separate lower cards show supporting trust services, the Active Verified Release, authorization evidence, and the no-bypass requirement.
BeaconGuard remains on the consequential execution path. Identity, delegation, MCP/A2A, replay state, keys, and monitoring provide context and trust inputs; they do not create alternate action authority.

Integration contract

DomainEstablishesDoes not establish
Identity / delegationWho or what is acting, for whom, and within what boundsAutomatic authority for every downstream side effect
MCP / A2A / API / applicationInvocation and capability pathFinal action authorization
AI / agentA proposed result or consequential actionExecution authority
BeaconGuardExact-action ALLOW or DENY under governing policy authorityBusiness-system execution or source-of-record ownership
Executor / system of recordValidated execution and resulting business statePolicy authority
Evidence providerIntegrity, retention, and reconstruction material as configuredRuntime permission to execute

Runtime sequence

  1. Validate required identity, delegation, tenant/environment, freshness, and replay context.
  2. Admit the required invocation path and allow the AI or agent interaction to produce a proposal.
  3. Construct and canonicalize the exact material action that would create the side effect.
  4. Authorize that action under the current governing policy authority and return ALLOW or DENY.
  5. Persist authorization evidence; ALLOW may issue one-time execution authority bound to the action.
  6. The executor recomputes the action identity, validates and consumes the grant once, then creates the side effect.

Production placement requirements

On path

The application or connector architecture must prevent a consequential action from bypassing BeaconGuard.

Verified authority

Only verified and explicitly activated customer policy authority may govern production decisions.

Executor enforcement

Executors reject missing, mismatched, expired, revoked, or previously consumed execution authority.

MCP and A2A

MCP and A2A are supported as invocation and delegated-authority context. They do not replace the exact-action decision.

Invocation permission and delegated authority constrain the decision; they do not equal final action authority.

Environment and evidence boundaries

Development, validation, and production should use explicit trust, release, key, replay, and evidence boundaries. Evidence-provider durability, retention, append-only behavior, and external anchoring remain deployment-dependent.

Control Responsibility Matrix Enforcement Runtime Data-Flow Trust Analysis