Private by Default: Running AI Agents with 1Claw Shroud, Darkbloom, and Venice AI

Most teams worry about whether their AI agent will say something dumb. The harder problem is the one nobody talks about at the demo: every prompt your agent sends carries something. Customer messages, internal context, sometimes credentials a tool accidentally pasted in. All of that lands in a third party's logs. And once it is there, you cannot pull it back.

If you actually care about privacy, the standard stack is not enough. The provider sees your raw traffic. Your agent runtime sees the same. Anyone with access to the box your code runs on can read what you sent and what came back. “We do not train on your data” is a policy claim, not a guarantee.

This post is about building an inference path that does not require you to take anyone's word for it. We pair three pieces:

1. 1Claw Shroud, a TEE-hosted LLM proxy that inspects, redacts, and forwards traffic from inside confidential compute.
2. Darkbloom, decentralized inference on hardware-attested Apple Silicon, end-to-end encrypted so the node operator cannot read your data.
3. Venice AI, a privacy-first provider with zero retention plus optional TEE and end-to-end encryption modes.

Used together, you get a chain where the secrets, the inspection step, and the inference itself all happen inside hardware that is provably opaque to the people running it.

What a TEE actually buys you

TEE stands for Trusted Execution Environment. In practical terms, it is a region of a CPU where memory is encrypted and the operating system, the cloud provider, and anyone with physical access cannot read what is happening inside the process. Two pieces matter:

• Confidential memory. Even if someone roots the host, the bytes are encrypted while the enclave is running.
• Remote attestation. The hardware can sign a statement that says “this exact code is running in this exact configuration.” A client can verify that signature before sending data.

This is the same primitive Apple uses for Private Cloud Compute and the same one Google offers in confidential GKE nodes. It is not magic. It does not make a buggy program safe. What it does is shrink the trust boundary. Instead of trusting “the company that runs the cloud,” you trust the silicon vendor and a small, auditable piece of code.

If you skip the TEE, you have moved the problem rather than solved it. Your inspection proxy now sees the plaintext your provider was going to see anyway. You just added a hop.

Shroud, very briefly

Shroud is the LLM proxy that sits in front of your provider. Your agent points at shroud.1claw.xyz instead of OpenAI or Anthropic directly. Shroud authenticates the agent, resolves the provider API key out of the 1Claw vault, runs 20 inspection layers on the prompt, forwards the cleaned request upstream, then runs another set of inspections on the response before handing it back.

The list of things it catches, briefly: vault secrets bleeding into prompts, hardcoded API keys, PII, prompt injection scored on a 0 to 1 scale, context injection from poisoned RAG documents, Unicode homoglyph tricks, zero-width character smuggling, command injection patterns, encoded payloads, exfiltration URLs, markdown-image data leaks, hallucinated credentials in responses, and a per-agent policy engine on top.

The important part for this post is where Shroud runs. It runs inside confidential compute nodes on GKE. So when your agent sends a prompt that contains, say, a customer support transcript, the cloud operator cannot read it during the inspection step. The secret redaction automaton, which is built from the actual secret values in your vault, is constructed and applied inside the enclave. The plaintext only exists where it is supposed to exist.

Where Darkbloom fits

Darkbloom is one of the more interesting things to come out of the DePIN space in 2026. The pitch is simple: there are more than 100 million Apple Silicon Macs sitting idle most of the day. Each one has 64 to 512 GB of unified memory and bandwidth that rivals dedicated GPU boxes. Darkbloom routes inference requests to those machines through a coordinator, with the node operator never able to read the prompt.

The privacy story has four parts:

• End-to-end encryption. Your prompt is encrypted before it leaves the client. The coordinator routes traffic it cannot read. The provider machine decrypts only inside a hardened process it cannot inspect.
• Hardware-rooted keys. Encryption keys are tied to Apple's Secure Enclave. The keys never exist as plain bytes outside hardware.
• Hardened runtime. The provider process uses PT_DENY_ATTACH to refuse debugger attachment and blocks external memory inspection through Hardened Runtime. SIP cannot be disabled without rebooting, which would terminate the process and tear down the keys.
• Per-response attestation. Every reply is signed by the specific machine that produced it. The attestation chain is published and anyone can verify it independently.

The result is a node operator who is paid to run your inference but who cannot read your data. They can pull the plug. They cannot eavesdrop.

You wire Darkbloom into Shroud by storing the API key at providers/darkbloom/api-key in your vault and setting X-Shroud-Provider: darkbloom on the request. Shroud handles the OpenAI-compatible mapping internally.

Where Venice fits

