How It Works
BeaconGuard evaluates each regulated workflow request through an inline policy proxy before the request proceeds to model or automation execution.
Runtime flow
Policy Before Execution
- A regulated workflow requests AI assistance.
- BeaconGuard receives the request before the model call.
- Policy rules evaluate signed request metadata, workflow identity, user role, source-system trust, approved-pathway status, context tags, freshness windows, and requested action.
- BeaconGuard returns allow, deny, or needs-review.
- Allowed requests continue to the model or automation endpoint.
- Denied requests are blocked.
- Needs-review requests are routed for human approval.
- Evidence is preserved for audit and compliance review.
Runtime sequence
Runtime Decision Sequence
Compatibility-Layer Path
Some non-native clients require a governed compatibility layer before BeaconGuard evaluation. Host applications or optional preprocessors may generate deterministic context metadata tags before the request reaches BeaconGuard. BeaconGuard's core policy boundary evaluates those tags and other signed request attributes before model execution. It does not originate policy decisions. It does not weaken fail-closed behavior. BeaconGuard still performs the deterministic allow, deny, or needs-review decision and emits reviewable evidence.
Enforcement Boundary
Existing applications remain in place and continue to own workflow logic and systems of record. BeaconGuard places policy enforcement in a dedicated AI request boundary where deterministic 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 regulated 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 signed request metadata, workflow identity, user role, source-system trust, approved-pathway status, context tags, request IDs, timestamps, freshness windows, requested action, and policy identity. Outputs remain constrained to a minimal set: decision result, policy identity, approval status, 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, or needs-review 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
A control outcome is produced before execution; allow moves to bounded model interaction, deny blocks by fail-closed policy, needs-review routes to human approval, and each outcome is retained as decision evidence.