Enterprises are beginning to encode the conditions under which actions can be trusted, rather than relying on policy, reputation or retrospective audit alone. The result is not machine trust replacing human judgement, but a new infrastructure layer connecting identity, authority, evidence and accountability.
A supplier is added to a payment system. A software release moves into production. An AI agent retrieves customer information, calls an external service and updates a case record. Each action may be technically valid, yet the enterprise still needs to answer a more important set of questions: who or what was authorised to act, which rules applied, what evidence supported the decision and how quickly could that authority be withdrawn?
Historically, organisations answered those questions through hierarchy, professional judgement, policy documents and periodic audit. Those mechanisms remain necessary, but they no longer match the speed or scale of digital operations. Critical work now passes through APIs, cloud workloads, automated pipelines, third-party platforms and AI systems that can make or execute thousands of decisions before a human reviewer sees the first exception.
This is the structural shift behind programmable trust. Trust is moving from an assumption surrounding the system to a set of conditions operating inside it.
Trust is becoming an execution requirement
Enterprise trust has often been treated as a cultural or institutional quality. Organisations trust employees because they were recruited, trained and given defined responsibilities. They trust suppliers because contracts, due diligence and relationships create confidence. They trust systems because access has been approved and controls are reviewed.
The weakness is temporal. Most traditional trust decisions are made at one point and carried forward: at login, onboarding, contract signature, system approval or annual audit. The conditions supporting that decision may change long before the trust is reassessed.
Modern security architecture already reflects this problem. NIST's zero trust model removes implicit trust based on network location and requires access decisions to draw on continuously updated information. The OpenID Foundation's Continuous Access Evaluation Profile extends the same logic by allowing systems to exchange events that can reduce or revoke access for people, devices, sessions, applications and robotic users when circumstances change.
A similar movement is taking place in assurance. NIST's Open Security Controls Assessment Language represents controls, system plans and assessment results in machine-readable formats. FedRAMP 20x now expects cloud providers to demonstrate security through clearer, measurable and reusable evidence; its 2026 rules establish machine-readable authorisation data across certification packages and ongoing reporting.
These developments come from different domains, but they point in the same direction. Trust cannot depend only on what was approved yesterday. It increasingly depends on what can be verified now.
Programmable trust connects permission to proof
Programmable trust is not a single product and, at least today, it is not a clean software category. It is an architectural pattern: the ability to convert selected trust conditions into rules and signals that software can evaluate across identities, permissions, actions, data flows and evidence while work is being performed.
Its purpose is not to make a system inherently trustworthy. No control architecture can guarantee that. Its purpose is to make the basis of trust explicit, testable and contestable.
Five capabilities work together:
- Identity: establishes which person, service, workload, device, model or agent is acting.
- Authority: defines what that identity may do, for which purpose, within which limits and for how long.
- Policy: converts selected rules into conditions that systems can evaluate and enforce.
- Observability and provenance: record what happened, which data and components were involved and how an output or action was produced.
- Evidence and intervention: demonstrate whether controls operated and allow access, execution or approval to be stopped, reversed or escalated.
The individual components are already visible. SPIFFE and SPIRE issue strongly attested cryptographic identities to workloads across distributed environments. SLSA uses provenance to describe which entity built a software artefact, which process it used and which inputs were involved. OpenLineage records metadata about datasets, jobs and runs. OpenTelemetry is standardising how generative AI operations, including model calls and tool activity, can be represented through shared telemetry conventions.
The strategic development is their convergence. Identity without policy says who acted but not whether the action was legitimate. Policy without telemetry says what should happen but not what did. Observability without provenance shows system behaviour but may not establish the integrity of the inputs. Evidence without intervention can prove failure only after damage has occurred.
Programmable trust joins these elements into a control loop: identify, authorise, evaluate, observe, prove and, when necessary, intervene.
Machine trust should govern repeatable conditions, not human meaning
The phrase “machine trust” can imply that an organisation is transferring judgement from people to software. That is the wrong model.
Machines do not trust in the human sense. They evaluate signals against rules. Their advantage is consistency, speed and coverage. A machine can check every access request, verify every signed software artefact or test a control continuously rather than sampling a small proportion once a quarter. It can preserve a detailed record across volumes of activity that no audit team could inspect manually.
Human judgement provides what encoded controls cannot reliably supply: interpretation, proportionality, ethical reasoning, sensitivity to context and responsibility for consequences. These qualities are essential where decisions are novel, contested, rights-affecting or difficult to reverse.
The boundary matters because simply placing a person after an automated recommendation does not create effective oversight. A meta-analysis of 106 experiments found that human–AI combinations performed better than humans alone on average, but worse than the better of the human-only or AI-only approaches. Collaboration did not automatically create synergy, particularly in decision tasks.
The durable model is therefore not human trust versus machine trust. It is machine-enforced minimum assurance combined with human-governed ambiguity, exceptions and accountability.
That creates a non-delegable core. People should retain authority where an organisation must weigh competing values, explain a material decision, hear an appeal, accept an exception or own an outcome. Machines should dominate where conditions are stable, evidence is observable and enforcement must operate at scale.
Trust becomes real at the point of action
Consider an illustrative procurement workflow in which an AI agent helps a team onboard a supplier and prepare a purchase order.
In a conventional design, the agent may inherit the user's access, retrieve information from several systems and produce a recommendation. A person approves the result, but the organisation may struggle to reconstruct which records were used, whether the agent crossed a data boundary or why a particular supplier passed the checks.
A programmable trust design changes the workflow.
The agent receives its own identity rather than operating invisibly through a shared account. Its delegated authority is limited by task, value, data scope and duration. Policy checks verify supplier status, segregation of duties, contractual conditions and spending thresholds before the action is committed. The workflow records the data sources, model and tools involved. A material exception moves to an accountable person with the evidence needed to challenge the recommendation. Every override is attributed and retained for review.
The organisation has not automated trust. It has made the conditions for trusted action operational.
The same pattern applies to software deployment, financial approvals, customer decisions, data access and AI-assisted service. The details differ, but the architecture asks consistent questions: which identity is acting, what authority has been delegated, which rule permits the action, what evidence has been generated and where does human responsibility re-enter the process?
Regulation is strengthening the need to answer those questions. The EU's Digital Operational Resilience Act has applied since January 2025 and requires covered financial entities to manage information and communications technology risk, incidents, testing and third-party dependencies. The EU AI Act is being applied in stages, with further obligations becoming applicable from 2 August 2026 and implementation continuing into 2027. These regimes differ, but both increase the value of controls that can be demonstrated rather than merely described.
Continuous evidence can still create false confidence
Programmable trust has an obvious failure mode: governance theatre with better telemetry.
A dashboard can show that every control passed while excluding the systems that were never instrumented. A policy engine can enforce a flawed rule perfectly. An immutable log can preserve evidence that nobody reviews. A human approval step can become a ritual in which people accept machine recommendations without the time, authority or context to challenge them.
The trust infrastructure can also become a concentrated source of risk. Compromise the identity provider, policy repository or evidence pipeline and an attacker may gain both operational power and the appearance of legitimacy. Excessive monitoring can create privacy and workforce concerns. Rigid controls can block legitimate work, pushing teams towards unmanaged tools and informal exceptions.
This is why evidence quality matters more than evidence volume. Leaders should ask whether telemetry covers the full workflow, whether policy logic reflects the intended control, whether provenance can be independently verified and whether exceptions reveal weaknesses in the design. FedRAMP 20x's guidance makes a useful distinction between static evidence and “living” evidence that can be reproduced, maintained and tested for scope and cadence.
Trust must also remain contestable. A control decision should be explainable to the people accountable for it. An affected person should have a meaningful route to intervention where the decision carries material consequences. A system that can enforce a rule but cannot expose its basis may be automated, but it is not well governed.
The leadership task is to design a trust architecture
The first mistake would be to launch a procurement exercise for a “programmable trust platform”. Most enterprises already own parts of the required stack across identity and access management, security, workflow, observability, data governance, software delivery, AI governance and governance, risk and compliance systems.
The harder task is to make those capabilities operate as one assurance system.
A practical leadership agenda starts with six decisions.
Identify the critical trust moments. Map the decisions and actions where failure could create material financial, operational, customer, regulatory or reputational harm. Prioritise the point where an approval becomes an action, data crosses a boundary or authority is delegated to a non-human actor.
Make identity the root of accountability. Inventory human and non-human identities, including services, workloads, automation accounts and AI agents. Remove shared or unowned identities and define who may delegate authority to each actor.
Translate a small number of controls into executable conditions. Do not begin by encoding the entire policy library. Select high-value rules with clear inputs, outcomes and owners. Version them, test them and connect changes back to the governing policy.
Design evidence into the workflow. Decide what must be recorded at execution time: identity, authority, policy decision, data lineage, model or software version, tool calls, approvals, exceptions and outcomes. Prefer interoperable formats and portable evidence over proprietary dashboards that cannot support independent review.
Treat exceptions as governance data. Overrides should be possible where human judgement is needed, but they should be attributable, time-bound and reviewed. Repeated exceptions often reveal a policy, workflow or operating-model defect.
Preserve the non-delegable core. Define which decisions require human authority because they involve ambiguity, rights, ethics, strategic trade-offs or irreversible consequences. Give reviewers the information and decision rights needed to do more than rubber-stamp the system.
Programmable trust will not remove the need for culture, leadership, professional judgement or institutional credibility. It will change what those forms of trust can reasonably rely on.
The organisations best prepared for more autonomous digital operations will not be those that attempt to encode every judgement. They will be those that know which conditions should be enforced by machines, which decisions must remain human and how to produce credible evidence across the boundary between them. Trust then stops being a claim made about the enterprise and becomes a capability demonstrated through its actions.
