Case study · amotivv · Attexa Witness × Tinfoil

Attexa Witness Nodes running on Tinfoil confidential infrastructure

Consequential AI-agent activity, turned into signed, durable, independently verifiable evidence, where the evidence layer itself is attested, not merely trusted.

Signed, durable evidenceAttested witness runtimeVerifiable without trusting Attexa

Agent Anything runs on the same governance fabric described in this case study. Every consequential agent action passes through Attexa's policy boundary and produces a signed, quorum-witnessed receipt. The following case study, developed with Tinfoil, shows how that evidence layer is itself attested so it can be verified end to end.

Summary

Evidence you can verify without trusting the system that produced it.

Attexa Verified Actions is a patent pending solution that turns consequential AI agent activity into signed, durable, independently verifiable evidence.

When an agent attempts an action that matters, Attexa routes that action through a policy boundary before execution, records the decision path, and produces a receipt bundle that can be verified later without relying on the agent's own logs or self-reporting.

The Attexa Witness quorum produces the evidence chain. Attexa Witness nodes operate inside secure Tinfoil enclaves, so the evidence layer is itself verifiable rather than merely trusted. In the production Verified Actions profile, receipt bundles that pass through the L1 witness include the attestation evidence needed to verify the witness runtime offline.

That is what allows the independence claim to hold end to end: a verifier can check the receipt signatures, witness quorum, runtime attestation, registry authorization, and public build evidence without trusting Attexa, Tinfoil, the AI provider, or the enclave operator as a black box.

The architecture also extends naturally to customer-operated and third-party witness nodes. Enclave attestation provides the shared trust substrate, making multi-party witnessing practical without requiring every quorum participant to maintain a bilateral trust relationship with every other participant.

Attexa Verified Actions architecture diagram: an AI agent attempts a consequential action, which passes through a policy boundary into an Attexa Witness quorum running on Tinfoil attested enclaves, producing a signed receipt bundle that an independent verifier can check offline.

Attexa Verified Actions and Attexa Witness are copyright of amotivv, Inc.

01 · Architecture overview

A policy gate, a witness, and a signed receipt on every consequential action.

Attexa provides a governance and evidence layer for AI agents through two integrated components: Verified Actions and the Attexa Witness.

Verified Actions adds a policy gate, witness, and signed receipt to every consequential action routed through the Verified Actions boundary.

Consider a Release Manager agent running inside Claude Managed Agents. The agent can draft release materials in its workspace, but publishing or modifying release-governed artifacts requires policy approval. A policy rule says the agent may not update official release notes, release manifests, or deployment metadata unless a valid human-signed attestation is attached to the exact action.

When the agent attempts to update a governed release artifact, the request reaches the Verified Actions boundary before execution. The policy engine evaluates the action digest, target path, agent profile, session context, and any attached attestations. If no valid attestation is present, the action is denied. No release artifact is modified.

A signed receipt records the attempted action, the policy rule that applied, the evidence considered, and the denial decision. The resulting bundle can be published to durable storage and independently verified later by an auditor, customer, or compliance team.

The same flow applies to allowed actions. Policy is checked, the action proceeds, the result is recorded, and a signed receipt is produced. Allowed and denied actions both generate evidence the operator did not write and cannot quietly modify after the fact.

The Attexa Witness is the component that performs the recording and signing. It operates as a quorum: multiple witness nodes participate before evidence is accepted as valid. This prevents any single party, including Attexa, from unilaterally forging a valid receipt chain. The quorum signs checkpoints that commit to the receipt chain, allowing a verifier to validate the sequence of events through compact cryptographic commitments rather than relying on mutable logs.

Tinfoil provides the attested runtime for the witness nodes. The witness quorum runs inside Tinfoil-hosted trusted execution environments. Each witness node's runtime is attested, so a verifier can confirm the node was running the declared software and configuration when it produced witness evidence. This makes the question "was the witness runtime tampered with?" answerable through cryptographic verification rather than through Attexa's assurances.

02 · Why the Attexa Witness runs on Tinfoil

If the evidence layer needs trust, the problem just moves down a level.

The choice of enclave provider is not incidental. The Attexa Witness is part of the evidence layer. If that layer requires trust in Attexa-operated infrastructure, the system only moves the trust problem one level down.

Tinfoil gives the witness runtime an independently verifiable substrate. Its open-source stack and transparency-log-backed release process allow a verifier to connect a running enclave measurement back to a publicly recorded build. That creates a verification chain from source code, to measured release artifact, to enclave attestation, to witness signature, to receipt bundle.

For Attexa, that chain is central. The claim is not simply that an agent action was logged. The claim is that the evidence for the action can be checked without trusting the agent, the operator, Attexa, or Tinfoil as a black box.

