Six Ways to Fake a Trust Gate: Attacker Patterns and the Detectors That Catch Them

A trust gate is only as good as the update path behind it. You can put a beautiful min() on the action envelope, log every decision, and ship a dashboard that says "gated" -- and still have a system that quietly inflates its own authority every tick. The gate is the visible part. The fake happens upstream, in the law that moves trust from one step to the next.

This is a red-team listicle: six ways an implementation can look gated while the real update path leaks authority, each paired with the Prov 6 mechanism that detects it. Attacker versus detector. The attacker wants the trust score to keep rising smoothly with the gate apparently in place; the detector wants to catch the first illegal step before it is ever used.

The central instrument is the per-step certificate, kappa_t -- a residual computed every tick against the canonical multiplicative trust-transfer law:

kappa_t = || H( log A_{t+1} - (1 - alpha_t) log A_t - alpha_t log R_t ) H ||_F
# within floor_t  <=>  this step obeyed the canonical trust-transfer law
# above floor_t   =>   contract / suspend / close the action envelope

A_t is the prior trust matrix, R_t the incoming evidence, alpha_t the blend weight. The full derivation lives in Trust you can falsify. Here we point it at six concrete fakes. One note throughout: floor_t is a per-platform, per-deployment calibrated noise floor, not a universal magic constant. There is no cross-platform 1e-9.

1. Arithmetic Interpolation Instead of Multiplicative Update

How the fake works. The canonical law is multiplicative in the trust state. The attacker -- or, more often, a well-meaning contractor "optimizing" the kernel -- swaps it for a cheaper arithmetic blend: A_{t+1} = (1 - alpha_t) A_t + alpha_t R_t. On a dashboard the two are nearly indistinguishable; the trust score still rises and falls smoothly, and the logs say nothing.

The narrative. A vendor profiles the hot loop, sees the matrix logarithm dominating the per-tick cost, and replaces it with a linear interpolation "that gives basically the same numbers." It does, on the boundary cases they tested. It does not on the interior. Authority now accrues along a different curve than the gate was calibrated against.

The detector. kappa_t does not ask whether the number looks reasonable. It asks whether this exact step obeyed the multiplicative law. Arithmetic interpolation does not, so the residual goes above floor_t on the first interior step, and the high-risk action classes close before anyone notices the dashboard still looks fine. Example 2 in the patent [0091].

2. Soft-Min / Weighted-Average Gate Instead of Hard Min

How the fake works. The real gate is min(C_inst, C_ctx) -- the weakest channel constrains the output. The attacker replaces it with a soft blend: g' = w * C_inst + (1 - w) * C_ctx. Now a high contextual trust can paper over a low instantaneous reading. The system "feels" gated, but a single strong channel buys authority the weak channel never earned.

The narrative. A prompt injection nudges the system toward a soft-min reading -- "you've known this user for weeks, weight the relationship history over this one odd message." Under a hard min, the odd message (low C_inst) clamps the envelope regardless of history. Under the smuggled-in soft-min, history dilutes the alarm and the envelope stays wide open exactly when it should clamp. C7: prompt injection and the soft-min gate takes this apart in full.

The detector. Two things fire. A gate audit checks that the executed gate is the hard min, not a weighted average. And because a soft-min changes the realized trust trajectory, it shows up as kappa_t residual against the canonical update. Example 3 [0092].

3. Non-Diagonal Gauge Substitution Dressed Up as "Normalization"

How the fake works. The subtle one. The trust state has gauge degrees of freedom -- a normalization (the doubly-stochastic / Sinkhorn-Knopp projection) that rewrites the state in a canonical frame without changing the causal trust dynamic. A legitimate normalization vanishes under the H(.)H projection inside kappa_t. The attacker hides a real content change inside what is presented as a normalization step, hoping it slides through as bookkeeping.

The narrative. Worth stating plainly because it is a legitimate "fake" in its own right: presenting the normalization as the trust law. The Sinkhorn-Knopp projection is gauge presentation, not the causal update; the thing that actually moves trust is the quotient-affine contraction (QAC). An implementation that routes authority changes through the normalization and labels them "just renormalizing" is making a content change wear a gauge costume. C4: the normalization is not the trust dissects this confusion in full.

The detector. A pure gauge move projects to zero under H(.)H; a content change does not. So a non-diagonal substitution carrying real trust content survives the projection and lands as kappa_t above floor_t. The normalization is exactly the part the certificate is built to see through. Failure-mode table entry [0110].

4. Endpoint Shortcut at alpha in

How the fake works. The certificate certifies the interior of a blend. The endpoints -- alpha_t = 1 (claim full transfer) or alpha_t = 0 (claim none) -- are exactly where kappa_t alone does not certify behavior. An attacker who knows this drives the update to an endpoint and takes an unauthorized branch there, betting the interior residual stays quiet because there is no interior to check.

The narrative. A code path special-cases "perfect evidence" by jumping straight to alpha_t = 1 and copying R_t wholesale into A_{t+1}, skipping the blend. To the interior residual this looks like nothing happened. Authority is granted at the endpoint, off the certified path.

The detector. Endpoints get their own structural verifier -- a separate check on endpoint and path, not the interior residual. kappa_t staying small does not certify alpha_t in {0,1}; the endpoint verifier does. The architecture wires both. Example 4 [0093].

