Enforcement Runtime

The BeaconGuard enforcement runtime determines whether an exact consequential action is authorized to execute under the current verified customer governance state. Request admission, identity validation, MCP invocation, A2A delegation, and provider access are inputs to this path; they are not substitutes for the action decision.

The runtime is designed to be:

Deterministic
Fail closed
Exact-action bound
Single-use at the execution-grant boundary
Governed by verified production policy authority
Verifiable and reconstructable through authorization evidence

Identity, delegation, invocation permission, and the proposed business action flow into BeaconGuard exact-action authorization. Request ALLOW is explicitly separated from Action ALLOW. A one-time grant proceeds to execute-side validation while DENY hard-stops; decision evidence records the action, release, and outcome. — Invocation permission establishes context. Consequential execution still requires a separate exact-action authorization decision.

Two distinct authorization events

Request admission

Determines whether the actor, delegated authority, context, and invocation path are valid enough to reach the requested AI, agent, provider, or tool.

Consequential-action authorization

Occurs after the proposed result or side effect is known. BeaconGuard evaluates the exact material action under the Active Verified Release and returns ACTION ALLOW or ACTION DENY.

REQUEST ALLOW ≠ ACTION ALLOW.

Material-action contract

The proposed side effect is converted into a canonical material-action representation and deterministic action identity. Authorization applies to that identity. The contract prevents broad request permission from silently expanding into different downstream actions.

Decision contract

Result	Meaning
ACTION ALLOW	The exact material action satisfies current verified policy, trust, identity, delegation, tenant, environment, and action conditions. One-time execution authority may be issued.
ACTION DENY	The exact material action is not authorized. No execution authority is issued and no side effect may occur.

One-time execution grant

An ALLOW result can produce execution authority bound to the exact material-action identity. At the execution boundary:

The executor receives the action and one-time grant.
The executor recomputes the material-action identity.
The recomputed identity must match the authorized identity.
The grant must be valid, unexpired, unrevoked, and unused.
The grant is atomically consumed for the authorized side effect.

Binding mismatch, replay, grant reuse, invalid trust state, or missing required state fails closed.

Runtime source of authority

The Active Verified Release is the policy authority permitted to govern production authorization. Drafts, unsigned artifacts, inactive releases, mixed policy material, and unverifiable releases are not runtime authorities.

Evidence emission

Each action decision produces integrity-protected authorization evidence tied to the decision, exact material-action identity, governing release, and relevant authority context. The evidence is designed to support verification and deterministic reconstruction.

Failure semantics

The runtime returns DENY or refuses execution when required authorization state cannot be established.

Identity or delegation invalid, expired, revoked, or outside bounds
Tenant or environment mismatch
Freshness or replay failure
Active Verified Release absent or unverifiable
Material-action canonicalization or binding failure
Required approval or policy condition absent
Execution-grant mismatch, expiry, or reuse
Required evidence or shared trust dependency unavailable
Internal authorization error

Silent fallback or permissive continuation is prohibited.