An AI root of trust is a verifiable foundation for deciding whether an AI system is running approved components under approved conditions. For enterprise buyers, the task is to connect hardware and boot integrity with runtime evidence, model provenance, identity and policy, then separately evaluate whether outputs are fit for use.
This guide is for CEOs, business owners, CMOs and marketing leaders evaluating enterprise AI, alongside the security and platform teams who must approve it. Start with one workflow and its permitted actions, not a promise that a model is universally trustworthy.
What does an AI root of trust establish?
A hardware root of trust is a starting point relied on for security functions. For an AI deployment, use that foundation within a broader evidence chain covering the system, its model and its authority to act. Infrastructure integrity and answer correctness are separate acceptance questions.
For the platform-security foundation, see NIST’s Platform Firmware Resiliency Guidelines.
Start with the action you are authorizing
A drafting assistant and an agent authorized to change customer records deserve different release decisions. Specify what the system may read, what it may change, who could be affected and which actions require human approval.
Then ask what evidence would justify those permissions. A supplier's statement that its model is trusted does not answer whether your deployment uses the approved release, whether the requesting identity has appropriate access or whether a proposed answer follows from an authoritative source.
Treat the AI root of trust as part of that acceptance decision, not as a replacement for it.
Use the Trusted AI Chain to find the missing evidence
Percepture’s Trusted AI Chain is a review sequence: silicon → boot → runtime → model artifact → identity → policy → output evidence. It is not a certification or a claim that every link shares one cryptographic mechanism.
“Trust has to start before the prompt.”
Bob Generale, President of Percepture
For each link, name the evidence owner, the acceptance condition and the consequence of failure. Use this table to structure an AI root of trust review with a supplier or internal platform team.
| Chain link | Evidence to request | Decision when evidence is insufficient |
|---|---|---|
| Silicon | The hardware trust anchor, its security boundary and how its identity is established. For managed services, identify what the provider operates. | Do not approve a hardware-assurance claim whose trust anchor or covered boundary cannot be explained. |
| Boot | The approved startup policy, integrity measurements where applicable, reference values and the process for accepting firmware changes. | Hold the affected workload when startup evidence cannot be reconciled with the approved baseline. |
| Runtime | Attestation evidence where applicable, its freshness requirements, covered components and treatment of failed checks. | Restrict sensitive processing when the required execution environment cannot be established. |
| Model artifact | The model release identifier, origin, integrity reference, deployment configuration and separately identified adapters or other modifications. | Prevent substitution of an unidentified release; require review of changes before restoring its permissions. |
| Identity | The requesting user, workload identity, delegated authority and credentials used for each connected tool. | Deny actions that cannot be tied to an authorized identity and a permitted purpose. |
| Policy | Enforced access rules, allowed actions, data-handling requirements, approval gates and the responsible policy owner. | Reduce permissions or require human approval where enforcement has not been demonstrated. |
| Output evidence | Source references, relevant versions, tool-action records and review evidence appropriate to the decision. | Withhold publication or consequential action when the supporting evidence is inadequate. |
An AI root of trust review should also identify what is being trusted upstream: a manufacturer, signing authority, cloud provider or internal release process. Move an assumption into the record instead of silently treating it as proof.
Before the next supplier call, give the business owner and security owner the same table. Agree which gaps block release and which permit a narrower pilot. If the business objective or accountable owner is unclear, begin with strategy and planning before selecting more technology.
Distinguish the controls before comparing suppliers
An AI root of trust discussion becomes less useful when different controls are treated as interchangeable. Ask suppliers to name the mechanism, its coverage and its limits.
TPM and hardware roots of trust. TPM 2.0 is not zero-trust software. A Trusted Platform Module belongs to the platform-security conversation; it does not replace enterprise access policy or evaluate the truth of a generated answer. The Trusted Computing Group is a primary source for TPM specifications and terminology.
TEE and confidential computing. A trusted execution environment concerns a protected execution boundary. Ask exactly which CPU, accelerator, memory and data-transfer boundaries the proposed implementation covers. Do not extend a component-level protection claim to the entire application without evidence.
Attestation. Attestation supplies evidence about an environment or component for appraisal. Ask who produces the evidence, who verifies it, which reference values are accepted, how freshness is established and what happens after rejection. The IETF Remote ATtestation procedureS architecture, RFC 9334, provides the vocabulary for separating these roles.
Model provenance and enterprise policy. Provenance concerns the artifact's origin and history; policy concerns what the deployed system is allowed to do. A model identifier is not a permission grant. A signature or integrity reference should not be accepted as proof of factual accuracy or business suitability.
Ask suppliers to distinguish their AI root of trust evidence from their broader governance claims. The procurement question is which decision each piece of evidence actually supports.
Make the evidence change a release decision
Consider a proposed sales workflow that summarizes account information and can write a recommended next step into a CRM. This is a decision exercise, not a product test. For a workflow such as AI sales agents, define those read and write permissions separately.
Suppose the platform and model evidence satisfy the technical team's acceptance criteria, but the proposed tool credential permits changes outside the intended account scope. Do not average that failure against the controls that passed. Restrict the credential or remove write access before release.
If permissions are acceptable but the recommendation lacks an adequate source, keep the workflow in draft mode. If a model change cannot be reconciled with the approved release, hold the affected deployment pending review.
That is the operating value of an AI root of trust: evidence leads to an explicit permission, restriction or stop. A review that ends with a reassuring label but no changed decision has not resolved the buyer's question.
Where an AI root of trust stops
Infrastructure assurance is not a warranty on everything the application does. Keep these limits in the acceptance record:
- Coverage: Identify components, connections and external services outside the asserted security boundary.
- Correctness: Evaluate whether an answer is supported and suitable for its intended use, separately from platform integrity.
- Source quality: Examine retrieved material for authority, currency, relevance and permitted use.
- Change: Define which model, configuration, permission or provider changes trigger another review.
- Evidence handling: Set access and retention rules for logs and supporting records; do not collect sensitive information without a defined purpose.
Use the NIST AI Risk Management Framework to structure the wider risk-management discussion rather than trying to make hardware evidence answer every governance question.
For content marketing workflows, give publication its own approval gate. Ask the editor to evaluate the claim and its supporting source, not merely whether the drafting system ran in an approved environment.
What not to accept as proof
A trusted-model label without an identifiable release. Ask which artifact and configuration the statement covers, and how changes reach your deployment.
A prompt presented as an access-control boundary. Require evidence of enforced permissions outside the model's instructions. Include attempted prohibited actions in the acceptance test plan.
An impressive diagram without failure handling. Ask what happens when an identity check fails, evidence expires or a component changes. Assign the person who can restrict the workflow.
An AI root of trust label used as blanket approval. Require a specific assurance claim, a defined boundary and a release consequence. Keep business acceptance separate from the supplier's terminology.
Buyer checklist for an AI root of trust
Before approving a pilot or expanding access, ask the business and technical owners to complete these actions:
- Bound the workflow: List permitted data sources, users, tools, actions and human approvals.
- Assign ownership: Name the business approver, technical evidence owner and person authorized to stop operation.
- Identify dependencies: Record customer-operated and provider-operated trust anchors and controls.
- Pin the release: Record the model, relevant modifications and deployment configuration under review.
- Request failure tests: Include denied access, rejected environment evidence, unauthorized model changes and unsupported outputs.
- Define evidence handling: Specify who can inspect records, how long they are retained and what sensitive data must be excluded.
- Set the release rule: Document what permits production, what limits the pilot and what requires suspension or reassessment.
Keep the completed review with the deployment decision. A numerical trust score is not a substitute for deciding whether a particular failure is acceptable.
Questions buyers ask before approval
Is an AI root of trust a certification?
Not by itself. Treat the phrase as a request for specific evidence. If a vendor presents a certification, check its issuer, scope, covered components and validity rather than treating the label as approval for every workload.
Can a managed AI API fit the Trusted AI Chain?
Use the chain to document shared responsibility. Ask which platform, model-version and control evidence the provider exposes, which decisions you retain, and what remains outside your visibility. Limit the workflow when the available evidence cannot support its proposed permissions.
Do buyers need access to model weights?
Start by requesting an identifiable model release, its origin, change controls and the configuration used for your workload. Access to weights is a separate procurement question. Where you cannot inspect an artifact, document what you rely on the provider to establish.
Does retrieval-augmented generation establish output trust?
Do not accept retrieval alone as sufficient evidence. Check the source’s authority, version, access permissions and relevance, then verify that the answer actually follows from it. Preserve source references where appropriate.
Does every AI root of trust require customer-owned hardware?
No. Decide which trust anchors you operate and which you rely on a provider to operate. Ask for evidence at that boundary. Buying hardware is not a substitute for controlling identities, tools, data access and release decisions.
When should the evidence be reviewed again?
Set review triggers before launch. Include changes to the model, runtime, provider, retrieval sources, permissions and approval policy, plus evidence expiry or a security incident. Define who can restrict the workflow while the affected controls are reassessed.
Define the next deployment decision
Bring one workflow, its data sources, proposed actions and approval owners. Use the conversation to frame the business objective and the questions your technical team must resolve. Security acceptance remains with your qualified security and platform reviewers.
An AI root of trust is useful when its evidence changes a decision: admit the workload, restrict the action, require review or stop deployment. Set those consequences before expanding access.
About Bob Generale
Bob Generale is President of Percepture and the author of this guide.
