For the Security Architect
How WhiteFin enforces.
What it requires and where the limits are.
This page is for the person who has to put this in front of their CISO and sign off that it works. No claim here without a paragraph below it explaining exactly what it means. Where we do not govern, we say so — precisely, not vaguely.
How WhiteFin Enforces
The enforcement model.
WhiteFin enforces at the kernel boundary using eBPF — a Linux kernel technology that intercepts system calls before they complete.
Every action an AI agent takes — every file read, every file write, every network connection, every subprocess spawn, every inter-process message — is a system call. System calls are the only way a process interacts with the operating system. There is no path around them.
When an agent issues a system call, WhiteFin's enforcement hook fires before the kernel completes the call. If the decision is deny, the system call returns an error to the calling process. The action does not complete. No data moves. No file changes. No connection opens.
The Guard Chain
Cost-ordered. First deny wins.
Every tool call passes through a cost-ordered chain of evaluation stages. Cheap stages run first. The first stage that produces a deny terminates the chain — later stages are skipped.
The shape — cheap first, expensive last, deny on first match — is what matters. No hidden gates. No out-of-band decisions. The enforcement path contains only deterministic components. No ML models gate real-time decisions.
What WhiteFin Sees
Below the network. At the system call.
This coverage exists because WhiteFin operates at the kernel boundary — not at the network boundary. Actions that produce no external network traffic are fully visible.
What It Requires
Three preconditions.
These are the entirety of the install commitment.
Linux kernel 5.7 or later with BPF-LSM enabled
WhiteFin requires Linux kernel ≥ 5.7, BPF LSM enabled at boot (lsm=...,bpf), and BTF (BPF Type Format) active. On kernels that meet these requirements, WhiteFin operates in full enforcement mode — fail-closed on policy cache miss. On kernels that do not meet these requirements, WhiteFin degrades to observe-only mode. No enforcement occurs. Verify your kernel configuration before deployment if enforcement is a requirement.
Deployment on the host where the agent runs
WhiteFin enforces at the kernel of the host where your agent process runs. Agents running on separate hosts require a separate WhiteFin deployment on each host. This is not a network appliance — it is a per-host enforcement layer. Two deployment options, identical enforcement guarantees: self-hosted (your VPC) or air-gapped on-premise.
Shadow mode observation period
Before enforcement turns on, WhiteFin runs in shadow mode — observe only, no blocking — long enough for Policy Bootstrap to learn what your agents actually do. Default: 15 days. Configurable. At the end of the observation period, you review the generated policy. Nothing goes live without your sign-off.
Fail-Closed Behavior
Unknown action equals blocked action.
On a policy cache miss — when WhiteFin receives a system call for which no policy entry exists — the default behavior is deny. WhiteFin does not fail open.
Architecture
Data Plane vs. Control Plane.
The enforcement path contains only deterministic components. No machine learning. No probabilistic evaluation. No external calls during enforcement.
Probabilistic components — behavioral analysis, semantic evaluation, anomaly detection — run in a separate control plane. They inform policy updates over time. They do not gate real-time enforcement decisions.
Agent Identity
Cryptographic. Persists across child processes.
Every agent carries a cryptographic identity that persists across its full execution lifecycle — including when it spawns child processes.
The identity follows the agent at the kernel level. The kernel knows which agent caused which system call. A valid credential held by a compromised agent does not become a valid authorization for the actions that agent takes.
Who the agent is and what the agent is permitted to do are two separate questions. WhiteFin answers both.
Human authentication remains upstream — your SSO and IdP own that layer. WhiteFin governs agent identity, not human identity.
Where the Limits Are
What WhiteFin does not govern today.
The most useful page in a security evaluation is the one that says where the product stops. Read this carefully.
Not in scope: What the model says
WhiteFin does not intercept model inference. Prompt-level safety, jailbreak resistance, hallucination detection — those are a different vendor category. We assume the model has guardrails. We govern what happens after the model produces an output and the agent acts on it.
Not in scope: Agents running on other hosts
WhiteFin enforces at the kernel of the host it is deployed on. If an agent runs on a separate host with no WhiteFin deployment, that host is not governed. Enforcement scope is per-host. Multi-host environments require per-host deployment.
Not in scope: Already-open file descriptors
File reads and writes are governed at the point of open. Subsequent operations on an already-open file descriptor are not re-evaluated per-operation. This is a known design boundary. It is on the roadmap.
Not in scope: Content on already-established connections
Network connections are governed at connection time. Content inspection on an already-established connection is not currently performed inline. This is also a known design boundary, for the same reasons.
Not in scope: The cloud platform itself
WhiteFin governs the system calls your agents make. It does not govern the cloud provider's own infrastructure or internal operations. That is the cloud provider's domain — and one they cannot govern impartially for agent actions taken against their own infrastructure.
PII and Sensitive Arguments
Inline. Deterministic. No external model call.
WhiteFin evaluates argument content for PII before the tool call executes.
57 entity types across 14 regions — financial identifiers, health data, government IDs, and credential formats.
Detected entities can be denied outright, redacted from the argument before the call proceeds, or routed to human approval before execution. The specific entity set and response action are configurable per policy.
Detection happens in the deterministic data plane — no external model call, no added latency beyond the guard chain.
The Audit Record
Hash-chained. Signed. Independently verifiable.
Every enforcement decision — allow and deny — is written to an immutable audit record at the moment it is made.
Records are hash-chained and cryptographically signed. Tamper with one entry and the integrity failure is immediately detectable without access to WhiteFin systems.
Every record includes: timestamp, agent identity, tool call, full argument payload, enforcement decision, and the stage in the guard chain where the decision was made.
What to Verify Before You Sign Off
The checklist.
If anything on this page requires clarification or documentation for a specific compliance framework — we are available to work through it directly.
Talk to us →