Trust in a software system is a measurable property: the policy you enforce and the evidence you keep at every point where control changes hands. Watch a single request cross an API gateway and the whole problem is there in miniature — one context deciding, on partial information, what to accept from another and what to do next.
Policy defines what the system should permit, deny, require, transform, or constrain. Evidence shows what it actually did, under what authority, with what traceable support. A system is trustworthy to the extent that both are inspectable at its boundaries. That definition is the useful one because it moves trust out of marketing language and into design — and it places the rest of this work: if trust is policy and evidence across boundaries, then semantics, middleware, and platform become the layers that make trustworthy behavior possible.
Boundaries are where trust becomes real
Trust is easy to discuss in the abstract and hard to preserve at handoff points, which is why boundaries are the right place to study it.
A boundary is any point where control, information, or authority moves from one context to another: a network edge, an API gateway, a service-to-service call, a tenant isolation layer, an identity federation point, an event pipeline, an approval step, a model invocation, a workflow handoff. The mechanism varies; the situation repeats. One side has to decide what to accept from the other and what to do next.
At that point the system faces a predictable set of questions. Who is making the request? What identity or claims are attached? What policy applies, which actions are allowed, which route is valid, what evidence needs recording, and what context must survive the handoff? A system that answers these explicitly is doing trust work. A system that leaves them unanswered falls back on assumption, and assumption is where trust quietly degrades.
This is why trust is a systems design problem rather than a cultural one: it concerns how systems behave when control crosses domains, layers, and components, and how they carry rules and proof through those transitions.
No implicit trust is a design rule
Composed, distributed systems run on inherited legitimacy. A request is trusted because it came from the internal network. A service is trusted because it is already part of the environment. A workflow is trusted because it sits on an approved path; a model output, because the model was invoked from inside the boundary. In each case trust was never established. It was inherited from location, and location is a weak parent.
The practical value of zero trust — the design rule at the center of NIST SP 800-207 — is the removal of ambient legitimacy from the architecture. Internal stops being an argument; so do adjacent and previously authenticated. A trustworthy system requires explicit identity, explicit policy evaluation, and explicit evidence at every meaningful handoff.
Each handoff is also an opportunity to lose something: identity fidelity, provenance, route constraints, enforcement context. Once that context is gone, downstream components operate on weaker ground — the system still functions, but it becomes harder to examine and easier to misuse. “No implicit trust” is a way of forcing the system to carry its reasons with it.
Policy is one half of trust
Policy is the normative half: what should happen. It defines permissions, prohibitions, obligations, routes, required checks, release conditions, transformation rules, and escalation points. Policy lets a system say: this identity reaches this resource under these conditions; this workload may call this service and no other; this data crosses this boundary only with these labels; this output ships only when its provenance requirements are met.
Without policy a system can still emit telemetry, but it cannot distinguish acceptable behavior from unacceptable behavior. It can describe activity, and no more.
The separation between deciding and enforcing matters here. A policy decision point determines what should happen; an enforcement point makes runtime behavior conform — the split that engines like Open Policy Agent are built around. Keeping the two distinct keeps a system legible, and it blocks a common mistake: treating declaration as enforcement. A control that exists only in specification, policy code, or an architecture deck is incomplete until it reaches runtime. (Many controls live long, well-documented lives without ever doing so.)
Policy is necessary because trust needs rules. Rules alone, though, prove nothing about behavior.
Evidence is the other half
Evidence is the empirical half: what did happen. It includes the runtime artifacts that make behavior examinable — policy decisions, provenance records, logs, traces, audit surfaces, identity assertions, denials, and the correlations that tie actions back to principals. Evidence is what lets a system answer questions under inspection: which decision was made, why, under which accepted identity, along which path, leaving which record.
The strongest objection to this whole frame comes from teams with mature observability: “We already have telemetry — traces, dashboards, a log pipeline with its own budget line. Isn’t that evidence?” Not yet. A log line shows that an action occurred; a trace shows where a call moved; an audit record shows that a change happened. None of them shows the action was justified, policy-compliant, or properly constrained. Telemetry becomes trust evidence at the moment it connects back to control logic, and at no moment before.
The symmetric failure gets less attention. A team can claim that every request is authenticated and every sensitive path governed, and mean it. Trust depends on whether the system can expose the proof in runtime terms: the accepted identity assertion, the policy result, the enforcement surface, the record connecting request to action. Where it cannot, the control remains partly rhetorical.
Policy without evidence is assertion. Evidence without policy is uninterpreted telemetry. Trust requires both.
Trust signals are runtime signals
Real trust appears in runtime behavior, and it has a short list of recognizable signals.
The policy decision itself is the first. A trustworthy system can show that an action was evaluated under a defined rule set and resolved a specific way — governed behavior, as opposed to behavior with no explanation attached.
Provenance is the second: where an artifact came from, how it was transformed, and what lineage connects it upstream, in the sense W3C PROV gives those words. Outputs detach from their origins at every handoff unless something deliberately preserves the chain.
Usable logs, traces, and audit surfaces are the third — the OpenTelemetry layer. Their value is the examinability they create: operators can reconstruct controlled events across boundaries, and controlled is the word doing the work.
Identity assertion is the fourth. Policy has to bind somewhere; identity is the anchor, and weak identity weakens every control attached to it. The companion note on runtime identity takes that problem up in full.
The least appreciated signal is constraint itself: what the system made impossible. If sensitive traffic moves only through certain paths, if only attested workloads can invoke a service, if egress is limited to inspected channels, those constraints are themselves evidence. Narrowness is evidence. Denial is evidence. In many systems the clearest trust signal is the enforced boundary rather than the happy path.
Trust has to land somewhere
The definition also places the other pillars. Semantics gives evidence its structure and meaning — the shared vocabulary that keeps policy decisions, provenance, and audit events intelligible across components; without it, evidence fragments into records you can collect but cannot compose. Middleware carries decisions and context across handoffs, and this is where trust is most often lost — during propagation, after the decision was made correctly. Platform provides the runtime discipline: identity systems, policy engines, telemetry pipelines, gateways, audit sinks — the layer where enforcement becomes repeatable and evidence capture becomes durable.
The trust problem is upstream, but its realization is distributed across meaning, handoff, and runtime control. The other essays here follow from that distribution.
What this asks of a design
Treat boundaries as first-class control surfaces. Make identity survive handoffs. Make policy explicit and its enforcement observable. Retain evidence in a form that supports examination, keep provenance attached to artifacts and decisions, and leave routing constraints visible enough to show what the system refuses as well as what it permits. User confidence may follow from all of this, but confidence is the byproduct; the engineering definition is the one you can build against.
A short exercise makes it concrete. Walk one request through your stack and list every point where control changes hands — gateway, service call, queue, model invocation, approval step. At each point, ask two questions: what policy applied, and what evidence remains. The places where both answers come back empty are your actual trust surface, whatever the architecture diagram says.