Your Agent Has Been Leaking Secrets. Here Is What We Did About It.

We built 1claw because we kept running into the same uncomfortable reality: the most capable AI coding agents in the world have absolutely no idea how to handle secrets.

Not because the models are bad. Because the tooling around them was never designed for this. When you give an agent an API key, it gets pasted into the context window, it floats around in logs, it ends up in conversation history. The agent does its job and the key just… stays there. Visible. Retrievable. Effectively public inside whatever system is running the agent.

OpenClaude is an open-source coding agent CLI that runs anywhere and uses anything. It talks to OpenAI, Gemini, Ollama, Atomic Chat, GitHub Models, and a dozen other providers. It does real work: bash, file editing, grep, glob, MCP, multi-step tool loops. It is genuinely good at what it does.

But until now, if you wanted to give OpenClaude access to a production credential, you had the same problem every other agent user has. You put the key somewhere the agent could see it, and hoped for the best.

We wanted to fix that properly. So we built native 1claw support directly into OpenClaude.

Big credit where it is due: GitLawb

Before getting into what we built, the OpenClaude project deserves a proper shoutout to GitLawb. They are the original maintainers of the upstream repo that 1claw AI forked from, and they have been doing genuinely interesting work on decentralized git infrastructure for AI agents. The full diff between the upstream GitLawb repo and our 1claw integration branch lives here if you want to dig into exactly what changed.

GitLawb's vision of agents as first-class citizens in a git workflow, with DID-based identity, UCAN capabilities, and IPFS-backed storage, is the kind of infrastructure thinking the agentic ecosystem needs more of. OpenClaude being mirrored at gitlawb.com is not an accident. It is because these two projects share the same conviction: agents need real infrastructure, not workarounds.

What the 1claw integration actually does

When you run OpenClaude with the 1claw integration enabled, three things change in how the agent handles credentials and LLM traffic.

Vault: Secrets at runtime, not in context

The 1claw Vault is an HSM-backed secret store built specifically for agent workloads. Instead of hardcoding a credential or passing it in as an environment variable that ends up in logs, OpenClaude fetches secrets from the Vault at the moment they are needed.

The agent authenticates with a short-lived JWT. The JWT expires in minutes. The secret is fetched, used, and discarded. It never appears in the context window, never lands in a log file, never ends up in conversation history. The audit trail records which agent accessed which secret path and when. You can revoke access to a single agent without touching the underlying credential.

For teams running OpenClaude against production environments, this is the difference between hoping nothing leaks and actually knowing nothing leaked.

Shroud: Everything the agent sends gets inspected

Shroud is a TEE-backed LLM proxy that sits between OpenClaude and whatever model provider you are using. Every request the agent makes goes through Shroud before it reaches the model. Every response comes back through it too.

Inside the TEE, Shroud runs an 11-layer threat detection pipeline. It catches prompt injection attempts. It normalizes Unicode homoglyphs. It detects social engineering patterns in responses. Most relevantly for agent use: it redacts secrets before they reach the model provider.

If the agent somehow ends up constructing a prompt that includes a database connection string or an API key, Shroud catches it, redacts it, and the model provider never sees the raw credential. The audit log records the redaction. You get a tamper-evident record of what was caught and why.

For OpenClaude users this means you can point the agent at real infrastructure without needing to trust that every tool call and every synthesized prompt will stay clean. Shroud is the layer that verifies that assumption rather than hoping it holds.

Intents API: Agents that can sign transactions without holding keys

For teams building on-chain agents with OpenClaude, the Intents API is the piece that changes the threat model completely. Instead of an agent holding a private key in memory, it submits transaction intents to the signing infrastructure. The key stays in the HSM or TEE. The agent gets back a signed transaction.

Per-agent guardrails let you set address allowlists, value caps, chain restrictions, and daily limits. When Intents is enabled, the agent cannot read the private key at all. It can only submit intents that pass the configured guardrails. Tenderly simulation runs before broadcast. Nonce management is automatic. Replay protection is built in.

If you are running an autonomous DeFi agent or a treasury management workflow on top of OpenClaude, this is what controlled transaction signing looks like in practice.

Why we built it this way

The obvious approach would have been to build a standalone 1claw CLI or a separate wrapper. We did not do that because it creates friction developers do not need.

OpenClaude is already where the work happens. It is the terminal session that is already open, the agent that already has tool access to the codebase. Adding secret management as a native integration means it is zero-configuration overhead once you have set it up. The agent just works securely, rather than requiring a separate process or a manual fetch-and-inject step.

We also wanted the integration to be useful for the full spectrum of OpenClaude users. Someone running a local Ollama model who just wants to not paste keys into prompts gets Vault. A team running agents against cloud infrastructure who needs audit trails and revocation gets Shroud on top of that. A protocol team building autonomous on-chain tooling gets the Intents API on top of that. The layers stack independently.

The MCP server integration is part of this too. 1claw exposes 27-plus MCP tools natively, which means OpenClaude can interact with vault operations, audit log queries, and agent configuration directly through the tool loop, the same way it interacts with bash or file operations. No context switching.

Setting it up

Getting the 1claw integration running with OpenClaude takes three steps.

Clone and set up OpenClaude

git clone https://github.com/1clawAI/openclaude
cd openclaude
bun install && bun run build

Then run the interactive setup wizard to provision your vault, agent, and provider configuration in one step:

bun run setup

The setup prompts for your 1claw API key (1ck_ prefix), your preferred LLM provider, and auth mode. It creates a vault, mints an agent, stores your provider key, and writes the local config file. After that, OpenClaude is fully wired to 1claw with no manual configuration.

Add the MCP server (optional)

The native integration handles vault access and Shroud routing automatically. If you also want MCP tool access (for vault operations, audit queries, etc. inside the tool loop), add the hosted server to your .mcp.json:

{
  "mcpServers": {
    "1claw": {
      "url": "https://mcp.1claw.xyz/mcp",
      "headers": {
        "Authorization": "Bearer <token>",
        "X-Vault-ID": "<vault-id>"
      }
    }
  }
}

From this point, OpenClaude can fetch secrets from the Vault through the tool loop. To enable Shroud, point your model provider base URL at the Shroud proxy and add your provider in the X-Shroud-Provider header. The Shroud docs cover per-agent configuration for PII policy, injection thresholds, blocked domains, and token caps.

For Intents API setup, register an agent with intents_api_enabled: true and configure your per-agent guardrails before the agent starts running.

The actual problem this solves

There is a 2026 State of Agentic AI Threats report on the 1claw site that goes deep on the attack surface. Prompt injection at CVSS 9.6. Supply chain compromises in the billions. The threat categories are real and the incident timelines in that report are not hypothetical.

The core issue is that most agent tooling was built for demos and prototypes. The mental model is still: give the agent a key, watch it work, hope nothing goes wrong. That works fine when the agent is running against a sandbox. It stops working the moment the agent touches production infrastructure.

OpenClaude is powerful enough that it should be running against real environments. The 1claw integration is what makes that safe to actually do.

The diff is public. The code is open. Go look at what changed and build something real.

GitHub: 1clawAI/openclaude • 1claw.xyz • GitLawb