01
A named human owns it
Every policy, every system, every department has a person with authority to intervene and accountability for the outcome. Legal accountability requires a person.
How We Work
Observe. Derive. Approve. Enforce.
Nothing is enforced until a named human has approved it, and every decision afterwards is recorded with the reason attached. The same sequence applies to a services engagement: measure what actually happens before designing what should.
The Product Method
Four steps. Shadow mode runs first.
You see what your agents actually hold before anything changes, and you decide whether to enforce it.
01
Observe
The gateway runs in learn mode alongside your agents. Nothing is blocked. It records which capabilities each task actually uses and which sit unused. Two weeks. Output: the gap between held and used.
02
Derive
From observed behaviour we generate a candidate least-privilege policy per task class, plus the composition paths that exist today but should not. Suspicious observations are filtered before they influence the policy.
03
Approve
A named human reviews and approves. Nothing is enforced automatically. Policy files are signed, so a changed file is detected and never loaded.
04
Enforce
Every call is verified against the approved policy at runtime. Denials are logged with the reason. When an injected instruction arrives, the agent attempts the action and fails, because that capability was never granted.
The Services Method
Audit first. And the audit is separable.
Every engagement opens with a measurement, not a proposal. You can stop after it, and some departments should.
01
Measure what the department actually does
Task by task, observed rather than described. Interviews with the people doing the work, not only the person who manages it. The gap between the documented process and the real one is usually the most valuable finding.
02
Classify every task
Execution, decision, authority or governance. Execution automates. Decisions get AI assistance but stay human. Authority never moves. The ceiling is arithmetic on this classification, not an opinion.
03
State the ceiling in writing
Before any build. Including when the number is low enough that we recommend against proceeding. That happens, and it is the reason the audit is sold separately.
04
Build with governance active from day one
Provenance, sampling and authority limits go in with the first deployment. Retrofitting them means rebuilding, which nobody funds, which means it does not happen.
05
Supervised run before trust
The system operates with every output reviewed before it takes effect. This is where the real exception cases surface and where the ceiling gets corrected if the audit was optimistic.
06
Hand it over and leave
Documentation, the sampling process, the drift indicators, and training for whoever owns it afterwards. We do not stay on as a dependency.
What Does Not Change
Three things that hold either way.
Whether it is the product or an engagement.
02
The limit is stated first
Autonomy ceilings for departments, capability sets for agents. Published before the work starts, not discovered afterwards.
03
Failures get measured
Sampling, drift detection, and a reported error rate. We would rather be the company with a visible error rate than the one with an invisible one.
See it run on
your own agents.
Shadow mode for two weeks. Nothing is blocked and no agent code changes. You receive a report showing exactly what would have been allowed, escalated and denied.