Four Controls Are Not Four Lines of Defence
The trust cost frontier: why trustworthy AI needs independent assurance, bounded verification, and an economics of when to stop adding controls
Keywords: trustworthy AI, MLOps, DevSecOps, cloud-native AI, AI assurance, formal verification, software provenance, correlated failure, common-mode failure, transparency logs, Merkle trees, AI governance, Kubernetes, software supply chains
There is a simple way to make an artificial-intelligence system look trustworthy: add controls.
Add another validation stage. Add another signature. Add another approval gate. Add another monitoring service. Add another policy engine. Add another dashboard. Add another provenance record. Add another compliance check. Then count them.
Four controls must be better than three. Ten controls must be better than four. A system with twenty-seven green ticks on a governance dashboard must surely be safer than a system with only nineteen.
That reasoning is attractive, measurable, administratively convenient, and potentially wrong.
The problem is not that controls have no value. They plainly do. The problem is that controls are not independent merely because they have different names. Two controls can share the same signing root. Three controls can depend on the same policy configuration. Validation and authorisation can rely on the same continuous-integration runner. Monitoring and authorisation can depend on the same identity provider. A fleet of nominally distinct controls can therefore collapse onto a surprisingly small number of actual failure domains.
There is a second problem. Assurance is not free. Every test consumes compute. Every gate adds delay. Every human approval consumes attention. Every monitor adds infrastructure. Every policy check can block a valid release. Every rollback system can roll back a deployment that was not actually broken. Every provenance mechanism produces evidence that must be generated, stored, transmitted, committed, checked, and governed.
There is a third problem, and in some ways it is the most dangerous: verification is often asked to prove more than it can prove.
A cryptographic digest can establish that a disclosed artefact is identical to the artefact represented by that digest. It cannot establish that the model is good.
A signed deployment approval can establish that a particular key signed a particular record. It cannot establish that the human associated with that key understood the decision.
A test record can establish that a specified test produced a recorded result. It cannot establish that the test was the right test.
A transparency log can establish that an item was committed to an append-only structure. It cannot transform a false statement into a true one.
These three problems — cost, dependence, and evidential overclaiming — are the basis of a research project I am developing on what I call the trust cost frontier.
The central proposition is straightforward:
Trustworthy AI engineering should optimise independent, verifiable assurance rather than maximise the number of controls.
That sounds obvious after it has been stated. It is much less obvious in the architecture of real systems.
This post sets out the research idea, the engineering framework, and preliminary results from a cloud-native prototype. The results are deliberately reported with one qualification: the dependence and bounded-verification experiments are already strong, while the full economic frontier still requires additional ablation runs before I would treat the complete frontier as established. That distinction matters. A research programme about trustworthy evidence should not begin by overstating its own evidence.
Trustworthy AI is an engineering problem before it is a slogan
The contemporary trustworthy-AI literature and standards landscape contains a great deal of sensible guidance. The National Institute of Standards and Technology’s Artificial Intelligence Risk Management Framework treats AI risk management as a lifecycle activity and organises it around the functions Govern, Map, Measure, and Manage (Tabassi, 2023). The later Generative AI Profile extends the framework for generative systems and places particular emphasis on the risks, evaluations, and governance practices associated with that technology (Autio et al., 2024).
There is also an established body of software-security practice. NIST’s Secure Software Development Framework treats secure development as a set of practices that must be incorporated into the software lifecycle rather than bolted on after deployment (Scarfone et al., 2022). NIST SP 800-53 distinguishes security functionality from assurance — the confidence that the security capability actually works as intended — and provides a broad control catalogue rather than pretending that one control can solve every problem (Ross & Pillitteri, 2020). Its companion assessment publication addresses how those controls are assessed (Pillitteri, 2022).
Cloud engineering adds another layer. Mature MLOps is not simply “put a model in a container.” Production machine-learning systems combine source control, build systems, model registries, metadata, deployment services, validation, monitoring, serving infrastructure, and orchestration. Google Cloud’s MLOps architecture guidance explicitly treats automation, testing, metadata, deployment, and monitoring as parts of an integrated production system rather than adjuncts to the model itself (Google Cloud, 2024).
Supply-chain frameworks make a related point. SLSA describes progressively stronger guarantees for software artefacts and provenance, while its verification guidance requires verifiers to compare artefacts and provenance against expectations rather than treating the mere existence of provenance as sufficient (SLSA Community, n.d.). Sigstore’s Rekor provides an append-only transparency log for software-signing metadata and supports inclusion and integrity verification (Sigstore, n.d.). Kubernetes admission control provides mechanisms for intercepting and evaluating changes to cluster resources before persistence, creating a natural enforcement point for deployment policy (Kubernetes Authors, n.d.).
All of this is useful.
But there is a gap between having controls and knowing what those controls collectively buy.
Consider a production AI deployment pipeline containing four control classes:-
artefact verification;
-
pre-deployment validation;
-
deployment authorisation;
-
runtime monitoring and rollback.
A governance inventory will say: four controls.
An engineer should ask a different question:
How many independent ways does this architecture have to notice or contain failure?
Those are not the same quantity.
Control count is not assurance
Suppose artefact verification checks a model digest and a container digest. Validation executes a canary test. Authorisation checks an approval signature. Monitoring watches the live service and rolls back a bad deployment.
On paper, this is a respectable architecture.
Now suppose artefact verification and authorisation both depend on the same signing root. Validation and authorisation both depend on the same policy configuration. Authorisation and monitoring depend on the same identity provider. Monitoring depends on the same telemetry bus used elsewhere in the operational stack.
The organisation can still report four controls.
The system does not have four independent lines of defence.
That distinction is the first part of the trust cost frontier.
In the current prototype, I constructed two full four-control architectures. The first, B2, deliberately separates dependency paths. The second, B3, uses the same nominal controls and the same substantive thresholds but introduces shared dependencies.
The purpose is not to compare “more security” with “less security.” It is to hold the nominal control count constant and change the topology underneath it.
Figure 1. Four controls can represent very different amounts of independent assurance.
The measured result is the sort of result I wanted the experiment to be capable of producing.
Both B2 and B3 have four nominal controls. Yet the measured aggregate detection rate was 1.000 for B2 and 0.800 for B3. The difference was 0.200, with a 95% confidence interval of approximately 0.169 to 0.234. Residual failure was 0.000 for B2 and 0.200 for B3.
The comparison is particularly stark in the suppressed-runtime-alert scenario. The independent architecture detected the injected failure in every run. The architecture that depended on the shared telemetry path detected it in approximately one percent of runs.
That does not mean “correlation always costs 99 percentage points of detection.” It means something much more specific and defensible: if the failure being tested suppresses the same telemetry path on which the monitor depends, an independent observation path can be radically more valuable than another nominal control attached to the compromised channel.
A second common-mode experiment corrupted shared dependencies. In the high-dependence architecture, corruption of a common policy configuration impaired two controls at once and, under that condition, left a residual failure rate of 1.000. The same nominal collection of controls behaved differently because its dependency graph behaved differently.
This is the engineering version of an old lesson in finance: counting positions tells you little about diversification if they all load on the same factor.
A portfolio containing ten securities can have one underlying risk.
An AI assurance architecture containing ten controls can have one underlying failure domain.
The economic question: when is another control worth buying?
Once control dependence is recognised, the next question is economic.
A trustworthy system is not built by minimising cost regardless of risk. Nor is it built by minimising risk regardless of cost. In real engineering, both matter.
The simplest form of the model is:
J(S) = C(S) + D(S) + L × P_F(S)
where:-
S is the selected set of assurance controls;
-
C(S) is the direct engineering and execution cost of those controls;
-
D(S) is operational cost, including deployment delay, coordination, false blocks, and unnecessary intervention;
-
L is the loss associated with an uncontrolled deployment failure;
-
P_F(S) is the residual probability that the selected architecture fails to prevent, detect, or contain the relevant failure;
-
J(S) is total expected cost.
The important part is not the notation. The important part is what follows from it.
A new control should not be added merely because it reduces risk. Almost any functioning control can reduce some risk. The question is whether the expected reduction in loss exceeds the additional cost the control introduces.
In plain form:
Expected loss avoided by the new control > additional control and operating cost
Or, a little more explicitly:
L × [P_F(before) - P_F(after)] > added cost + added operational burden
That is the decision rule.
It immediately gives us a reason why the optimal assurance architecture can change across applications.
A model that recommends films and a model that controls access to a power system should not have identical assurance budgets. The loss term is different.
A ten-second approval delay may be negligible for a weekly model release and intolerable for an automated recovery action during a live incident. The delay term is different.
A duplicate monitor may be valuable if it observes the service through an independent path and nearly worthless if it reads the same corrupted telemetry stream. The residual-risk reduction is different.
Trustworthiness therefore cannot be reduced to a universal checklist. The same control can be rational in one system and wasteful in another.
Preliminary evidence of a real break-even frontier
The current prototype has not yet executed every possible combination of the four control classes. That matters, and I will return to it. But three configurations already have directly measured low-dependence outcomes that allow a useful preliminary calculation.
The measured configurations are:-
no structured assurance;
-
AV: artefact verification plus validation;
-
AVZM: artefact verification, validation, authorisation, and monitoring.
For these executed configurations, the measured normalised assurance costs and residual failure probabilities are approximately:
ConfigurationAssurance costResidual failure probabilityNone0.0001.000AV0.6220.368AVZM19.0000.000
Those numbers produce two break-even values.
The first occurs when the expected cost of doing nothing becomes equal to the expected cost of using artefact verification plus validation. That crossover is approximately:
L* ≈ 0.985 normalised loss units
The second occurs when AV and the full four-control architecture have equal total expected cost:
L* ≈ 49.895 normalised loss units
That gives a simple preliminary result:-
below about 0.985 loss units, no structured assurance is cheapest under this calibration;
-
between about 0.985 and 49.895 units, AV is cheapest;
-
above about 49.895 units, the full four-control architecture is cheapest.
The point is not the specific numeric value of “49.895.” These are normalised engineering units, not dollars, pounds, euros, or baht. The experiment has not observed a monetary loss from a real production catastrophe, and it would be misleading to pretend otherwise.
The point is the existence of switching regions.
Figure 2. The cost-minimising assurance architecture changes with the value at risk.
This figure captures what I mean by a trust cost frontier more clearly than a control checklist ever could.
When the consequence of failure is trivial, expensive assurance is irrational.
When the consequence becomes material, a partial architecture becomes worthwhile.
When the consequence becomes large enough, the full architecture dominates despite its higher operating cost.
This is not an argument for fewer controls. It is an argument for justified controls.
There is a very important caveat. The current full frontier calculation also contains model-implied values for combinations that have not yet been experimentally executed. I do not regard those extrapolated points as equal in evidential status to the measured points above. The next engineering cycle will therefore execute true leave-one-control-out configurations and, ideally, the remaining combinations, so that the frontier is predominantly empirical rather than a mixture of observed and model-implied values.
That is precisely why Figure 2 uses only the configurations that have actually been run.
Why the initial sensitivity analysis taught us something by failing
The first sensitivity analysis produced a superficially boring result: every tested loss profile selected all four controls.
Low loss: all four.
Medium loss: all four.
High loss: all four.
Scale direct costs up: all four.
Scale operational costs up: all four.
Scale losses over the initial range: all four.
At first glance, that could be reported as evidence that the full architecture is robustly optimal.
It should not be.
The more useful interpretation is that the sensitivity range was badly positioned for the question we wanted to answer.
The lowest initial loss profile was 500 normalised units. Yet the empirically implied switch from AV to the full architecture occurs at roughly 49.9. The analysis began an order of magnitude above the interesting transition.
That is a methodological lesson worth making explicit.
Sensitivity analysis is not a ritual in which one perturbs coefficients by 25 percent or 400 percent and congratulates oneself when the conclusion survives. A sensitivity analysis is useful only if it explores the region in which the decision could plausibly change.
If the threshold is near 50 and the smallest value tested is 500, “robustness” is largely an artefact of choosing an uninformative range.
The next iteration therefore needs to sweep the loss parameter across several orders of magnitude and calculate exact break-even points rather than relying on a coarse grid.
This is another reason I prefer the frontier language. It forces the researcher to ask where the decision changes.
Correlation changes marginal value
The cost model becomes more interesting once shared dependencies are introduced.
If controls fail independently, the chance that they all miss the same problem can fall rapidly as controls are added. If they share a common cause, that intuition breaks.
A compact common-cause representation is:
P_F(S) = γ + (1 - γ) × product of conditional control-failure probabilities
Here, γ represents a common-cause component. If γ is zero, the model approaches the independent case. As γ rises, adding controls that share the common cause produces less marginal protection.
Again, the notation is less important than the architecture it represents.
Imagine two runtime monitors.
Monitor A reads the service’s normal telemetry stream.
Monitor B is a separate process, owned by a different team, running on a different account, but it reads the same telemetry stream.
Administratively, there are two monitors.
Functionally, a telemetry suppression attack can blind both.
Now compare that with Monitor C, which probes the service externally, through a separately authenticated path, and tests behaviour rather than trusting the internal health report.
Monitor C might be much simpler than Monitor B. It might even collect less data. Yet it can add more assurance because it introduces a genuinely different observation mechanism.
This is why “defence in depth” must mean more than stacking products.
Depth is not the vertical height of the software bill.
Depth is independence of failure modes.
Verification must be bounded by the claim
The second major part of the project is a verification framework.
Modern software supply chains already provide useful building blocks for this. SLSA provenance is designed to provide verifiable information about where, when, and how an artefact was produced, and its verification guidance explicitly requires comparison against expectations (SLSA Community, n.d.). Sigstore combines identity-bound signing with transparency logging, while Rekor provides an append-only record against which inclusion and integrity can be checked (Sigstore, n.d.). Certificate Transparency demonstrated the broader value of append-only Merkle-tree logs for making important security events auditable (Laurie et al., 2013).
Those are valuable primitives.
But cryptographic validity and semantic validity are different things.
The prototype therefore introduces an evidence-to-claim registry. An evidence object is not allowed to support every proposition that someone would like to infer from it. It can support only claims registered for that evidence type, subject to the required assumptions.
The basic principle is:
Valid evidence can be authentic and still be insufficient for the claim being asked of it.
Consider the following table.
Evidence objectWhat it can supportWhat it cannot establish by itselfModel or container digestThe disclosed artefact matches the committed artefactThe model is accurate, safe, unbiased, lawful, or appropriateValidation recordThe specified validation produced the recorded resultThe test suite was complete or the test was substantively adequateApproval signatureThe specified key signed the disclosed deployment recordThe associated human understood the decision or exercised independent judgementRuntime event recordThe disclosed event was recorded and committedNo unrecorded event occurredMerkle inclusion proofThe evidence item belongs to the committed setThe evidence item is truthfulAppend-only commitmentThe committed record existed by the relevant ordering point and has not been silently replaced within the verified log historyThe underlying real-world event necessarily occurred as described
That last distinction is critical.
A blockchain, transparency log, or other append-only commitment mechanism is very good at answering questions of the form:-
Was this exact record committed?
-
Was this artefact included?
-
Has this disclosed object changed?
-
Does this signature verify under this key?
-
Does this evidence correspond to this root?
It is not an oracle.
A beautifully signed lie remains a lie.
A perfectly hashed bad model remains a bad model.
A valid approval signature generated using a compromised trusted key remains cryptographically valid even though the authority behind it has failed.
This is why the verifier in the prototype can return “integrity valid” while refusing the requested substantive claim.
The bounded-claim result is stronger than a tamper detector
The current verification suite contains ten mandatory verification cases.
They include:-
valid evidence for a registered claim;
-
valid evidence for an unregistered claim;
-
modified evidence;
-
a proof belonging to another leaf;
-
a valid proof checked against the wrong root;
-
a root absent from the commitment log;
-
a signature from an untrusted key;
-
a signature from a compromised but formally trusted key;
-
a missing claim-registry version;
-
an attempted claim-registry downgrade.
Across the implemented test suite, 314 tests passed with no failures or skipped tests in the reported full run. Coverage exceeded 90 percent for the cryptographic, verification, schema, and designated analysis modules.
For deliberate evidence mutation, the verifier rejected all 48 constructed mutation cases across six evidence types and eight mutation classes. I treat that as a conformance result, not as a probabilistic statement about “100 percent of attacks.” The mutation cases are deliberately generated tests, not a random sample from an unknown universe of adversarial behaviour.
The more interesting result involves unsupported claims.
Across 8,291 requests in which canonicalisation, digest, inclusion, and commitment checks were valid, the verifier refused every requested claim that was not registered as supported by the evidence.
That is the point of the architecture.
A normal tamper detector asks:
Has this object changed?
A bounded-claim verifier additionally asks:
Even if this object is genuine, what exactly are you entitled to conclude from it?
That is a much more useful question for trustworthy AI.
Evidence should be compact, selective, and independently checkable
The architecture borrows an important idea from scalable blockchain and transparency-log systems: do not put every piece of operational data into the global commitment layer.
A production AI system generates far too much evidence for that to be sensible.
Instead, the prototype keeps detailed operational evidence off the commitment medium. Each evidence object is canonicalised and hashed. The hashes are assembled into a Merkle tree. The root is committed to an append-only medium. A later verifier receives the evidence object, the relevant inclusion proof, the root, signatures, and the applicable claim mapping.
The result is selective disclosure.
A verifier checking one deployment event does not need every event generated by the system.
This is a familiar pattern in transparency systems. Certificate Transparency uses append-only Merkle trees to make log history auditable (Laurie et al., 2013). Rekor similarly uses verifiable log structures for software-signing metadata (Sigstore, n.d.). The engineering novelty here is not “Merkle trees exist.” It is the integration of compact commitment with a bounded semantic layer for AI deployment evidence and a cost model for deciding which assurance controls should exist in the first place.
The measured overhead in the current prototype is modest.
For the full four-control configurations, evidence generation was around four to five milliseconds per run in the no-fault measurements. The detailed off-medium evidence was approximately 5.6 to 5.7 kilobytes. The commitment record was about 503 bytes. Mean verification latency across more than sixteen thousand evidence verifications was approximately 1.214 milliseconds.
Those figures should not be universalised. They come from a small testbed, not hyperscale production.
But they establish an engineering point: bounded, selectively disclosed verification does not require placing the entire AI lifecycle on-chain or forcing every auditor to ingest the complete operational record.
Why this matters for DevOps and cloud systems
The trust cost frontier is not an abstract AI-ethics model. It belongs in the deployment pipeline.
The natural implementation points already exist.
A model and container can be identified by digest.
Continuous integration can create validation evidence.
An admission or policy layer can block deployments that lack required evidence. Kubernetes admission controllers are specifically designed to intercept requests to create or modify resources before persistence, making them a natural enforcement point for machine-verifiable deployment predicates (Kubernetes Authors, n.d.).
An authorisation service can require a valid approval record.
A monitoring service can observe the live deployment and trigger rollback.
The evidence generator can canonicalise the outputs of those controls.
A commitment service can batch evidence hashes into a root.
A verifier can check integrity, inclusion, signatures, registry versions, and allowed claims.
The point is not to replace MLOps with blockchain.
It is not to “decentralise Kubernetes.”
It is not to turn every inference into a transaction.
It is to separate operational execution from compact verification.
That separation is important because trust mechanisms themselves can become operational liabilities. If every assurance event requires a slow global consensus process, assurance can destroy availability. If every record must be publicly disclosed, assurance can destroy confidentiality. If every verifier must replicate the entire operational history, assurance can become economically absurd.
The better architecture is layered:
Operational layer: builds, tests, authorises, deploys, monitors.
Evidence layer: records what those processes did.
Commitment layer: preserves compact integrity commitments.
Verification layer: checks disclosed evidence and returns only supported claims.
Governance layer: handles the things the technical verifier cannot establish.
This last layer must remain explicit.
A technical system can prove artefact identity.
A governance process may still need to decide whether deploying that artefact was wise.
Trustworthy AI requires trustworthy roots, not just trustworthy leaves
There is a subtle recursive problem in assurance engineering.
Every control has assumptions.
A signature assumes something about the key.
A key registry assumes something about identity management.
A policy engine assumes something about the policy configuration.
A monitor assumes something about the telemetry path.
A model digest assumes something about the binding between the approved artefact and the artefact actually executed.
A provenance statement assumes something about the system that generated the provenance.
SLSA’s verification model recognises this explicitly through roots of trust and expectations (SLSA Community, n.d.). Sigstore likewise has a trust-root model surrounding certificate and transparency-log verification (Sigstore, n.d.).
The trust cost frontier adds an economic and dependency perspective to the same issue.
If five controls terminate at the same root, then the root deserves more attention than the count of leaves.
This also changes how an organisation should spend its next dollar of security budget.
Suppose an organisation has four controls and all four ultimately depend on one identity provider. It has two choices:-
add a fifth control that also depends on the identity provider; or
-
make one existing control independent of it.
A checklist tends to reward the first choice because the control count increases.
A dependence-adjusted assurance model may strongly prefer the second.
That is the kind of decision the trust cost frontier is intended to make visible.
False assurance is a measurable engineering outcome
The phrase “false assurance” is often used rhetorically. It should be measurable.
Imagine an additive governance score:-
artefact verification present: +1;
-
validation present: +1;
-
approval present: +1;
-
monitoring present: +1.
Both B2 and B3 score four.
Yet their measured outcomes differ.
That means the score is omitting information.
The omitted information is the dependence structure.
A more useful assurance representation therefore needs at least three quantities:-
nominal controls;
-
independent failure domains;
-
realised performance under relevant faults.
One can go further and define an apparent assurance measure and an actual assurance measure. The gap between them becomes the false-assurance gap.
This is not merely an academic distinction. Governance systems increasingly rely on dashboards, maturity models, policy-as-code, automated attestations, and compliance evidence. These are useful only if their measurement model corresponds to the failure mechanisms that matter.
A dashboard can be perfectly accurate about the number of controls and still be wrong about the system.
The attack surface is larger than the model
NIST’s adversarial machine-learning taxonomy is useful here because it treats AI security as a lifecycle problem involving different attack goals, capabilities, and stages rather than as a single phenomenon called “adversarial examples” (Vassilev et al., 2025). MITRE ATLAS similarly catalogues adversarial tactics and techniques against AI-enabled systems based on observed and demonstrated behaviour (MITRE, n.d.).
For production engineering, that means the model file is only one target.
An adversary may attack:-
the model artefact;
-
the container image;
-
the build pipeline;
-
the validation evidence;
-
the signing key;
-
the identity provider;
-
the policy configuration;
-
the model registry;
-
the deployment manifest;
-
the telemetry bus;
-
the monitor;
-
the rollback mechanism;
-
the evidence store;
-
the claim registry;
-
the commitment process.
This is why formal reasoning about the pipeline matters.
“Model safety” and “system trustworthiness” are not synonyms.
A robust model deployed through a compromised pipeline can be untrustworthy.
A cryptographically pristine pipeline deploying an unsuitable model can also be untrustworthy.
The architecture must represent both truths without collapsing them into one score.
A compromised trusted key demonstrates the difference perfectly
One of the verification tests is deliberately uncomfortable.
Suppose an approval is signed with a key that is formally trusted by the registry. The cryptographic signature is valid.
Now suppose that key has been compromised.
What should the verifier say?
A naïve system has two bad options.
It can say “signature invalid,” which is false. The signature is mathematically valid.
Or it can say “approval valid,” which overstates what has been established.
The bounded verifier separates the claims.
It can report that:-
the signature verifies;
-
the key is one recognised by the relevant trust structure;
-
a compromise condition is recorded;
-
the authority claim is therefore withheld;
-
a still broader claim such as “the human exercised informed judgement” is not supported at all.
This may sound fussy.
It is exactly the sort of fussiness trustworthy systems need.
The difference between “the signature verifies” and “the decision was properly authorised” is small linguistically and enormous logically.
What the current experiment does not prove
A credible research programme should have a section devoted to what the current evidence does not establish.
First, the three-node k3s testbed is logically distributed but hosted on one physical machine. Shared-infrastructure failures are therefore implemented at the application dependency layer rather than by destroying genuinely separate physical infrastructure. The software topology is real; the physical fault independence is not equivalent to a multi-region production deployment.
Second, the loss values are calibrated normalised units. The experiment measures engineering quantities such as latency, CPU time, bytes, detection, and recovery. It does not observe the monetary cost of a bank outage, medical error, market failure, or industrial accident. Monetary interpretation therefore belongs to a later application-specific calibration.
Third, the current full frontier includes twelve control combinations whose residual probabilities are model-implied rather than directly executed. That is why I do not use those points as the evidential foundation of this article.
Fourth, the first “ablation” analysis is observational because existing configurations differ in more than one control at a time. True leave-one-out runs are required.
Fifth, timing measurements show host-period effects. Two functionally equivalent full-control architectures measured at different periods produced materially different deployment times. The next cycle should therefore randomise and interleave configurations, with contemporaneous controls, rather than treating measurements taken at different times as perfectly exchangeable.
Sixth, the experiment addresses deployment-stage assurance. It does not claim to solve training-data governance, fairness, explainability, model capability evaluation, or every form of AI risk.
These are not minor disclaimers to hide in six-point type.
They define the boundary of the claim.
What the next experiment should do
The next engineering cycle is clear.
The four genuine leave-one-control-out configurations are:-
AVZ;
-
AVM;
-
AZM;
-
VZM.
Those runs isolate the marginal contribution of each control far more cleanly than the current observational contrasts.
The stronger version of the study would execute all sixteen possible combinations of the four controls. Then every point in the core frontier can be empirical.
The cost measurements should be run in randomised, interleaved blocks so that host load and temporal drift do not masquerade as treatment effects.
The loss sweep should cover the actual transition region, not begin above it.
Exact crossover values should be calculated for every competing empirical configuration.
And the economic model should distinguish topology-specific resource costs where the measured engineering data show that high-dependence and low-dependence architectures consume different resources.
None of this requires changing the central idea.
It requires testing the idea properly.
Why not simply maximise security?
A predictable objection is that the economics is unnecessary. If a control improves security, why not deploy it?
Because engineering is always constrained.
Compute is constrained.
Latency is constrained.
Human attention is constrained.
Availability is constrained.
Budget is constrained.
Complexity is constrained.
And security mechanisms can conflict with one another.
A fail-closed validation gate may improve integrity while reducing availability.
A human approval requirement may improve accountability while making emergency response slower.
Continuous high-resolution monitoring may improve detection while increasing cost and expanding the volume of sensitive operational data.
A rollback mechanism may reduce recovery time while increasing the probability of unnecessary intervention.
More importantly, controls can create dependencies of their own.
The assurance system is itself a system.
It can fail.
That means “maximise controls” is not even the same objective as “maximise safety.”
The governance implication: ask for the dependency graph
Boards, regulators, risk teams, and auditors commonly ask whether a control exists.
They should also ask:-
What does this control depend on?
-
Which other controls share those dependencies?
-
What happens if that shared service is corrupted rather than merely unavailable?
-
Which monitor observes the system independently?
-
Which evidence can be verified without trusting the system that generated it?
-
What proposition does each evidence object actually support?
-
Which claims remain outside technical verification?
-
What is the marginal value of the next control?
-
At what consequence-of-failure threshold does that control become rational?
-
Does the organisation know, or is it simply accumulating ticks?
This is particularly important as compliance becomes automated.
Policy-as-code can execute the wrong policy with extraordinary reliability.
An automated control is not epistemically superior merely because it is deterministic.
The question is whether the policy, evidence, root of trust, dependency structure, and supported claim all line up.
The broader idea: trust is a production function
The economics behind the project can be expressed in another way.
Trustworthiness is produced.
It consumes inputs:-
compute;
-
engineering labour;
-
independent infrastructure;
-
cryptographic operations;
-
monitoring capacity;
-
review attention;
-
recovery capability;
-
time.
Those inputs produce reductions in expected loss.
But the production function has structure.
The first independent control may be extremely valuable.
The second independent control may also be valuable.
The fifth control that shares the same compromised root may add almost nothing.
A simple additional test may outperform an expensive governance platform if the test adds an independent observation path.
A cheap commitment may add substantial evidential value if it makes later alteration detectable.
A large archive of provenance may add very little if nobody verifies it against any expectation.
The marginal productivity of assurance therefore matters.
That is the frontier.
A more precise definition of “trustworthy”
The word trustworthy is frequently used as if it were a property that a system either possesses or lacks.
For engineering purposes, that is too vague.
A better decomposition is:
Reliable: the system performs its intended function under the conditions for which reliability is claimed.
Robust: performance degrades acceptably under specified disturbances.
Secure: defined adversarial actions are prevented, detected, contained, or recovered from within stated assumptions.
Accountable: decisions and actions can be attributed to defined actors or processes.
Verifiable: relevant claims can be checked against evidence under a stated verification procedure.
Governable: residual risks and decisions that cannot be technically resolved have explicit owners and processes.
The trust cost frontier does not compress these into one mystical “trust score.”
It asks how specific controls contribute to specific claims and risks, what they cost, and where they fail together.
That is less glamorous than saying a platform is “responsible AI ready.”
It is much more useful.
The research claim I ultimately want to test
The completed study should be capable of supporting, rejecting, or qualifying four propositions.
First:
The cost-minimising assurance architecture is finite and changes with the value at risk.
Second:
Positive dependence between controls reduces the marginal assurance value of additional controls.
Third:
Architectures with the same nominal control count can produce materially different realised assurance because of dependency topology.
Fourth:
Cryptographically valid evidence should support only explicitly bounded claims; integrity verification does not imply semantic truth.
The current evidence already strongly supports the third proposition within the prototype and demonstrates the engineering implementation of the fourth.
The first is visible in the empirical break-even calculation but needs the complete ablation/frontier experiment.
The second is supported by the B2/B3 comparison and common-mode scenarios, but the final paper should estimate it with the completed configuration set rather than relying only on selected contrasts.
That is where the research stands.
Conclusion: stop counting controls
Trustworthy AI engineering has inherited two habits from conventional governance.
The first is the checklist.
The second is the document.
The checklist says that the presence of controls is evidence of trustworthiness.
The document says that if the system produced enough records, the organisation can demonstrate what happened.
Both habits are useful. Neither is sufficient.
Controls share dependencies.
Evidence has bounded meaning.
Assurance costs resources.
The next generation of AI assurance needs to model all three.
The practical goal is not a system with the largest control inventory. It is a system in which the controls that matter are independent enough to survive relevant failures, cheap enough to justify their continued use, and precise enough that the evidence they produce is not asked to prove more than it can.
That is the trust cost frontier.
And if an organisation cannot tell you where its assurance controls fail together, what each piece of evidence actually establishes, or why the next control is worth its cost, the problem is not that it lacks another dashboard.
The problem is that it has not yet measured trust.
References
Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1
Google Cloud. (2024, August 28). MLOps: Continuous delivery and automation pipelines in machine learning. Google Cloud Architecture Center. https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning
Ross, R., & Pillitteri, V. (2020). Security and privacy controls for information systems and organizations (NIST Special Publication 800-53, Revision 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5
Pillitteri, V. (2022). Assessing security and privacy controls in information systems and organizations (NIST Special Publication 800-53A, Revision 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53Ar5
Kubernetes Authors. (n.d.). Admission control in Kubernetes. Kubernetes. Retrieved August 31, 2026, from https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
Laurie, B., Langley, A., & Kasper, E. (2013). Certificate transparency (RFC 6962). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc6962
MITRE. (n.d.). MITRE ATLAS. Retrieved August 31, 2026, from
https://atlas.mitre.org/
Scarfone, K., Souppaya, M., & Dodson, D. (2022). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST Special Publication 800-218). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-218
Sigstore. (n.d.). Rekor. Retrieved August 31, 2026, from https://docs.sigstore.dev/logging/overview/
SLSA Community. (n.d.). SLSA specification, version 1.2. Retrieved August 31, 2026, from https://slsa.dev/spec/v1.2/
Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1
Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X., & Hamin, M. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2e2025). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-2e2025
Research-status note: The quantitative prototype results reported in this article are preliminary results from the ongoing Trust Cost Frontier engineering project. The B2/B3 dependency comparison, verification tests, mutation tests, and measured implementation overheads are completed within the current prototype. The complete trust-cost frontier remains under active testing because several control combinations require direct execution and true leave-one-control-out ablation before the full frontier should be treated as empirical.