Cloud-provider TEE offerings provide real hardware isolation, but the witness layer also needs public auditability of the runtime that produced the evidence. For a governance component whose value proposition is independent verification, the attestation substrate must support that claim end to end.

03 · Why the witness runtime requires attestation

Narrowing the trust assumption to a measured runtime.

A governance layer that stores its own evidence in ordinary operator-controlled infrastructure recreates the original problem. A skeptical auditor still has to trust that the witness code was not modified, that records were not selectively dropped, and that signing keys were not used outside the intended context.

Tinfoil's attestation model narrows that trust assumption. The enclave attestation commits to the measured runtime image and configuration. The witness signing key is generated and used inside that runtime, and the production verifier profile links the witness key, enclave attestation, and registry authorization.

In practice, this means the verifier checks multiple things together: the receipt signatures, the witness key authorized by the registry epoch, the witness runtime attestation, and the public build evidence associated with that runtime. The key is not treated as trustworthy simply because Attexa says it is a witness key. It is accepted because it is authorized in the registry and associated with an attested witness runtime under the applicable verifier profile.

In the production Verified Actions profile, published receipts include the attestation evidence needed for offline verification. A verifier can check the receipt signatures, the receipt-chain commitments, the witness quorum, and the Tinfoil attestation evidence without calling a live Attexa service or relying on an operator dashboard.

Returning to the release-governance example: an auditor reviewing a denial receipt does not need to call an Attexa endpoint or log into the operator's dashboard. They run a local verifier against the receipt bundle. The verifier checks the receipt signatures, confirms the witness key was authorized for that workflow and registry epoch, and confirms the witness runtime corresponds to a publicly recorded Tinfoil build. The result either verifies or it does not.

The operator cannot alter a receipt that has already been witnessed. They also cannot produce a receipt that passes verification unless the required witness quorum actually participated.

04 · Key rotation and registry epochs

Ephemeral keys, with continuity in the registry.

Tinfoil filesystems are intentionally ephemeral. A witness relaunch can produce a fresh witness key epoch. Attexa treats that as part of the security model rather than as an operational gap.

The witness registry is the continuity layer. It records which witness keys are authorized for which workflows, policies, and validity windows. When a witness key rotates, Attexa publishes a new signed registry epoch authorizing the new key and superseding or expiring the old one.

Old receipts remain verifiable against the registry epoch that authorized the witness key at the time of signing. New receipts verify against the new epoch. The key does not need to persist outside the enclave for continuity to hold.

This makes key rotation auditable. A fresh enclave instance can have a fresh key, and the registry records that transition explicitly.

05 · Quorum design and third-party witnesses

No single witness is a single point of control.

A single attested witness is still a single point of control. The Attexa Witness therefore operates as a quorum. In the reference deployment, L1 mechanical witnessing uses a threshold quorum, while L2 policy decisions can require a stricter policy-witness quorum.

L1 mechanical witnesses record the action boundary and receipt chain. L2 policy witnesses evaluate whether a requested action is authorized under the active policy bundle. Together, they separate evidence production from policy authorization while preserving a unified verifier story.

Because each witness node runs inside an attested Tinfoil enclave, the quorum can include nodes operated by parties other than Attexa without requiring those parties to trust one another. Each node proves what it is running. The quorum proves that enough independently operated nodes observed or evaluated the action.

This design extends naturally to customer-operated, auditor-operated, or regulator-operated witness nodes. A customer can hold part of the signing threshold for its own evidence. The audit trail no longer rests solely on Attexa infrastructure.

Adding a witness node becomes an attestation and registry operation, not a bespoke bilateral trust relationship with that node's operator.

06 · What this enables

Beyond agent self-reporting.

Attexa Verified Actions gives AI operators a way to move beyond agent self-reporting.

Instead of asking whether an agent says it followed policy, a verifier can check:

  • what action was attempted
  • what policy applied
  • whether the action was allowed or denied
  • whether the required witness quorum signed
  • whether the witness keys were authorized
  • whether the witness runtime was attested
  • whether the receipt chain was modified
  • whether the resulting bundle matches durable published evidence

For teams deploying AI agents into regulated or high-impact workflows, this changes the audit model. The evidence is no longer a mutable log controlled by the same system that performed the action. It is a signed, quorum-witnessed, attestation-backed receipt chain that can be verified independently after the fact.

Attexa Verified Actions routes consequential AI-agent actions through a policy boundary and records them as signed, quorum-witnessed receipts. The witness quorum runs in Tinfoil-attested enclaves, so the evidence layer is verifiable end to end. Claude contains the agent, Attexa governs the action, Tinfoil verifies the witness, and Agent Anything is the product surface that puts this architecture in customers' hands.

Get in touch to scope a deployment.

We will map your current AI surfaces, identify a first use case, and put Agent Anything to work for you and your team.

Request access