WardenOpen-source AI scannerExplore →
Layer 4 · Day-0 ceremony

From a blank policy to enforcement in fifteen days.

Hand-written deny-by-default policy is a 90-day project. Policy Bootstrap collapses it to fifteen — and the policy you ship is derived from your real traffic, not from what an architect could remember.

Policy Bootstrap is the Day-0 ceremony pillar of WhiteFin's moat — alongside ToolGuard (inline enforcement) and Agent Passport (cryptographic identity). Three phases: shadow-mode observation builds the behavioral baseline; auto-synthesis derives a human-readable YAML policy from observed traffic; operator approval flips the proxy to deny-by-default. Six times faster than hand-authored policy. Zero rules written by humans. One hundred percent of the policy is grounded in real observed agent behavior.

6×
Faster to enforcement
0
Policies handwritten
100%
Derived from traffic
15
Days, end to end
How it works

Three phases. Fifteen days.

Bootstrap is a fixed sequence: observe, generate, enforce. The clock starts the day you drop the proxy in. Deny-by-default is reached on day fifteen.

01
Days 1–7

Observe

Shadow-mode proxy logs every tool call. No enforcement. Zero friction.

  • WhiteFin sits inline but blocks nothing — every call passes through unchanged.
  • Tool calls are captured with full argument distributions, time-of-day patterns, calling-agent identity, blast-radius classification, and downstream effects.
  • Argument fingerprints (parameter shapes, value ranges, frequency distributions) are recorded against agent identity, building a behavioral baseline per agent × per tool × per environment.
  • Operators get a live dashboard but agents are unaware shadow mode is on. No surface change to existing systems.
02
Days 8–12

Generate

Policies auto-synthesize from observed agent behavior — argument distributions, time-of-day patterns, blast radius.

  • Inverse policy synthesis: from N observations, infer the smallest policy that allows them all. Standard ML inference, not a black-box model.
  • Each generated rule is human-readable YAML — operators can audit, edit, reject, or extend.
  • Rules are scoped by agent identity, tool, time-of-day window, argument distribution percentile, and blast-radius tier.
  • Anomalies in the observation window are flagged but not auto-included — the operator decides whether they are legitimate edge cases or attacks.
03
Days 13–15

Enforce

Operator approves the generated rule set. The proxy flips to deny-by-default. Anything outside the policy now requires explicit approval.

  • Operator reviews the auto-generated rules in a single PR-style diff. Approve in batches, edit specific rules, or reject and extend the observation window.
  • On approve, the proxy mode flips from shadow → enforce. From this moment, deny-by-default applies — any call not matching the approved policy is blocked.
  • Rules become living artifacts: as new agent behaviors emerge, they re-enter shadow mode, get re-synthesized, and the operator re-approves the delta.
  • Continuous re-bootstrap on a rolling window means the policy evolves with the workload — without humans hand-writing rules.
The comparison

Hand-written vs. shadow-mode bootstrap.

Same outcome (deny-by-default for every tool call). Different paths. The hand-written path optimizes for the architect's mental model. The bootstrap path optimizes for ground truth.

DimensionHand-writtenWhiteFin Bootstrap
Time to first enforcement90+ days (industry baseline)15 days
Author of the policySecurity architect, hand-writtenAuto-synthesis from observed traffic
CoverageWhatever the architect remembered100% of observed agent behavior
Drift handlingManual policy update on incidentContinuous re-bootstrap, operator-approved delta
Audit trail of policy originWiki history at bestEvery rule maps to specific observed calls
False positives at enforce-day-1High — architect couldn't predict prod trafficLow — derived from real prod traffic
Day 1+ · Continuous drift defense

Sanctioned Envelopes — the approved behavioral contract that outlives bootstrap.

Bootstrap produces a policy. A Sanctioned Envelope is what that policy becomes at runtime — a cryptographically-bound record of the exact tool-call shapes an agent is authorized to produce, scoped to a specific session, environment, and operator-approved version. Where bootstrap asks "what behavior did we observe?", the envelope asks "does this call match what was sanctioned?"

What a Sanctioned Envelope contains

  • The exact set of tools the agent is permitted to call — scoped to a specific operator-approved policy version, not a floating "latest".
  • Argument distribution bounds derived from the bootstrap observation window: percentile ranges, enum constraints, blast-radius ceiling.
  • A session-scoped cryptographic proof that the issuing operator key matches the key on record — the envelope cannot be replayed across agent identities.
  • A validity window and expiry: envelopes are ephemeral by design. An expired envelope triggers re-bootstrap, not silent pass-through.
  • An audit reference linking every issued envelope back to the specific policy version that authorized it — the compliance artifact for change-management auditors.

How envelopes are generated

At the moment an operator approves the bootstrap-generated policy (end of Day 15), the proxy materializes a Sanctioned Envelope for every agent in the approved scope. The envelope is derived deterministically from the approved policy version — the same input always produces the same envelope, making re-issuance after a policy update auditable as a delta, not a replacement.

When a new agent behavior enters shadow mode during continuous re-bootstrap, the existing envelope remains active for unchanged tools. Only the delta goes through re-synthesis and re-approval. The result: a living compliance artifact that tracks every authorized change without invalidating what was already approved.

Continuous compliance evidence, not point-in-time screenshots

Every tool call matched against an active envelope produces a timestamped audit record: envelope ID, policy version, call shape, result classification (within-bounds / drift-detected / blocked). Auditors reviewing a SOC 2 or ISO 27001 evidence package no longer need to reconstruct "what was allowed on this date" — the envelope record is the answer, and it exists for every call WhiteFin proxied, not just the ones that triggered an alert.

When a call arrives that falls outside the envelope — an argument out of observed range, a tool not in the approved set, a blast-radius tier above the sanctioned ceiling — the proxy classifies it as drift, surfaces it to the operator, and logs the deviation against the envelope version. The approved envelope is the immutable reference point. Drift is measured against it continuously, not retroactively.

Sanctioned Envelope Coverage
8 of 10

agents have active envelopes (80%)

Continuous audit evidence for SOC 2 CC8.1, ISO 27001:2022 A.5.9, EU AI Act Article 15, NIST AI RMF MANAGE-2.3.
Envelope lifecycle
Bootstrap PolicyOperator approvedIssue EnvelopeDeterministic derivationTool CallAgent runtimeMatch CheckWithin-bounds / driftAudit RecordTimestamped evidence
Framework mapping
SOC 2 CC8.1
Change Management
Every policy delta is a tracked change event with operator approval proof.
ISO 27001:2022 A.5.9
Inventory of information assets
Envelopes maintain a live inventory of authorized agent capabilities.
EU AI Act Article 15
Accuracy, robustness and cybersecurity
Continuous drift detection surfaces behavioral degradation before it becomes an incident.
NIST AI RMF MANAGE-2.3
Risk response
Blocked calls and drift events are automatically escalated to the risk response queue.

Day 1: shadow mode.
Day 15: deny-by-default.

Every other vendor in the market hands you a policy template and a six-week SOC engagement. We hand you a proxy and fifteen days.

We use cookies for analytics to understand how visitors use our site. No advertising cookies. Privacy Policy