Trust Engineering / The Layers of Trust
Enterprise AI stalls one ring at a time. Five layers, each with a question somebody in your organization is accountable for, a control that answers it, and a piece of evidence that proves it. Miss one and the whole thing is decoration.
Why this exists
Six months in. Legal, risk and compliance in the room, everyone wanting the program to proceed, and one question nobody can answer. Capability was never what stalled it. Evidence was.
The accuracy is fine. The benchmark is fine. Performance was never the question being asked in that room, and improving it does not move the review forward.
A policy is a statement of intent about systems nobody has built yet. Security review does not want your intent. It wants your architecture.
Every question that holds up a deployment has an answer that is a document: a data-flow map, an evaluation run, a runtime log, a signed score. Most organizations can produce none of them.
Rule one
Compromise the core and every ring outside it is decoration. Perfect evaluations and perfect guardrails on a leaking data layer buy you nothing.
Rule two
Most enterprises start with a policy memo. That is layer five: a statement of intent about four layers nobody has built. You earn the outer ring by having built the inner ones, in that order.
The model
Trust leaks from the inside out, so the work runs in the same direction. Select a ring to see what it asks, who owns it, and what closes it.
Five rings, core outward. Select a layer.
Layer 01 / Data
Staff paste proprietary material into tools nobody approved, because it makes their day easier.
Layer by layer
Each layer has a characteristic failure mode. Four of them are well documented in public incidents. The fifth leaves no trace at all, which is why it is the one that stalls programs.
01
Owner: CISO
Can I trust it with my company’s data?
What goes wrong
Staff paste proprietary material into tools nobody approved, because it makes their day easier.Capable people route around slow tooling. Source code, contracts, and customer records end up in consumer chat interfaces because that is the fastest way to finish the task. This is not a discipline problem, and a policy memo does not solve it. The answer is architecture.
02
Owner: Architecture
Can I trust intelligence I don’t own?
What goes wrong
Your intelligence layer belongs to somebody else, and their roadmap is not your roadmap.Pricing changes, and your unit economics change with it. A model deprecates, and your evaluations were written against something that no longer exists. A provider tightens policy, and a capability you already shipped stops working. None of these arrive on your schedule, and none of them ask first.
03
Owner: Engineering
Can I trust an agent to act for my company?
What goes wrong
An agent takes an action on your behalf and you find out what it committed you to afterwards.Agents do not only answer. They act. They issue credits, update records, send messages, and call other systems on your behalf. Where this has been tested, the finding has been consistent: responsibility sits with the company, not the software. You own what your agent does, whether or not you intended the action it took.
04
Owner: Operations
Can I trust it right now, while it’s running?
What goes wrong
The system is talking to your customers at this moment and nobody can say what it is saying.A system that behaved in testing can be talked out of its instructions in production. The attack is cheap, it arrives through ordinary user input, and the damage scales with whatever you connected the system to. The published examples are funny because the stakes were low. Change the object to a claim, a diagnosis, or a wire transfer, and they stop being funny.
05
Owner: The executive whose name is on it
Can I prove any of it to my board?
What goes wrong
Everyone in the room wants the program to proceed. Nobody can say out loud whether it works.This layer produces no incident report, which is exactly the problem. It shows up as a program sitting in security review for six months while everyone waits for somebody to state in writing that the system works. Every other layer fails loudly. This one fails as silence, which is why it costs the most and gets discussed the least.
The whole stack
Not “have a plan for”. Not “have a vendor for”. Hand a document to somebody who doesn’t work for you. If the honest answer is one, you are exactly where the market is.
| Layer | The question | The control | The evidence |
|---|---|---|---|
| 01 / DATA | Can I trust it with my company’s data? | Sovereignty | A data-flow map. Where every prompt actually lands. |
| 02 / MODEL | Can I trust intelligence I don’t own? | Portability | A completed model swap. Not a slide about one. |
| 03 / ACTION | Can I trust an agent to act for my company? | Evaluations | A versioned evaluation run, with the failures still in it. |
| 04 / RUNTIME | Can I trust it right now, while it’s running? | Guardrails | The log. Every action taken, and every action blocked. |
| 05 / ACCOUNTABILITY | Can I prove any of it to my board? | Evidence | The score itself, in front of the board. |
Start at the core. Layer one is architecture, and architecture takes the longest. The outer rings are fast once the inside is real.
How we work the stack
The framework tells you which question is unanswered. The engagement answers it. Two connected disciplines: establish evidence about system behavior, then use that evidence to guide engineering changes and verify their effect.
01 / Trust Analysis
Map decision chains and define acceptance criteria with your team. Evaluate realistic scenarios, edge cases, and policy conditions. Trace failures across models, retrieval, integrations, and tools.
02 / Trust Remediation
Address the causes in prompts, context, retrieval, tool use, and policy logic. Re-run evaluations against an agreed baseline and check for regressions elsewhere in the workflow.
The unit of trust is the workflow
Layer three is where most engineering time goes, and it is the layer that hides the most. An accurate model can still produce a poor business outcome when it receives outdated context, calls the wrong tool, or applies a superseded policy.
We connect each step to the final decision. That makes it possible to investigate causes, prioritize fixes, and test whether the system actually improves.
Explore the illustrative claims workflow to see the difference.
Inspecting / Retrieval
The workflow retrieves a superseded policy. The answer can sound correct while relying on the wrong evidence.
Example scenario, not a client result or live system.
What we measure
Success criteria are specific to your workflow. We agree the baseline, test scenarios, and measurement approach before interpreting the results.
Does the outcome meet your business criteria across representative scenarios?
Does behavior remain acceptable when inputs, context, or dependencies change?
Can your team follow the evidence, tool actions, and policy checks behind a decision?
Which failures have the greatest operational consequences, and where should remediation start?
Where we fit
We work with your team across models, orchestration, evaluation tooling, and business controls. The starting point is a specific workflow and a decision you need to make about it.
Start with one workflow
Thirty minutes to discuss your system, the layer you are least confident about, and whether a Trust Audit is the right next step.