SOLUTIONS · 08
Detectors produce signals. Policy decides.
A detector produces a score, a finding or a reason code. What happens next is up to policy. Wardline policies are written in readable YAML, compiled to Cedar, signed and distributed per application as versions.
THE PROBLEM
A threshold buried in code cannot be audited
A line like “block if the score is high” inside a classifier is a decision auditors cannot see and the security team cannot change. Moving the threshold means a new release, and nobody can later tell which threshold blocked which request.
As rules multiply they start to conflict: one says mask, another says block. Unless precedence is explicit, the same request gets different decisions in different environments.
HOW IT WORKS
Step by step
Authoring
Rules are written in YAML. Conditions use reason codes, risk band, application tier, direction and identity; the result is one of the five decisions plus flags. Thresholds are integers from 0 to 10000.
Compilation and testing
YAML compiles to an intermediate representation and then to Cedar. The IR interpreter and Cedar are run against the same scenarios, and if they disagree the bundle is not published.
Signing and distribution
Bundles are signed with Ed25519. The engine rejects unsigned or invalid bundles and keeps running on the last valid one; a stale bundle is recorded in evidence with its own reason code.
Resolution
All matching rules are evaluated and the most restrictive decision wins: DENY, REQUIRE_APPROVAL, REWRITE, MASK, ALLOW. An ALLOW rule cannot relax another rule’s decision; exceptions are written with “unless”. If nothing matches, the default action applies.
Versions and diffs
Every release is a version. The console shows the diff between two versions, and who published what and when goes into the audit log. When a new version runs in shadow, any decision that differs from the live one is marked with the SHADOW_DIFF flag.
DECISIONS
Which decision you get, and when
| Decision | When | Example reason code |
|---|---|---|
| ALLOW | No rule matched, or every matching rule says ALLOW: the default action applies. | POLICY.DEFAULT_ACTION |
| MASK | Detected values are masked by position. | POLICY.MASK_APPLIED |
| REWRITE | The request or response is rewritten using the strategy in policy; with the template strategy the model is not called. | POLICY.REWRITE_TEMPLATE_FALLBACK |
| REQUIRE_APPROVAL | The tool call, MCP tool or email waits for an approver. | APPROVAL.PENDING |
| DENY | Any rule says block, whatever the other rules say. | POLICY.RULE_MATCH |
EXAMPLE
A new version running in shadow
The security team prepares a version that changes the card number rule from MASK to DENY and runs it in shadow. For a week the live decision stays MASK, the shadow version produces DENY, and every difference is marked with SHADOW_DIFF. The team reviews the differences in the console, sees which applications are affected and promotes the version.
| Decision | DENY |
|---|---|
| Live version | v41 · MASK |
| Shadow version | v42 · DENY |
| Matching rule | block-card-numbers |
| Signature | Ed25519 · verified |
| Reason codes |
|
| Flags |
|
| Risk score | 0.96 |
CONFIGURATION
What administrators control
Rules and default action
Rules per application and risk tier, and what happens when nothing matches.
Hard rules
Rules marked “override: hard” are applied first; the default rules that ship with the product are in this class.
Failure mode
Whether an application fails open or closed when a detector is unreachable; when layers combine, the stricter one wins.
Release flow
Who writes and who publishes; observe and shadow stages; the previous version to roll back to.
RELATED
Capabilities that work alongside
See it on your own traffic.
In a demo session we walk through this flow with examples your security team picks, in the console’s evidence viewer.
Request a demo