What are you protecting?
Pick the secret or identity to secure. Each card opens a guide that explains exactly what NoFoundry builds — a hardened Confidential VM on your own cloud, running our agent, attested to our gateway.
Name this project
One project = one protected use case. This name shows on the dashboard, in the audit log and on the recipe.
Where does the key live?
You never paste a key. NoFoundry's recipe mints it by IaC straight into custody — never displayed, not even once. You reference it by name.
Your app changes one line. Point your provider's base URL at the local agent and delete your .env — the key is released only into the attested CVM, your data never transits NoFoundry (Mode B).
Review & prepare
Everything you've chosen, in one place. Pick the environment and confirm the key name — Deploy provisions it. No key value is ever entered or shown.
This project
Name the key
NoFoundry proposes the name — rename the base, pick the environment. A frozen creation date is appended: deterministic and idempotent, so a re-apply never changes it (no random suffix). The value is minted into custody, never displayed.
Security Policies
Per project, define what the silicon must prove. Because identity is the CPU itself, these switches are absolute — not advisory.
A modified agent is rejected at the handshake. Leave empty only in development.
Policy change log
Every change is hash-chained to the one before it and signed by the gateway's attested key. Rewriting history breaks the chain — provably, for an auditor.
Projects
Each project is one protected use case on your own cloud. Open a project to see its machines, settings and danger zone — or watch the whole fleet re-attest below.
Every important step is recorded with dual clocks (gateway + in-guest agent), streamed live, and forwarded to your SIEM (Splunk / Sentinel / Chronicle / Elastic). Policy & security decisions are anchored in the signed, hash-chained policy log — your NIS 2 / DORA evidence trail. Click any row for the raw record.
Verify the verifier
The attestation authority, attesting itself. Don't take our word for it — this is NoFoundry's own silicon, signing root and posture, live.
Project
—
Overview
Machines
Danger zone
Destructive actions on this project. Each is logged with your identity and a reason, then pushed to your SIEM.
Account & preferences
Operator profile and defaults. Authentication here is the human layer (OAuth2 / Passkey in production); your machines authenticate by their CPU.
Authentication
Password sign-in is enabled for this demo. Production adds OAuth2 (GitHub / Google Workspace) and Passkey / FIDO2.
Send feedback
Tell us what's working and what's missing. Tied to your account so we can follow up.
Real-time revocation
MFA stops the login — it can't stop a stolen session. NoFoundry can: the instant the silicon stops vouching, the session dies, mid-flight. This is the real-time containment DORA and NIS 2 art. 21 demand.
The kill-switch
re-attestation
posture fail
Zitadel / Okta / Entra
Splunk / Sentinel / Sekoia
A signed Security Event Token (SSF-CAEP) is pushed to your IdP, which terminates the exact session bound to that machine. The stolen cookie is dead — no waiting for the next login.
Triggers — what kills a session
- Clone — the agent reappears on a different CPU (Chip-ID mismatch).
- Measurement drift — the running binary no longer matches the official build.
- Posture failure — secure boot / vTPM check fails on re-attestation.
Manual kill-switch
Operators can revoke any machine on the spot — every session bound to it dies immediately.
Recent revocations
Retire a machine
When a workload is retired, tear it down cleanly — the Confidential VM, its machine identity, and the sealed secret all go. This is distinct from Revoke (an incident kill-switch): here you remove machines you created and no longer need.
Clean teardown
terraform destroyremoves the Confidential VM you created, the IAM grant, and the HSM-sealed secret.- The machine identity is revoked — any session still bound to it dies (CAEP → IdP).
- No copy of the secret ever existed in your code or RAM — there is nothing left to leak.
Your machines
Pick a machine you created to decommission. (Not a security incident — for that, use Revoke.)
Deployment
Provision the Confidential VM in one terraform apply. The recipe carries only your project id — not a secret. The machine then proves itself by silicon and you approve it here (or it auto-enrolls). Nothing to mint, nothing to paste. Your app needs no rewrite — a CVM is a normal Linux VM; lift-and-shift, repoint one URL.
What you actually do
on your cloudApprove the machine — device flow
demo / live viewerThe CVM proves itself by silicon (genuine SEV-SNP + your pinned code + your cloud account). It then waits for your out-of-band approval here — your console on your PC is a separate channel from the machine, so a compromised CVM can never self-approve. Two paths: a known-good machine (valid token or matching policy) auto-enrolls → it shows up directly in your Dashboard (green), not here; only a machine that needs review steps up to you here. The two buttons below simulate a machine calling in so you can see the flow now — in production your real CVM does this automatically after terraform apply.
Live stream of the CVM startup over the attested tunnel — the agent reports each verify step, then only enrolls after verify.sh confirms SEV-SNP + Secure Boot. live · /api/events · no live CVM yet → replays a sample boot
Advanced — offline enrollment token · on-prem / no cloud identity
Cloud CVMs don't need this — they prove themselves and you approve them above. For on-prem / bare-metal without a cloud instance-identity, fall back to a single-use, 15-minute token the recipe injects into the machine.