Control Responsibility Matrix
BeaconGuard owns the exact consequential-action authorization decision and its assurance evidence. It does not absorb the responsibilities of identity systems, protocol layers, business applications, execution systems, systems of record, or customer governance authorities.
Responsibility matrix
| Responsibility | BeaconGuard | Identity / Delegation | Application / MCP / A2A | Executor / System of Record | Customer Governance / Review |
|---|---|---|---|---|---|
| Who or what is acting | Consumes and validates required identity context | Authoritative source for human, service, workload, or agent identity | Carries validated context where required | May verify calling service / execution authority | Defines identity and access governance |
| For whom the agent is acting | Consumes delegation as an authorization constraint | Authoritative for delegation chain / authority context | A2A or application path may transport delegation | Does not infer broader authority from delegation alone | Defines delegation policy and revocation expectations |
| Capability / tool invocation | May perform request admission checks; does not treat invocation as final action authority | May constrain scopes / capabilities | MCP / API / application layer owns invocation mechanics | Provides callable capability | Reviews permitted integration paths |
| Exact consequential-action authorization | Owns deterministic ACTION ALLOW / ACTION DENY under the Active Verified Release | Provides bounded identity/delegation inputs | Provides the proposed material action and required context | Must not execute without valid bound authority | Defines / approves governing control intent |
| Production policy authority | Validates, packages, verifies, and enforces only the activated verified release | Does not own BeaconGuard policy | Does not silently substitute policy | Does not determine BeaconGuard policy | Owns approval/signing authority and trust configuration |
| Business side-effect execution | Issues or denies one-time execution authority; does not become the business system of record | Does not execute the side effect | Orchestrates the allowed workflow as designed | Verifies the action binding, consumes authority, and performs/records the side effect | Defines operational approval and oversight requirements |
| Authorization evidence | Preserves action decision, governing release, authority context, and integrity/reconstruction information | Provides identity/delegation provenance where configured | Correlates request and workflow context | Maintains downstream business records and execution state | Reviews, verifies, audits, and investigates |
| Fail-closed behavior | DENY/refuse execution when required authorization conditions fail | Revocation/expiry should invalidate authority context | Must not bypass the action boundary | Must reject invalid/mismatched/reused execution authority | Reviews deployment controls and exception handling |
Reviewer checks
- Identity and delegation remain authoritative inputs, not the final action decision.
- MCP/A2A/API invocation permission cannot bypass action authorization.
- The exact material action is bound before execution.
- Only an Active Verified Release governs production authorization.
- ALLOW produces only bounded one-time execution authority.
- The executor rejects mismatched, expired, revoked, or reused authority.
- Systems of record remain authoritative for business state.
- Evidence allows reviewers to distinguish the authorization decision from downstream business records.