Shroud TEE proxy

Shroud is an OpenAI-compatible LLM proxy running inside a confidential GKE node with AMD SEV-SNP. Your agent sends chat completions to Shroud instead of the provider. Shroud authenticates the agent, resolves the provider key, runs threat detection and secret redaction, then forwards the request. Secrets never leave your infrastructure in the clear.

• Endpoint: POST https://shroud.1claw.co/v1/chat/completions
• X-Shroud-Agent-Key: agent_id:api_key (the agent's ocv_ key)
• X-Shroud-Provider: openai, anthropic, google, gemini, and others
• Secret redaction, PII detection, and prompt-injection scoring run before the model sees the prompt

1. 1

   Set your agent credentials. Replace with your agent_id from agent creation and your ocv_ key from the agent's settings page.

   bash Copy

   export ONECLAW_AGENT_ID="your-agent-id-from-agent-creation"
   export ONECLAW_AGENT_API_KEY="ocv_your_agent_api_key"

2. 2

   Quick start: pass your provider key directly via X-Shroud-Api-Key. For production, store the key in the vault at providers/openai/api-key and grant the agent read access instead.

   bash Copy

   curl -s -X POST https://shroud.1claw.co/v1/chat/completions \
     -H "X-Shroud-Agent-Key: $ONECLAW_AGENT_ID:$ONECLAW_AGENT_API_KEY" \
     -H "X-Shroud-Provider: openai" \
     -H "X-Shroud-Api-Key: sk-your-openai-key" \
     -H "Content-Type: application/json" \
     -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Hello"}]}'

3. 3

   Parse the response. It follows the standard OpenAI shape.

   bash Copy

   curl -s -X POST https://shroud.1claw.co/v1/chat/completions \
     -H "X-Shroud-Agent-Key: $ONECLAW_AGENT_ID:$ONECLAW_AGENT_API_KEY" \
     -H "X-Shroud-Provider: openai" \
     -H "X-Shroud-Api-Key: sk-your-openai-key" \
     -H "Content-Type: application/json" \
     -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Hello"}]}' | jq -r '.choices[0].message.content'

Your agent's LLM traffic now flows through the TEE proxy, inspected and redacted, with a normal OpenAI-style response coming back.

Where this goes wrong in practice. A TEE proxy is easy to deploy and easy to hold wrongly, because it produces a strong feeling of safety that outruns what it actually guarantees.

• Attestation is enabled but never verified. The hardware signs a measurement of what loaded; if nothing on your side checks that measurement against an expected value, you have the ceremony without the assurance.
• One caller bypasses the proxy. Unless intents_require_tee or execution_require_tee is set, direct API calls still work, and the service written before the proxy existed keeps using the path it always used.
• Redaction is assumed to be complete. Inspection catches known secret values and recognisable patterns. A credential in a format it has never seen passes through, which is why the proxy is a layer rather than a guarantee.
• Latency pressure erodes it. Every referral, prompt or completion pays the proxy cost, and the first performance review proposes a fast path around it for "internal" traffic.