Everything about Blindfold

It's layered on purpose. What you run: a CLI (blindfold …) plus a local proxy. Where the secret lives: an Intel TDX enclave on Terminal 3. What runs in the enclave: a Rust→WASM contract that swaps the key in and makes the real API call. How an AI agent uses it: an optional Skill (Claude Code / OpenCode) that routes the agent through it. One line: a CLI + proxy that seals your key inside an Intel TDX enclave on Terminal 3; the contract swaps the key in and returns only the result, so the agent never holds the real key.

A TEE (Trusted Execution Environment) is a hardware-isolated region of a CPU. Intel TDX runs a memory-encrypted "confidential VM" — the chip encrypts its RAM so the host OS, the cloud operator, and even root can't read what's inside. Blindfold keeps your real key there.

Intel TDX is the CPU hardware that encrypts the memory. Terminal 3 is the platform that runs Blindfold's contract on that hardware and handles tenant identity, the egress allowlist, and metering. So: Terminal 3 runs the contract on Intel TDX — TDX does the encryption, T3 is the platform. (Don't say "Terminal 3 encrypts it.")

It's live on npm (@fiscalmindset/blindfold, MIT), self-serve, and runs on Terminal 3's Intel TDX. The strongest guarantee is the proxy path, where the key never leaves the enclave. It's early and open source — see the honest limitations below.

Your agent sends Authorization: Bearer __BLINDFOLD__. That request is forwarded into the enclave, where the contract's forward() reads the sealed key from the secrets map, replaces the __BLINDFOLD__ sentinel with the real key, applies the auth scheme, and makes the HTTPS call — all inside TDX-encrypted memory. Only the response comes back; the key never leaves.

