What runs inside the seal — and what doesn't.
Confidential-tier jobs execute inside a hardware-attested trusted execution environment (Intel TDX). The environment is sealed from the machine's owner, the operator, and AugmentEV itself: inputs enter encrypted, outputs leave encrypted, and the memory in between is not readable by anyone outside the boundary. The guarantee is rooted in the processor, not in our policy — attestation is anchored in hardware, which is why it can be checked independently of our word.
Inside the boundary
Confidential-tier workload execution, inside the hardware-attested environment. Inputs and outputs isolated from host and operator. Fail-closed: if the environment can't be verified, the job is rejected, not run.
Outside the boundary
Standard-tier and burst GPU execution runs on non-enclave nodes. Those jobs still carry the post-quantum-signed receipt — proof of what ran — but not the enclave guarantee. We say so on the pricing page, not in a footnote.
Straight talk: "confidential" means a specific, named tier with a specific, named boundary — not a marketing adjective applied to everything we run.
Evidence that doesn't depend on our word.
Every job — every tier — returns a Proof-of-Task-Execution: a tamper-evident record of exactly what ran, signed with ML-DSA-65 (NIST FIPS 204), a post-quantum digital-signature standard. Anyone can verify a receipt independently — in the browser or with one curl call — with no account and nothing installed. Receipts are retained in tamper-evident form for at least six months, aligned with EU AI Act Article 12 record-keeping expectations.
Key custody, stated plainly
Receipt-signing keys are held by the platform today. On the roadmap — and labeled as roadmap everywhere we mention it — is countersignature by an independent custodian's hardware security module and write-once neutral custody, so that no party to a job, including us, can alter, reorder, or drop the record. FIPS 140-3 validated cryptographic modules for the signing path are also on the roadmap.
Ask the hardware, not us.
For confidential-tier customers and pilots, attestation quotes are available on request: cryptographic evidence, produced by the hardware, of the environment your workload ran in. An attestation proves the genuineness and identity of the execution environment — it is evidence about where your job ran.
Its scope has limits, and we'll state them: attestation does not, by itself, vouch for what your workload's code does inside the environment — that remains your code's responsibility, and ours is the boundary around it. During pilots we walk your security team through verification tooling and what each claim covers.
Current, monitored, and disclosed responsibly.
- Patch cadence. Firmware and microcode relevant to the confidential-computing stack are kept current with vendor releases. We do not publish version numbers or patch levels (see below) — but we do commit to the practice.
- CVE monitoring. We track vulnerabilities affecting the confidential-computing stack and assess their impact on attestation validity — a CVE that undermines the boundary is treated as a trust emergency, not a routine patch.
- Coordinated disclosure. If you believe you've found a vulnerability — in our platform, our attestation path, or our verification tooling — we want to hear from you: security@augmentev.com. Our disclosure policy is published at security.txt.
What we can see, and what we can't.
- Confidential tier: we cannot see into your workload. Inputs and outputs are sealed inside the boundary; the platform routes, meters, and proves — it does not observe content.
- Every tier: jobs carry hard cost and runtime caps you set, enforced by the platform. Fail-closed means unverified jobs are rejected, never run unverified.
- What we do hold: account and billing details (processed by Stripe), the signed receipts (≥6-month tamper-evident retention), and operational metadata needed to run jobs. Our Privacy Policy and published Data Processing Agreement describe handling in legal detail.
- Analytics: cookieless, privacy-friendly measurement on this site; strictly necessary cookies only (see the consent notice).
What we deliberately do not publish.
Some details aid an attacker more than they inform a buyer, so we don't publish them: processor SKUs and steppings, microcode versions, kernel and hypervisor versions, node and environment identifiers, region, datacenter, or provider topology, and patch-level specifics.
This isn't evasiveness — it's the same discipline we ask of your workloads: expose the proof, seal the rest. Substantive assurance questions get substantive answers in the pilot process, under NDA where appropriate.
Straight talk: we lead with proof, not pedigree — and we protect operational detail the way we protect your data.
Where we are, honestly.
- Certifications: we are not SOC 2 or ISO 27001 certified today, and we won't imply otherwise. What you can rely on today is per-job, independently verifiable evidence. Dated commitments land on the changelog.
- Contracts: a published DPA, Terms, and Privacy Policy; AugmentEV, Inc. is a Delaware corporation.
- Record-keeping: ≥6-month tamper-evident receipt retention, aligned with EU AI Act Article 12 expectations.
- Ecosystem: member of NVIDIA Inception; listed on the Model Context Protocol registry; patents pending.
Assurance questions?
Verify a receipt yourself — or bring your security review to a pilot conversation.
Open the verifier Start a pilot