5. Forbidden-Category Write Into a Floored Coordinate

How the fake works. Some trust coordinates are floored to zero by policy -- categories the agent is structurally forbidden from accruing authority in. The attacker crafts evidence so that, after the update, mass lands on one of those floored coordinates, trying to open an action class that policy says must stay dark no matter how much "trust" accumulates elsewhere.

The detector. A precheck runs before the write commits, and the policy mask enforces the floor. Mass directed at a pinned coordinate is caught at precheck and masked out -- the write never lands. Example 5 [0094]. One honesty note: the full pinned-zero / support-strata mathematics is not solved here. This is precheck-and-mask enforcement of declared forbidden coordinates, not a closed-form proof that no path ever reaches them.

6. Target Thrashing -- Canonical Each Tick, Lurching Across Ticks

How the fake works. Each individual tick can look perfectly canonical -- kappa_t within floor every step -- while the target R_t lurches between ticks. No single step is illegal, but the sequence of targets is incoherent, ratcheting authority through a series of locally-legal jumps.

The narrative. The evidence stream is steered so every tick's update is a clean, law-abiding blend toward a target -- but the target jumps tick to tick, each jump small enough to look like normal evidence flow, the cumulative drift large enough to inflate authority. Per-step falsification passes; the run is still wrong.

The detector. This is why per-step kappa_t is necessary but not sufficient. A run-level monitor B_t certifies whether a run stayed inside its monitored envelope over its history, and a target-stability term delta_t flags an R_t that lurches out of envelope. Example 6 [0095]. Note carefully: B_t certifies that monitored conditions held over the run. It does not prove the trust trajectory converges. Convergence is not a claim Prov 6 makes.

The Six at a Glance

What This List Is, and Is Not

This is six detectors for six specific excursion classes. It is not a completeness claim and not a security proof. These are the regressions Prov 6 is designed to catch -- the ones we have characterized, named, and wired a detector to. There is no theorem here that no other failure exists, and we will not pretend there is. A novel attack that fits none of these six categories is entirely possible; the honest claim is that these six are caught, on the first illegal step, by an independently checkable instrument.

That is the whole difference from a score-and-story system. A trust score with good logging is still an assertion: the number moved, the log explains it, you trust both. Each fake above keeps the score smooth and the log clean. The certificate is an artifact a third party recomputes from the logged matrices and compares against the calibrated floor. The fakes that change the realized update get caught by kappa_t; the ones that don't (endpoints, forbidden writes) get caught by the structural verifier, the policy mask, or the run monitor. Falsifiable beats explainable.

The QAC update, certificate computation, endpoint verifier, policy mask, and B_t run monitor are implemented in ccf-core on crates.io. Demonstrations that apply those primitives to a robot, fleet, or LLM still need their own integration evidence. The patent claim structure is on the patent page.

— Colm Byrne, Founder — Flout Labs, Galway, Ireland

Patent pending — US Provisional 64/092,485 (filed June 17, 2026).

FAQ

So does running all six detectors make the agent unhackable?

No, and this is the misreading the post exists to correct. The six detectors catch six named excursion classes -- the regressions Prov 6 was built to detect. That is a deliberately narrow, honest claim, not a completeness result and not a security proof. A novel attack that fits none of the six categories is possible, and nothing here rules it out. What the list buys you is that these specific fakes -- the ones that slip past dashboards and logs -- are caught on the first illegal step by an instrument a third party can recompute. "Caught these six" is the claim. "Unhackable" is not. The detectors share a common shape across the platforms we have applied them to -- structurally equivalent under a common abstract schema, not formally isomorphic; the calibrated floor and policy-mask coordinates stay local to each deployment.

Isn't the doubly-stochastic / Sinkhorn-Knopp normalization the thing that actually controls trust here?

No -- and fake number 3 is precisely the attack that presents it as if it were. The normalization is gauge presentation: a canonical way to write the trust state down, which vanishes under the H(.)H projection inside kappa_t. The causal update -- the law that actually moves trust step to step -- is the quotient-affine contraction (QAC). Treating the normalization as the trust dynamic is the single most common error people make reading this work, which is why a substitution dressed as "normalization" is one of the six fakes. C4: the normalization is not the trust takes it apart.

If kappa_t stays within floor_t every step, is the run safe?

No. Per-step legality is necessary, not sufficient -- fake number 6 (target thrashing) is the counterexample: every tick canonical, the run still wrong. A separate run-level monitor B_t certifies whether the run satisfied its monitored conditions over its history, and even B_t does not prove the trust trajectory converges. Prov 6 explicitly disclaims unconditional convergence. Endpoints (alpha_t in {0,1}) and forbidden-coordinate writes also need their own checks -- the endpoint structural verifier and the policy mask -- because kappa_t alone does not cover them.

Is floor_t a universal threshold, like 1e-9?

There is no universal threshold. floor_t is a per-platform, per-deployment calibrated value -- the noise floor of the specific hardware, arithmetic precision, and sensor stack. A residual that reads "zero" on one platform may sit above the floor on another with cleaner arithmetic. Anyone quoting a single fixed cross-platform number is overclaiming. Calibrating floor_t honestly per deployment is part of using the certificate correctly.