Control Responsibility Matrix
This page helps reviewers understand which responsibilities BeaconGuard owns, which remain with the application and system of record, and which stay outside BeaconGuard’s control boundary. It is intended to reduce ambiguity during architecture, security, risk, and procurement review.
Responsibility model
BeaconGuard governs whether an AI interaction is allowed to proceed under policy. BeaconGuard does not replace transaction systems, systems of record, model providers, or downstream operational ownership.
Responsibility matrix
| Responsibility | BeaconGuard | Application | Model provider | System of record | Operations / reviewers |
|---|---|---|---|---|---|
| Authorization decision at the AI request boundary | Owns policy evaluation and explicit allow/deny decisioning | Submits normalized request context and enforces returned decision | Does not own authorization policy | Does not own AI request authorization | Review boundary correctness and policy fit |
| Business transaction execution | Does not execute business transactions | Orchestrates allowed workflow steps | Does not execute business transactions | Remains authoritative for transaction/state recording | Validate control separation and escalation paths |
| Model behavior and output quality | Does not guarantee model quality or business correctness | Determines how allowed outputs are used | Owns model behavior and model-serving characteristics | Does not determine model quality | Evaluate suitability and downstream control expectations |
| Decision evidence and review context | Emits structured decision evidence within its control boundary | Correlates BeaconGuard decisions with workflow context as needed | Does not provide BeaconGuard policy evidence | May hold downstream business records, not BeaconGuard decision evidence by default | Review evidence, trace decisions, and assess control operation |
| Fail-closed behavior when required conditions are not met | Denies requests when policy or trust conditions are missing, malformed, or out of bounds | Must respect and enforce deny outcomes | Does not control BeaconGuard fail-closed semantics | Not responsible for AI request gating | Validate that failure handling is explicit and reviewable |
What reviewers should verify
- The application submits the context BeaconGuard requires to evaluate policy
- BeaconGuard’s allow/deny response is enforced by the application
- Model execution does not become the authorization boundary
- Systems of record remain authoritative for business state
- Reviewers can distinguish BeaconGuard evidence from downstream business records
Next step
Reviewers can continue structured evaluation through the Reviewer Kit, Trust Center, and Contact path.