System Architecture

BeaconGuard is an independent authorization and assurance boundary for consequential AI actions. The architecture separates three responsibilities: govern which policy authority may control production, authorize the exact material action before execution, and verify the decision afterward.

BeaconGuard operating model with three horizontal lanes: Govern creates and activates the customer-approved release; Authorize evaluates the exact proposed action and issues a grant or deny result; Verify connects the decision record and governing authority to independent reconstruction and verification.
Govern establishes policy authority. Authorize controls the exact action. Verify preserves enough evidence to independently check the decision afterward.

Core architectural invariant

REQUEST ALLOW ≠ ACTION ALLOW.

A request may pass identity, delegation, invocation, transport, and capability checks without authorizing the exact business side effect that results. BeaconGuard therefore separates request admission from consequential-action authorization.

Govern plane

The Govern plane controls which customer-approved policy authority may govern production authorization. Compliance Playbooks move through validation, compilation, governance approval, signing, controlled distribution, verification, and explicit activation.

A release artifact does not become production authority merely because it was distributed. Only an Active Verified Release may govern runtime authorization. Draft, unsigned, mixed, revoked, or unverified material must not enter the production decision path.

Authorize plane

The Authorize plane consumes validated identity, delegated authority, tenant/environment, trust, freshness, replay, and invocation context. These inputs constrain the decision but do not independently authorize the material side effect.

The consequential-action path is:

  1. Validate identity, workload identity, delegation, and request context.
  2. Admit the invocation path required to reach the AI, agent, provider, or tool.
  3. Treat the AI result as an untrusted proposal.
  4. Construct and canonicalize the exact material action.
  5. Derive its deterministic material-action identity.
  6. Resolve the current Active Verified Release and trust state.
  7. Evaluate the exact action deterministically.
  8. Return ACTION ALLOW or ACTION DENY.
  9. Persist authorization evidence tied to the governing release and exact action.
  10. For ALLOW only, issue one-time execution authority bound to the exact action.
  11. At execution, recompute the action binding and consume the grant once.

Exact-action binding

BeaconGuard authorizes the material action, not a vague textual intent. The material action is represented canonically and assigned a deterministic identity. Execution authority is bound to that identity.

If the action presented to the executor differs from the action that was authorized, the binding fails and execution is denied. This prevents an authorized Action A from being replaced by Action B after policy evaluation.

One-time execution authority

ACTION ALLOW does not become a reusable bearer permission. One-time execution authority is bound to the authorized action and consumed on successful use. Replay or reuse attempts fail closed.

MCP relationship

MCP supplies protocol and tool-invocation context. It can establish whether an agent may invoke a capability, but MCP invocation permission does not automatically authorize the exact consequential side effect produced by that capability.

MCP ALLOW ≠ ACTION ALLOW.

A2A relationship

A2A supplies agent-to-agent identity, communication, and delegated-authority context. Valid delegation constrains what may be considered authorized but does not override downstream BeaconGuard policy or independently grant the final side effect.

A2A delegation ≠ ACTION ALLOW.

Enterprise identity relationship

The customer identity provider remains authoritative for workforce identity, and workload/agent identity systems remain authoritative for their own identities. BeaconGuard normalizes validated identity and delegation context for authorization.

Identity answers who is acting and for whom. BeaconGuard answers whether this exact material action may execute under the current approved governance state.

Verify plane

The Verify plane preserves the evidence required to check not only what decision was recorded, but what authority governed it and what exact action was evaluated.

  • Decision and correlation identity
  • Material-action identity
  • Actor and delegated-authority context
  • Tenant and environment binding
  • Active Verified Release / manifest identity
  • Policy / playbook identity
  • Execution-grant identity and consumption state when applicable
  • Integrity-verification information
  • Inputs and references required for deterministic reconstruction

Failure semantics

Authorization fails closed if required policy authority, trust state, identity/delegation, action binding, replay state, evidence persistence, or shared dependencies cannot be established or verified. No permissive fallback is permitted.

Systems BeaconGuard does not replace

  • Enterprise IAM or identity providers
  • MCP or A2A as protocols
  • AI models or model hosts
  • Enterprise applications and systems of record
  • EHR, AML, fraud, payment, case-management, or workflow platforms
  • Clinical, compliance, legal, privacy, or risk authorities
  • SIEM or GRC systems

Related review material