About WhiteFin
Software is becoming an operator.
Organizations need a way to retain authority.
For most of computing history, software advised and a person acted. That order is reversing. The question underneath every AI deployment is now the same one: how much power did the organization actually delegate, and can it show that?
Capability is not Authority. Authority is the bounded power the organization has actually delegated.
The line the company is built on
Why We Exist
The organization has to remain the source of the power.
WhiteFin was created around a simple observation. Autonomous systems are gaining the ability to cause consequential effects. The organization still needs to remain the source of the power those systems exercise.
That leaves most teams choosing between two bad options. Keep the system weak, and it never does the work that justified it. Give it broad access, and nobody can say what it was actually authorized to do. Neither answer is a decision an organization can defend.
We are building the Authority Layer for Autonomous Systems. It is infrastructure for making delegated power explicit, bounded, operational, and independently provable.
What That Means In Practice
Four properties delegated power has to have.
Delegation already happens every day, informally, in credentials and configuration. The work is making it something an organization can state, limit, apply, and prove.
Explicit
The power a system holds is written down, in terms the organization actually approved.
Bounded
Delegated power has limits. The limits are set before the system acts, not argued afterwards.
Operational
The boundary applies at the moment of a consequential action. Not in a document reviewed later.
Independently provable
A reviewer can establish what authority governed an effect, without taking our word for it.
Where This Started
We did not start with an Authority slogan. We started at execution.
The depth in this system is not decoration. It is the residue of working the problem from the bottom up – and then discovering what the bottom could not answer on its own.
Where it started
We did not start with an Authority slogan. We started at execution.
The original problem was practical: how do you govern autonomous software when it stops recommending and starts changing real systems? Nothing about that question is answered by naming a category.
So the work went down first
Execution is where the hard parts were, so that is where we went.
Execution identity – which running thing is actually acting. Observation close to the kernel, so the picture does not depend on the agent describing itself. Enforcement inline, in the path of the action rather than in a report about it. Failure behaviour, decided deliberately rather than inherited. And cryptographically protected evidence of what actually happened.
What that exposed
The deeper we went into execution, the more obvious the missing layer above it became.
Technical capability and access were not enough to explain what organizational power the machine had actually been given. A system can be able to do something, be permitted by a credential to do it, and still never have been delegated it by the organization. Authority became the organizing principle because the execution architecture had already exposed the difference.
Why the system is shaped this way
Observe, Authority, Enforce, Proof and Learn are not five products.
They are parts of one lifecycle for autonomous power: understand the real execution surface, commit the power the organization is willing to delegate, hold execution inside it, preserve evidence of the resulting effect, and use that verified history to propose a better boundary next time. Building them separately is how the trust boundary gets lost between them.
How We Work
The principles the whole system is held to.
These are commitments, not features. They apply across the lifecycle – observation, delegation, enforcement, evidence and learning alike – and they decide what we build and, more often, what we refuse to claim.
The organization is the source of Authority.
Not the agent. Not the model. Not whoever made the request. Not WhiteFin. Software can propose a boundary. Only the organization can grant one.
Observe reality; never infer permission from it.
Watching what a system does tells you what it is reaching for. It does not tell you what it was allowed to reach for. Observation informs a decision an organization makes; it never quietly becomes the decision.
No probabilistic inference in the authoritative ALLOW path.
Models are probabilistic, and that is what makes them useful. The derivation of an authoritative ALLOW is not. A system may propose; it does not get to decide what it was authorized to do.
Failure may reduce availability. It may never increase power.
Things break. When they do, the acceptable outcome is that less gets done – never that something acquires authority it was not granted. Failure behaviour is a design decision, made in advance, not an accident discovered in an incident review.
Customers should not need WhiteFin in order to verify WhiteFin.
Evidence only we can check is weak evidence. WhiteFin produces cryptographically protected evidence for governed decisions that can be checked independently of the live WhiteFin runtime – and we state separately what that evidence establishes about integrity, provenance, Authority, decision, and effect, because those are different claims.
Learning recommends. Governance decides.
Verified execution history is the best material there is for a better boundary. It still only ever produces a proposal. Nothing learned turns itself into authority without the organization granting it.
Scope and coverage are declared honestly.
We say what is inside the governed scope and what is not, and we treat coverage as a separate question from enforcement. A control that does not cover something has to say so, before a customer finds out.
Who Is Building It
Gilad Gabay
Co-Founder & CTO
Background in secure systems architecture, compliance engineering, and production-grade distributed systems. Now building the infrastructure that lets an organization delegate real power to autonomous systems and keep authority over what they do with it.
Connect on LinkedIn →What can your organization not approve today?
Most teams have at least one AI system that could do valuable work and does not have permission to act. That is the conversation we want to have.
Discuss a blocked deployment →