What runs inside the protected area, and what does not
Our API service runs inside a protected virtual machine in the cloud. The hardware can prove what it is running. The protected area is built to keep the service's memory hidden from the host software and the cloud provider. Your inputs and outputs are encrypted while they travel. Inside the protected area, the service has to read them to do the work. The hardware's proof is evidence about the setup it measured. It holds only within the stated limits of the platform and the threats it is built to stop. We do not offer a separate Confidential option today. That option would keep each job apart and only send work to hardware that passed a check first.
Inside the protected area
All our workloads run in confidential mode. That includes GPU work: we do not run work on a GPU unless it is in confidential mode. Our API service, including Fabric Verify. Text generation through MCP, a standard way for AI apps to call tools. The key that signs records. The key is made inside the protected area at each restart. The hardware's signed report ties it there.
Stored outside it
Fabric Verify records are kept in storage in the region you choose (EU or US). They hold fingerprints of your data, never the data itself.
Straight talk: "confidential" names a specific boundary you can check. It is not a marketing word. We do not sell a Confidential option.
Evidence that does not rely on our word
Fabric Verify gives you a proof for each record, logged in public. When our agents run, each finished job also gets a signed completion record. Any change to either shows. Our free verifier checks them on your own computer. No account is needed. We keep signed records for at least six months (see our Privacy Policy and DPA).
Who holds the signing keys
The key that signs completion records is made inside our protected area at each restart. It never leaves it. The keys that sign the Fabric Verify log are held in software on our server, not created inside the secure hardware. We still run that environment.
No independent party adds a second signature to records. Records are not held in storage run by a neutral party.
Ask the hardware, not us
Our live hardware proof (called attestation) is public. The key receipt and pinned values are at /verify. For a pilot, we can share hardware reports on request. These are signed evidence, made by the hardware, of the setup your job ran in. The proof shows that the setup is genuine and which setup it is. In short, it shows where your job ran.
The proof has limits. On its own, it does not vouch for what your code does inside that setup. Your code is your responsibility. The protected area around it is ours. During a pilot, we show your security team how to use the check tools and what each claim covers.
Kept up to date, watched and reported responsibly
- Updates. We keep our software up to date, and we apply security updates for the protected hardware platform as they are released. We do not publish version numbers or patch levels (see below).
- Watching for flaws. We watch for known security flaws (CVEs) in our protected-hardware stack. We check whether each one weakens the hardware proof. A flaw that breaks the protected area is a trust emergency for us, not a routine patch.
- Reporting a flaw. Found a security flaw in our platform, our hardware proof or our verification tools? Please tell us at security@augmentev.com. Our disclosure policy is at security.txt.
What we can see, and what we can't
- Inside the service: the protected area is built to hide the service's memory from the host and the cloud provider.
- Spending: each access key has a spending cap, and we enforce it. A call over the cap is refused, not run.
- What we do hold: account and billing details, and signed receipts (kept at least six months). We also hold the operating data needed to run jobs. Stripe processes billing. Our Privacy Policy and published Data Processing Agreement give the legal detail.
- Analytics: this site measures visits without cookies, in a privacy-friendly way. We use only strictly necessary cookies (see the consent notice).
What we choose not to publish
Some details help an attacker more than a buyer, so we do not publish them. These include processor models and steppings, microcode, kernel and hypervisor versions, and node and environment IDs. They also include datacenter, provider layout and patch levels.
This is not evasion. We ask the same of your systems: show the proof, protect the rest. Serious assurance questions get full answers during a pilot, under NDA where needed.
Straight talk: we lead with proof, not reputation. We protect operating details the way we protect your data.
Where we are today
- Certifications: we are not SOC 2 or ISO 27001 certified today, and we won't suggest otherwise. Fabric Verify proofs can be checked by anyone, with cryptography, using our free verifier.
- Security leadership: security at AugmentEV is led by Bassem Kudsi, Founder. He is accountable for the security program, vulnerability disclosure and incident response. Contact: security@augmentev.com.
- Contracts: a published DPA, Terms and Privacy Policy. AugmentEV, Inc. is a Delaware corporation.
- Record-keeping: we keep receipts for at least six months.
- What this page covers: what our product evidence does and does not show. Company and partner documents are shared in private due diligence.
Security questions?
Check a receipt yourself. Or bring your security review to a pilot conversation.
Open the verifier Start a pilot