You point the agent at the local proxy (e.g. OPENAI_BASE_URL=http://127.0.0.1:8787/v1) and set the key to __BLINDFOLD__. The agent makes a normal API call with the sentinel; the proxy forwards it to the enclave. Your agent code doesn't change beyond those two env vars.

(a) Proxy / forward — strongest; the key never leaves the enclave. (b) Release broker — the real value is released into one subprocess for a single command, then dropped (for non-HTTP tools). (c) Register / seed — the one-time seal, the only moment you hold the plaintext. See the "Three ways" section on the home page.

Install the Skill: blindfold skill install. It drops a rulebook into .claude/skills/ that tells the agent — when a secret is involved, route through Blindfold (proxy or release) instead of reading process.env. You just ask normally ("read my Google Sheet") and it uses the sealed key.

Blindfold ships first-class providers (OpenAI, Anthropic, Gemini, Stripe, GitHub, Twilio, AWS, Slack, SendGrid, Discord…). For anything else: grant egress (blindfold grant --host your.api.com) and add a one-line provider entry with its host + auth scheme (bearer / basic / sigv4 / webhook). Or use the release path for non-HTTP tools.

No. At seal time the value goes from your terminal straight into the enclave's secrets map — never printed, logged, or written to disk. After that the plaintext only exists inside TDX during a single call. The proxy, the CLI, and the maintainer never see it.

The agent process only ever holds __BLINDFOLD__. There's no real key in its memory or context to exfiltrate — convincing it to "print the key" prints the sentinel. The swap happens inside the enclave, after the request has already left the agent.

The release path does hand the real value to your local process for one command — that's its trade-off, and it's meant for non-HTTP tools and CLIs. It's injected as an env var into a single subprocess and dropped; it never goes back into your shell. For a fully un-leakable path, use the proxy — the key never leaves the enclave.

Release requires your tenant key (T3N_API_KEY), which authenticates to Terminal 3. Keep that key out of the agent's reachable environment (terminal-side only). If the agent can't authenticate to T3, it can't release. Getting this right is the core of the release path's safety.

Remote attestation. blindfold attest pins the RTMR3 code measurement and verifies the TDX quote, which chains to the Intel SGX root CA. You confirm the enclave is running your exact contract before trusting it — and Blindfold can auto-refuse an unverified enclave.

The proxy supports a per-session auth token (--auth) and a unix-domain-socket mode (--socket), so only your agent process can reach it — not another local process or a web page. Egress is also enforced server-side in Terminal 3 (a deny-by-default host allowlist), so it can't be bypassed from the client.

Those solve storage & rotation — but they hand the plaintext key to the process that makes the API call, so a prompt-injected agent can still leak it. Blindfold solves use: the agent calls the API without ever holding the key. It's complementary — keep your vault, and put Blindfold in front of the agent.

The proxy path is the strongest — the key stays in the enclave. The release path returns plaintext locally for one command, so its safety rests on keeping your tenant key (T3N_API_KEY) out of the agent's reach. It's early and open source. Attestation, per-session proxy auth, and the socket mode close the main gaps; the residual risk to manage is tenant-key reachability.

The enclave runs on Terminal 3's Intel TDX infrastructure — that's the confidential-compute platform Blindfold's contract is published to, so you don't operate the TDX hardware yourself. What you do self-host is everything on your side: the open-source CLI, SDK, and local proxy (all MIT). The Rust→WASM contract is open source too, so you can review it, build it, and publish it to your own Terminal 3 tenant. Running TDX hardware entirely outside Terminal 3 isn't supported today.

Your sealed key lives inside the Terminal 3 enclave's secrets map — that's the whole point; it's the only copy. Locally, Blindfold keeps metadata only: a tamper-evident ledger (~/.blindfold/sealed.jsonl) recording key names, byte-lengths, and tenant/map info — never values. Your tenant key sits in your OS keychain (or a 0600 config file). No plaintext secret is written to disk, and nothing is sent to the maintainer or any third party beyond Terminal 3 and the API you're actually calling.

They solve a different half of the problem. Password managers (1Password, Bitwarden, macOS Keychain) store & autofill secrets for humans — but they decrypt the value into the app/process that uses it, so an agent still holds the plaintext. KMS (AWS/GCP KMS) manages encryption keys and can encrypt/decrypt for you, but the decrypted secret lands in your process. HSMs keep keys in tamper-resistant hardware for signing/encryption — great for crypto ops, not for making an authenticated call to a third-party API with an API key. Blindfold is the only one that makes the API call itself inside the enclave and substitutes the key there, so for the "agent calls OpenAI/Stripe/GitHub" use case the agent never holds the plaintext. It complements a vault/KMS — keep them for storage, put Blindfold in front of the agent.

npm i -g @fiscalmindset/blindfold && blindfold signup — signup mints a funded testnet tenant automatically (no manual token, no waiting on anyone). Then blindfold register --name your_key to seal, and blindfold proxy / blindfold use to use it. Self-serve means a stranger can go from install to working entirely on their own.

Mechanics: 1 token = 1,000,000 base units; one enclave operation ≈ 20 tokens (measured live). Signup grants ~20,000 tokens ≈ ~1,000 ops. Price: on testnet it's free ($0). The production dollar-per-token price is Terminal 3's to set — it isn't in the code or SDK, so we don't quote a number we can't stand behind. Cost stays proportional to sensitive-key usage, and release-once-reuse collapses it for high-volume workloads.

Any. The proxy is a plain local HTTP endpoint — anything that makes an HTTP request (Node, Python, Go, curl, any agent framework) works by pointing at it and sending the sentinel. The release path wraps any command with an injected env var.

The contract compiles to WASM (wasm32-wasip2) and runs on Terminal 3's TDX runtime. Rust gives memory safety and a small, auditable, dependency-light binary — exactly what you want for the one piece of code that touches the plaintext key.

Sealing is the one moment the plaintext is handled, so it's deliberate: you type it with input hidden (no echo, no shell history), and it goes straight to the enclave. Auto-scraping .env would silently ingest whatever's lying around — an explicit register (or --from-env) keeps you in control of exactly what gets sealed.