Data-Flow Threat Analysis

This page identifies the trust boundaries, data flows, threat conditions, and deterministic enforcement responses associated with a BeaconGuard-governed request. It supplements the System Architecture and Threat Model documentation.

Data-flow and trust boundaries

Numbered directional data flows across customer-controlled, BeaconGuard runtime, evidence-provider, governed-system, and management trust boundaries. The Control Plane is outside the request path. The customer IdP does not decide ALLOW or DENY.
Text version
  1. Customer-controlled: Enterprise Application → Optional System Connector (request context).
  2. Customer Identity Provider supplies trusted identity context for runtime verification; does not decide ALLOW or DENY.
  3. Normalized request and identity context enter the BeaconGuard Runtime Boundary.
  4. Active Verified Release feeds deterministic evaluation.
  5. Replay verification uses Shared Replay State.
  6. Runtime generates and writes the Verifiable Decision Record to the separate Evidence-provider boundary.
  7. Write success / verification result returns to the outcome path; outcomes depend on successful evidence persistence.
  8. ALLOW forwards to the governed system only after successful evidence persistence.
  9. DENY returns to the Enterprise Application with no downstream execution.
  10. Operator / Administrator → Control Plane (outside request path).
  11. Control Plane manages Compliance Playbook release lifecycle through distribution, verification, and activation.
  12. Active Verified Release feeds runtime evaluation (flow 4).
  13. Monitoring or review may access evidence where configured; provider-dependent retention and integrity.

1. Scope and trust boundary

BeaconGuard inserts a Runtime Control Boundary between an enterprise application or workflow and a governed AI, API, or automated system. The management plane produces releases; the runtime data plane evaluates each request against an Active Verified Release and returns ALLOW or DENY before governed execution. The Control Plane is outside the per-request path. The customer IdP does not make the BeaconGuard decision.

Out of scope for this page:

2. Data-flow sequence

  1. Enterprise Application / Workflow submits a request.
  2. Optional System Connector maps source protocol and context.
  3. Request Validation and Context Normalization checks required structure.
  4. Trust, Freshness, and Replay Checks validate admission conditions.
  5. Deterministic Playbook Evaluation applies the Active Verified Release.
  6. BeaconGuard determines ALLOW or DENY.
  7. A Verifiable Decision Record is persisted.
  8. ALLOW may proceed to governed execution; DENY hard-stops.
  9. Evidence supports replay, verification, and governance review via the configured evidence provider.

3. Trust inputs

Typical trusted inputs include signed or otherwise verified request metadata, workflow identity, user role, source-system trust, approved-pathway status, request identifiers, timestamps, freshness windows, and the Active Verified Release selected for evaluation.

Missing or invalid required inputs fail closed as DENY.

4. Threat conditions

Threat Boundary Control Enforcement response Residual responsibility
Malformed request Runtime Control Boundary Request Validation and Context Normalization DENY because required structure is missing or invalid Application request construction
Missing trusted context Runtime Control Boundary Trust checks and playbook requirements DENY because required context is missing Identity and source-system trust configuration
Invalid signature or trust signal Runtime Control Boundary Trust and signature checks DENY because trust cannot be verified Key and identity-provider operations
Stale request Runtime Control Boundary Freshness checks DENY because freshness cannot be verified Clock and request-timing practices
Replayed request Runtime Control Boundary Replay checks DENY because the request appears replayed Replay-state provider and deployment configuration
Inactive or unverified release Release Verification and Activation Release verification before activation DENY because no verified active release is available Release distribution and activation operations
Unauthorized pathway Deterministic Playbook Evaluation Active Verified Release pathway controls DENY because the pathway is not approved Pathway governance and playbook authoring
System Connector manipulation Optional System Connector Connector cannot evaluate controls or bypass fail-closed enforcement DENY when normalized context fails validation or trust checks Connector hardening and monitoring
Downstream execution misuse After ALLOW BeaconGuard does not own post-ALLOW business logic Not a runtime permission bypass; ALLOW only permits governed execution Customer application and model-risk controls
Evidence-provider failure Evidence path Verifiable Decision Record emission; storage durability is deployment-dependent Runtime permission remains ALLOW or DENY; retention and integrity depend on provider configuration Evidence-provider and customer infrastructure

5. Enforcement behavior

Runtime permission results are binary:

When required approval is absent, BeaconGuard returns DENY with a deterministic reason indicating that approval is required. An illustrative reason style is APPROVAL_REQUIRED. Governance or human review may follow from the Verifiable Decision Record; review does not permit execution.

6. Evidence and review

Every deterministic result produces a Verifiable Decision Record that preserves decision context, release identity, control result, and outcome. Evidence is designed for replay and verification and supports audit and governance review. Retention and integrity protection depend on the configured evidence provider and shared customer deployment responsibilities. Append-only or immutable storage is not assumed unconditionally.

7. Residual risks

BeaconGuard does not remove residual risk from:

Those risks remain shared with customer operations and are addressed in the broader Threat Model.

8. Related documentation