Capability Floors and the Consequentiality Axis
A team operates a Phase 2 organisation. They have identity controls, basic supply chain verification, behavioural baselines, output validation. They feel ready.
They deploy a frontier-class model with code execution, browsing, and credential management. The agent operates at Phase 4 capability — frontier-class actions, autonomous tool use, persistent memory.
The organisation is now exposed to Phase 4 threats with Phase 2 defences.
This is the capability floor. It is also only half the picture. The other half — consequentiality — determines whether the floor mismatch is uncomfortable or catastrophic.
What the Capability Floor Is
A capability floor says: the rigor of your defence is bounded below by the capability of your agent. Not by the threats you have seen; not by the controls you have shipped; by what your agent can do.
If your agent can execute arbitrary code, your minimum defence rigor is the rigor needed for code-execution threats. If your agent can move money, your minimum is the rigor needed for financial-action threats. If your agent operates autonomously across multi-day mandates, your minimum is the rigor needed for delegated-autonomy threats.
You don’t get to argue with the floor. Capability sets it. What your agent can do is the threat surface, regardless of what threats have actually shown up yet.
This is structural. A frontier-capability agent in a Phase 2 environment has the threat surface of the frontier; the defences of Phase 2 are below the floor. The mismatch is not a vulnerability that hasn’t been exploited yet; it is a floor violation that can be exploited at any time, by any sufficiently-resourced adversary, with high probability.
What the Consequentiality Axis Adds
Capability gives you one number — what can the agent do. Consequentiality gives you a second — what does an action by this agent cost when it goes wrong.
These are independent. A high-capability agent doing low-consequence work is not the same threat as a high-capability agent doing high-consequence work. A medium-capability agent doing high-consequence work is also not the same as either.
The two axes form a grid:
| Low consequence | Medium consequence | High consequence | |
|---|---|---|---|
| Low capability | Phase 0-1 | Phase 1-2 | Phase 2-3 |
| Medium capability | Phase 1-2 | Phase 2-3 | Phase 3-4 |
| High capability | Phase 2-3 | Phase 3-4 | Phase 4-5 |
The phase you actually need is the max of what capability requires and what consequentiality requires. Not the average. The max.
A team that runs medium-capability agents on high-consequence actions cannot use medium-rigor defence. They need the high-consequence rigor. Capability does not relieve them of consequentiality’s demand.
A team that runs high-capability agents on low-consequence actions cannot use low-rigor defence. They need the high-capability rigor. The agent’s surface is what it is — even if the specific actions are low-cost, the surface for adversarial misuse is the high-capability surface.
The floor is the max of the two axes. Either axis can be the binding constraint.
Why This Pattern Matters
Two consequences follow:
1. You cannot trade rigor across the axes. A team sometimes thinks: our agent has high capability but only does low-consequence work, so we can run lighter defence. This is false. The capability sets the surface; the consequentiality sets the cost-per-failure; both must be defended at their own rigor level.
2. The floor moves over time. Models improve. New tool integrations expand capability. Action classes shift from low-consequence to high-consequence as the agent gets used for more important work. The floor that was correct six months ago is below the floor that is correct now. The capability floor is dynamic.
A framework that ships static defence levels — set once at deployment and not revisited — will be below the floor by the second model upgrade. The floor must be recalibrated when capability changes or when consequentiality changes.
The Recalibration Pipeline
Concretely, here is what it looks like to keep the floor honest:
Step 1: Inventory current capability. What model class? What tool surface? What modes of operation (sync, async, autonomous, multi-agent)? What memory shape (none, session, persistent)? Capability is not a single number; it is a vector across these dimensions. Inventory it.
Step 2: Inventory current consequentiality. What actions does the agent take? What are the costs of an action going wrong (financial, reputational, regulatory, physical)? Consequentiality, like capability, is a vector. Inventory it.
Step 3: Compute the floor. For each axis, identify the phase that capability requires and the phase that consequentiality requires. The floor is the max.
Step 4: Compare to current rigor. Are your defences at or above the floor? Where are they below? The cells where defences are below the floor are current gaps — not theoretical, not future, current.
Step 5: Re-run on every change. Model upgrade? Re-run. New tool integration? Re-run. New action class added to the agent’s mandate? Re-run. The floor moves; the recalibration is the discipline that keeps you above it.
A team that runs this pipeline quarterly will catch most floor violations before they are exploited. A team that doesn’t will discover floor violations the way they always get discovered: post-incident.
Why Capability Floor Beats Maturity Score
Most frameworks measure maturity by what has been built. You have shipped controls A, B, C; therefore you are at maturity level N.
The capability floor inverts this. It measures maturity by what is required given what you operate. You operate a frontier model with autonomous code execution; therefore your minimum maturity is level M, regardless of what you have shipped.
The inversion matters because the threat surface is set by what you operate, not what you have built defences for. The threats don’t care that you haven’t shipped Phase 4 controls yet. The threats are at Phase 4 the moment your agent is.
Maturity-by-construction is a self-flattering measure: you score yourself by the work you’ve done. Maturity-by-floor is an honest measure: you score yourself by the work that’s required given what you run. The difference between the two is the gap. The gap is where the next failure will land.
The Disposition
Capability floors and consequentiality axes together produce a discipline that is uncomfortable but useful: you cannot decide your defence level by what you’ve built; the level is decided by what your agent can do and what its actions cost when wrong.
This shifts the conversation. From we shipped these controls; what level does that put us at to our agent has these capabilities and these action costs; what level do we need to be at, and where are we below it?
Teams that adopt this discipline find their roadmap simplifies: the gaps between the required floor and the current rigor are the next investments. No prioritisation gymnastics, no debate about which control class is most important. The structural answer is the gaps.
Teams that don’t adopt this discipline keep building controls based on threats they have seen, while the threat surface expands faster than the defences. The floor moves up; the defences don’t keep pace; the next incident lands in the gap.
The floor is dynamic. Walk up it deliberately, ahead of the threats, against your specific capability-and-consequentiality vector. That is the engineering shape of staying above the floor.
