How It Works
BeaconGuard evaluates each outgoing AI request through a deterministic control boundary before the request proceeds to model execution.
Runtime sequence
Runtime decision sequence
1. Compatibility normalization
For non-native clients, request shape and context are adapted before BeaconGuard control evaluation.
2. Normalize
Request context, actor, action, and policy identity are normalized.
3. Evaluate
Policy engine applies deterministic control and produces decision state.
4. Emit evidence
Decision, policy version, and request context are recorded.
5. Gate execution
Allowed requests proceed to the model path.
6. Review record
Outcome is retained for replay and security review.
Fail-closed branch
Malformed or untrusted input never reaches execution.
7. Fail action
Denied requests are returned with context and kept reviewable.
Fail-closed is explicit: no trusted decision, no execution.
Compatibility-layer path
Some non-native clients require a governed compatibility layer before BeaconGuard evaluation. That layer normalizes request shape and context into the structure BeaconGuard evaluates. It does not originate policy decisions. It does not weaken fail-closed behavior. BeaconGuard still performs the deterministic allow/deny decision and emits reviewable evidence.
Enforcement Boundary
Applications do not need to embed AI governance rules in business logic. BeaconGuard places governance in a dedicated boundary where deterministic policy decisions remain consistent regardless of model behavior or prompt drift.
Deterministic Decision Path
For equivalent request state and policy snapshot, BeaconGuard returns equivalent decisions. This is the foundation for operational confidence, incident response, and reproducible reviews in financial workflows.
Compatibility normalization occurs before BeaconGuard policy evaluation when needed. It is not a replacement for the deterministic decision path.
Input and Output Governance
Inputs require explicit context (actors, requested action, attributes, policy identity), so decisions are traceable. Outputs remain constrained to a minimal set: decision result, policy identity, and reasoning context.
Evidence at Runtime
- Evidence is emitted as structured records, designed for audit and investigation.
- Failure conditions are explicit rather than implicit.
- Decision provenance stays attached to policy identity and input context.
Reviewer focus
A reviewer should confirm that the request path is normalized before evaluation, that policy evaluation produces deterministic allow/deny outcomes, that malformed or missing inputs fail closed, and that each execution decision writes reviewable evidence before model calls can occur.
Decision and Review Loop
Decision
Allow/deny computed from policy and state.
Execution
Model call proceeds only when allowed.
Review
Outcome, policy identity, and context are replayable.