How WhiteFin fits
How WhiteFin fits into a stack that already has controls.
This page is for the evaluator who has already read the argument and now wants the practical version. You already have identity, gateways, runtime security, observability, and a GRC program. They remain necessary.
The question is what they still leave unresolved when autonomous software begins causing real consequences – and why WhiteFin is a separate layer rather than another version of one of those controls.
This page describes what WhiteFin adds, what it deliberately does not replace, and the properties you should hold us accountable for.
What is already in the path
None of this gets replaced.
Five things are already doing work before WhiteFin is anywhere near your environment. Identity establishes which principal this is. The gateway decides whether a request on this route may proceed. Runtime security asks whether the workload is exposed, compromised, or behaving abnormally. Observability records what happened. Your GRC program organizes obligations, controls, and evidence.
Each of them answers its own question well. WhiteFin does not replace any of them, and a deployment that removed one would be worse rather than simpler. We are additive on purpose: we depend on your identity plane being real, and we hand evidence to the systems you already run.
Agent platforms and inventories tell you what has been registered. WhiteFin does not assume that declaration is the complete execution reality.
WhiteFin is additive because it answers a different set of questions: what autonomous execution is actually operating, what organizational power has been delegated to it, whether consequential action remains inside that power, and what Authority governed the outcome.
What is actually operating
Governance should not depend on a perfect agent inventory.
Autonomous systems enter organizations through different teams, frameworks, tools, platforms, and workflows.
A governance model that only sees agents after somebody has registered, instrumented, or rewritten them starts with an assumption the organization may not be able to defend.
WhiteFin can discover autonomous execution in supported environments without requiring changes to the agent code.
Declared inventory, manifests, and platform context can add meaning. They should not be the only way governance knows something exists.
WhiteFin starts from what is actually operating, then gives the organization a way to govern the power it is allowed to exercise.
Where the decision sits
Between the decision to act and the effect landing.
An autonomous system decides to do something. A moment later the effect lands: a volume is deleted, a deploy goes out, a secret is used, data moves. Between those two moments there is a point where the action can still be stopped.
That point is where the authority decision belongs. Not in the model, which can be entirely reasonable and still ask for power it was never given. Not only afterwards in a log, which is a record rather than a boundary.
WhiteFin evaluates the Authority that is in force for the consequential action and determines whether that action remains inside the power the organization delegated.
That decision does not have to live inside the process being governed.
WhiteFin can apply Authority at an independent enforcement boundary outside the autonomous process, so the actor does not control the mechanism that decides whether its action may proceed.
On supported Linux environments, that independent boundary can extend to the kernel execution boundary.
The important distinction is timing: governance has to matter before the consequence, not only explain it afterward.
The second distinction is independence: the governed process should not be the authority on whether its own action is authorized.
WhiteFin declares what is governed and what is not. That declaration is specific, and it is the first thing we go through with you. We do not publish it here as a perimeter claim, because a scope claim on a marketing page is exactly the kind of sentence that ages into something untrue. You get the current one, in writing, during an evaluation.
Why it is a separate layer
Why the controls you already have do not make WhiteFin redundant
| Control | What it tells you | What it leaves open |
|---|---|---|
| Agent inventory / platform | Tells you what was registered. | It does not necessarily tell you what autonomous execution is actually operating. |
| Identity / IAM | Tells you who the principal is and what broad access it holds. | It does not tell you whether this exact consequential action is inside delegated organizational Authority. |
| AI / MCP security | Tells you whether a request, prompt, tool interaction, or route appears acceptable. | It does not establish what organizational power governs the resulting consequence. |
| Runtime / cloud security | Tells you whether execution appears compromised, vulnerable, or abnormal. | Normal-looking execution can still exceed delegated Authority. |
| Observability / SIEM | Tells you what happened. | It does not establish what Authority was in force before the effect occurred. |
| GRC / compliance | Tells you what obligations and controls should exist. | It does not itself keep live autonomous execution inside delegated power. |
| WhiteFin | Starts from real autonomous execution, makes delegated organizational power explicit, enforces that Authority independently of the governed process at supported execution boundaries, and preserves independently verifiable evidence of which Authority governed the result. | Which consequential paths are inside the declared governed surface, and which are outside the claim? |
From intent to enforcement
From human intent to active Authority
Organizational Authority should not require policy engineering for every normal change.
WhiteFin separates the experience of expressing a mandate from the work required to make that mandate safe and enforceable.
- 01Express the mandateState the organizational outcome and the power the autonomous system needs.
- 02Understand the changeWhiteFin turns the request into a clear proposed Authority change and surfaces material ambiguity.
- 03Review what actually changesThe approver sees the meaningful difference from the Authority already in force.
- 04Get the right organizational approvalThe person or body entitled to delegate that power decides whether to approve it.
- 05Make the approved Authority operationalThe approved boundary becomes the Authority applied to consequential execution.
The simplicity is deliberate. The safeguards are not removed; they are moved underneath the user experience.
The model may help interpret what the user means. It may not create Authority, invent missing organizational facts, determine who should approve its own proposal, or make the final authorization decision.
The user should make the organizational decision. WhiteFin should handle the machinery required to make that decision real.
Review the change, not the machinery.
Approvers should not have to re-read an entire policy universe every time Authority changes.
WhiteFin should present the decision in terms of what is materially different from the Authority already in force.
The approver reviews the organizational delta. WhiteFin handles what has to happen underneath.
What has to be true
What has to be true for an Authority Layer to matter
It cannot depend entirely on self-description.
The autonomous system should not have to tell governance that it exists before governance can begin to see it.
Failure cannot silently increase power.
Losing a dependency may reduce useful work. It must not quietly widen the Authority available to autonomous software.
A model cannot decide that Authority exists.
AI can help interpret intent, explain behavior, and recommend changes. The organization remains the source of delegated power.
The autonomous system cannot widen its own Authority.
A system asking for more power is a request, not authorization.
Observed behavior is evidence, not permission.
What a system did yesterday can inform tomorrow's boundary. It cannot silently become Authority because it happened before.
Governance has to matter before the effect.
A report after the consequence is accountability. It is not enforcement.
The enforcement decision must not depend solely on the governed process choosing to honor it.
Coverage has to be explicit.
Controlling one execution path does not justify claiming that every path to the same consequence is governed.
Evidence has to survive disagreement.
The acting system and the enforcing vendor should not be the only parties capable of explaining what Authority governed the result.
Decision to evidence
A governed decision should leave evidence that survives the system that made it.
WhiteFin does not treat the enforcement decision and the accountability record as separate stories.
Each governed decision produces cryptographically protected evidence of the governed attempt, the Authority in force, and the decision made. WhiteFin can link that record to evidence of the resulting or prevented effect.
The resulting record can be checked independently of the live WhiteFin runtime.
The acting system and WhiteFin should not have to be trusted as the only interpreters of what happened.
Under pressure
The boundary has to remain a boundary under pressure.
A control is not meaningful if congestion, partial failure, or uncertainty quietly turns into permission.
WhiteFin’s requirement is simple: pressure may reduce availability or increase delay. It must not silently increase autonomous power.
The exact operating envelope and measured behavior for a deployment are part of the technical evaluation.
Deployment shape
The authority decision runs in your environment, not in ours.
WhiteFin is deployed inside the customer environment: self-hosted in your own cloud, on your own hardware, or in a private, sovereign, disconnected, or air-gapped environment. The authority decision is made there, by software you are running.
WhiteFin is designed so that critical Authority decisions can remain inside the customer environment, including environments where the final decision cannot depend on a vendor cloud being reachable.
For regulated, sovereign, private, or disconnected environments, that is not a deployment preference. It is part of whether the control can be used at all.
During an evaluation
What we will put in writing during an evaluation
- 01What autonomous execution WhiteFin can observe in your environment.
- 02What is governed and what is outside the governed surface.
- 03Which consequential actions can be stopped before the effect.
- 04What happens when required dependencies are unavailable.
- 05What Authority and approval state governs a decision.
- 06What evidence can be independently established afterward.
- 07What WhiteFin does not claim.
We would rather give you a narrower statement you can test than a broader statement you have to trust.
Where would this sit in your stack?
Bring the deployment you cannot approve today. We will go through the declared scope, the failure behavior, and what changes in your environment.