The day the bill arrived
In February, a three-person startup in Mexico opened its cloud dashboard and found a bill for $82,314.44, run up in about 48 hours using a compromised Google Cloud API key, mostly on Gemini models. They normally spent around $180 a month. When they asked for relief, a Google representative reportedly cited its shared responsibility model, under which customers secure their own credentials (The Register, Mezha). How the key leaked is disputed, and researchers have separately shown that older public Google keys can quietly gain Gemini access.
That is a leaked key. Now consider what happens when the thing holding your credentials can be talked into misbehaving.
In April, researcher Aonan Guan and colleagues from Johns Hopkins showed that a crafted pull request title could make Anthropic’s Claude Code Security Review action post its own API key as a “finding.” Similar text-only attacks worked against Google’s Gemini CLI Action and GitHub’s Copilot agent (SecurityWeek, ThreatCluster). Some fairness is due. Anthropic has said the action is not designed to be hardened against prompt injection, GitHub had three runtime protections in place (environment filtering, secret scanning, and a network firewall), and the Copilot attack required the victim to assign the issue to the agent. The lesson is not that these vendors were careless. It is that a credential inside a component that reads untrusted text is a standing risk.
Then there is money. On May 4, 2026, an attacker got the wallet tied to Grok on Base to send about 3 billion DRB tokens by hiding a transfer instruction in Morse code, which Grok decoded and passed to Bankr’s bot. Estimates of the loss range from about $150,000 to $200,000 (AI Incident Database, Startup Fortune). The attacker had first gifted the wallet a Bankr Club Membership NFT that unlocked broader transfer permissions, so a permission gate was bypassed socially, not technically. In fairness to the ending, Bankr reportedly got about 80% of the funds back after the attacker was identified (Ledger Academy).
Three incidents, one shared shape: something powerful (a key, a token, a wallet) was within reach of a component that could be fooled, leaked, or misused. As agents move from demos to real work with real API keys, databases, and money, this stops being an edge case and becomes the default risk.
Here is the idea the rest of this piece rests on: a limit written into a system prompt is a suggestion, while a limit enforced at the signing layer is a rule. An injected instruction can talk a model into almost anything. It cannot talk a server-side guardrail into approving a transfer to an address that is not on the list.
1Claw is built around that principle: agents should be able to use credentials without ever holding them.
What 1Claw is
1Claw is a secrets and credentials platform designed for AI agents. At its core is a vault where you store API keys, database passwords, and private keys. According to 1Claw’s documentation, the vault is backed by a Hardware Security Module (HSM). Around it sit scoped access policies, short-lived tokens, an audit trail, an LLM proxy, and a transaction-signing service.
Instead of pasting a key into a prompt, an environment variable, or a config file, you register your agent and decide exactly what it may touch. The agent asks for access at runtime, gets only what its policy allows, and every request is logged. If something looks wrong, you revoke it.
It works with tools you likely already use: an MCP server for clients like Claude and Cursor, a REST API, a CLI, a dashboard, and SDKs for TypeScript, Python, and Go, with wrappers for frameworks like LangChain and CrewAI.
How it works
Vaults and secrets. Secrets live at paths, with versioning and rotation, and environment variables can be scoped across production, preview, and development. Two advanced options matter for the trust discussion later: client-side encryption with your own key (CMEK), so a value is encrypted before it reaches 1Claw, and multi-party computation (MPC), which splits key material across several cloud providers so that compromising one is not enough to decrypt anything.
Policies. Access is granted by policies that match path patterns and apply to specific users or agents, optionally with conditions like IP ranges and time windows. The default is deny: an agent with no policy has zero access.
Two kinds of principals. Humans sign in to the dashboard and manage vaults, agents, and policies. Agents authenticate with an agent key, which the API exchanges for a JWT that lasts 15 minutes, with scopes derived from the agent’s policies. An agent can list secret metadata, but it can only fetch a value where a policy permits it.
A clear split of authority. Humans configure and approve, and agents act within limits. An agent cannot create its own bindings, channels, delegations, or signing keys. Those calls fail by design.
Audit and risk signals. Every access is recorded. A built-in risk engine scores unusual behavior such as impossible travel or a first-seen device, and it supports honeytokens: decoy secrets that should never be read. If one is touched, the principal’s sessions are revoked.
The features that matter most
Shroud: an LLM proxy that inspects what goes in and out
Shroud sits between your agent and the model provider. You point a standard OpenAI or Anthropic SDK at it using a router key. 1Claw documents that traffic passes through 20 inspection layers running inside a trusted execution environment (TEE), catching secrets in prompts, prompt injection attempts, suspicious URLs, and PII, with per-agent tuning.
The detail worth noting is the placeholder swap. Per the documentation, when a vault secret appears in a prompt, Shroud replaces it with a placeholder, and the real value is restored only inside the enclave, only for tool arguments the agent is authorized to use. The intent is that the model never sees the secret. Streaming responses are inspected frame by frame, and ten providers are supported, including OpenAI, Anthropic, Google, and OpenRouter. (1Claw Documentation)
Intents: transactions signed without exposing keys
For onchain agents, this is the standout. With the Intents API, an agent submits a transaction and the server signs it with a key the agent never sees. It covers six chain families: EVM networks (Ethereum, Base, Optimism, Arbitrum, Polygon), Bitcoin, Solana, XRP, Cardano, and Tron.
What matters is what runs before signing. Guardrails you define are enforced server-side, outside the model’s reach:
- Chain and recipient allowlists
- Per-transaction caps
- Daily limits per chain family
- Token allowlists
When agent-level and per-chain limits both exist, the stricter one wins. There is replay protection through idempotency keys and server-managed nonces, a simulate-first option, bring-your-own-key import, and an option to require signing inside a TEE.
Apply this to the Grok incident. A transfer that needed a recipient on an allowlist and fit under a per-transaction cap would not have been approved no matter how persuasive the injected message was. The weakness in that story was a permission gate that could be unlocked socially. A guardrail enforced at the signing layer has no such door.
Bindings and execution intents: use the credential, never see it
Not every secret is a private key. For HTTP APIs, GraphQL, Postgres, Redis, SMTP, S3, and more, 1Claw offers bindings. A binding is a named handle to a credential. The agent calls an /execute endpoint with the binding name, and the server injects the real credential into the request.
Bindings can pin allowed hosts and paths, block server-side request forgery, and point at a live vault secret so rotation propagates automatically. Guardrails can also run in log mode first, recording what would have been denied before you switch to enforce, which makes tightening a setup far less risky.
Human approval where it counts
Sensitive changes can require a person. Widening a guardrail can trigger an approval request. Delegation between agents is created by humans, with limits on depth, daily count, tool allowlists, and expiry. For purchases, step-up authentication scales with the amount.
A few more safe-access tools
Connectors give agents one-call OAuth access to services like Gmail, Slack, GitHub, Notion, and Stripe, pinned to specific hosts and paths. Browser Bridge lets an agent log into a site without holding the password. Key vending leases short-lived wallet keys that never appear in tool output.
1Claw also includes managed agent runtimes, workflow automations, a platform API for multi-tenant products, and treasury and prepaid-card features. They are outside the scope of this piece, which is about the credential problem. See the docs for details.
How this differs from what you already use
The obvious question is how this differs from HashiCorp Vault with OIDC, Doppler, Infisical, or an MPC wallet provider. Those tools solve storage, access control, and key custody well, and if your problem is humans and services sharing secrets, they may be all you need. What 1Claw is aiming at is narrower and agent-specific: a placeholder swap that keeps secrets out of the model’s context, server-side transaction guardrails designed for an actor that can be socially engineered, and MCP-native access so agent clients can use it directly. Whether that is worth adopting a newer product over a mature one is a judgment call, and it depends on how much your agents touch.
An honest word on limits
1Claw does not make prompt injection impossible, and it will not stop a provider from billing you for misuse of a key you leak elsewhere. What it aims to do is shrink the blast radius: if an agent is fooled, the damage is limited to what its policy allowed, enforced somewhere the agent cannot reach. You still have to write good policies. Least privilege is still your job.
The concentration-of-risk objection. A fair question is what happens if 1Claw itself is compromised or goes down. Putting credentials in one place creates a more attractive target, and that is a real tradeoff. Two features address part of it. With CMEK, you encrypt a value with your own key before it reaches 1Claw, so a breach of the vault alone does not expose that plaintext. With MPC, key material is split across several cloud providers, so compromising one is not enough to decrypt anything. Neither removes the trust you place in the service, though. Secrets that must be restored inside the enclave for Shroud, or used server-side for bindings and signing, depend on the enclave and the service behaving as documented. And an agent that fetches credentials at runtime will fail if the service is unavailable, so plan for that failure mode, including which tasks should stop and which need a fallback.
Questions to ask before adopting it. Is it open source? Partly. According to 1Claw’s licensing page, the SDK, CLI, MCP server, and OpenAPI spec are MIT licensed, so you can inspect, fork, and use them commercially. The pieces that actually hold your keys, namely the Vault API, Shroud, and the transaction-signing backend, are proprietary managed services. The docs say the Vault API source sits in 1Claw’s monorepo under a proprietary license, so that is not open source. In practice, you can verify the client side yourself but have to trust the vendor on the server side. Can I self-host it? Only through an Enterprise arrangement. This is also a young product, so expect the surface area to keep changing.
The bottom line
The pattern behind these incidents keeps repeating: powerful credentials sit within reach of components that can be tricked or leaked. 1Claw’s answer is to separate using a credential from holding it: give the agent the ability to act, keep the secret in a vault the model cannot read, and enforce limits somewhere the model cannot argue with. Whether or not you use this product, that separation is a good design principle for any agent that touches real keys or real money.
If you want to try it, npx @1claw/cli setup creates an agent, a vault, a policy, and a sample secret, and configures MCP for the clients it detects. A sensible first step is to move one real API key out of a .env file, scope the agent’s policy to that path, and check the audit log after it fetches the key.