Venice AI approaches privacy from a different angle. It started as a model router for people who wanted the strongest available open-source models without having their conversations stored or used for training. Three modes are worth knowing about:

• Private (default). Inference runs on Venice-controlled GPUs or zero-retention partner infrastructure. Nothing is persisted server-side. Privacy is enforced by contract.
• TEE (Pro). Inference runs inside a hardware-isolated secure enclave with remote attestation. The GPU provider cannot read prompts. The attestation certificate is verifiable by any external party.
• E2EE (Pro). The prompt is encrypted on the client before it leaves. It stays encrypted through Venice's infrastructure and is only decrypted inside a verified hardware enclave. Neither Venice nor the GPU operator can see your data at any point.

Venice currently supports both TEE and E2EE for around a dozen models, including Venice Uncensored 1.1, GLM 5, Qwen3.5 122B, Gemma 3 27B, and the GPT OSS family. The catalog grows over time.

The same wiring pattern applies. Store the key at providers/venice/api-key, set X-Shroud-Provider: venice in your request to Shroud, and Shroud handles the rest.

The full path

Put these together and your agent's prompt travels through three TEE boundaries on its way to a response:

1. Agent makes a request. Shroud authenticates it using the agent's short-lived JWT.
2. Shroud, running inside confidential compute, decrypts the request and runs its 20 inspection layers. Vault secrets get redacted. PII gets masked. Prompt injection gets scored. Anything that exceeds policy gets blocked before it ever reaches an upstream provider.
3. Shroud forwards the cleaned request to Darkbloom or Venice. With Darkbloom, the prompt is encrypted with hardware-rooted keys and only decrypted inside a hardened process on attested Apple Silicon. With Venice in TEE or E2EE mode, the prompt is delivered into a hardware-isolated enclave with remote attestation.
4. The response travels the same path in reverse, with Shroud running response-side inspection (echoed injection, exfil URLs, hallucinated credentials, markdown image data URIs) before the agent ever sees it.

At no point on this path is the plaintext sitting on a machine where a human operator can dump memory and read it. Compare that to the default stack, where the prompt sits in plaintext on at least three different servers and ends up in provider logs by default.

A quick example

Here is what a real request through this stack looks like. The agent is calling Shroud, which will forward to Venice's TEE-backed model.

curl -X POST "https://shroud.1claw.xyz/v1/chat/completions" \
  -H "X-Shroud-Agent-Key: $AGENT_ID:$AGENT_API_KEY" \
  -H "X-Shroud-Provider: venice" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "venice-uncensored-1.1",
    "messages": [
      {"role": "user", "content": "Summarize the attached customer complaint."}
    ]
  }'

Or with Darkbloom:

curl -X POST "https://shroud.1claw.xyz/v1/chat/completions" \
  -H "X-Shroud-Agent-Key: $AGENT_ID:$AGENT_API_KEY" \
  -H "X-Shroud-Provider: darkbloom" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3-235b",
    "messages": [
      {"role": "user", "content": "Triage this support ticket."}
    ]
  }'

No provider API key in the header. Shroud pulled it from the vault. No raw secrets in the prompt. The Aho-Corasick automaton scrubbed them. No way for the inference operator to read the request. The hardware enclave will not let them.

When this matters

Three situations where the default stack will eventually bite:

• Regulated data. If you process health, financial, or legal data, “the provider promises not to train on it” is a thin defense in an audit. Hardware-backed isolation with remote attestation is a much stronger story.
• Adversarial environments. If your agent runs in front of users you do not control, you have to assume some of them are actively trying to poison RAG sources, inject system prompts, or pull secrets out of context. The 20-layer inspection in Shroud is built for that. The TEE makes sure the inspector itself is not the next attack surface.
• Sensitive internal context. Source code, customer lists, M&A documents. These should not show up in a provider log because someone accidentally pasted them into a tool call.

The agents you build are going to outlive any single trust assumption you have today. Building on hardware-rooted privacy now is much easier than retrofitting it later.

Getting started

If you want to try the path:

1. Spin up a free 1Claw account and create a vault.
2. Add your provider key under providers/darkbloom/api-key or providers/venice/api-key.
3. Create an agent, enable Shroud, and grant it read access to that path.
4. Point your agent at https://shroud.1claw.xyz/v1/chat/completions with the headers above.

Full details on per-agent config (PII policy, injection thresholds, allowed models, daily budget caps) live in the Shroud docs. The provider-specific pages cover Darkbloom and Venice model IDs and any caveats.

Privacy is not a feature you bolt on after launch. It is a property of the path your data travels. With Shroud in front and Darkbloom or Venice behind it, that path stops being a hope and starts being something you can verify.