An Agent Launched a Token on Base. It Never Held a Key.

I'll be honest about the thing that nags at me with all the agent hype right now. We keep handing these things more power. Buy this, swap that, deploy a contract, move the money. And to do any of it, the agent needs keys. So we give it keys. We stuff them in an env file, or worse, somewhere the model can read them, and then we cross our fingers that nothing gets prompt injected and nothing spills into a log. That is the real security model behind a lot of what is shipping today. Cross your fingers.

I wanted to see if we could keep the capable part and drop the cross your fingers part. So a few of us built a small reference agent and put it on GitHub. You run one command. The agent goes off and does a full loop of real work across four different systems, and at no point does it ever hold a private key. Not in memory, not in an env file, nowhere it can leak from.

What actually happens when you run it

It starts by giving itself an identity. Not a password, a did:key derived from a key that lives inside an HSM over at 1Claw. The agent gets something it can prove it owns without ever seeing the secret behind it.

Then it spins up a repo and pushes it to GitLawb, which is git but decentralized, running over IPFS instead of somebody's servers. No account, no central host, just a push to a peer to peer node.

Next it writes its own code. The agent asks a model to generate an agent.ts file, but the request does not go straight to the model. It runs through Shroud, which sits inside a secure enclave and reads the whole exchange for injection attempts and leaking secrets before anything comes back. So even the step where the agent writes code is being watched.

Then the fun one. It launches a token on Bankr, on Base. Ticker, name, done. This is the same idea Bankr is built around, an agent that spins up a token whose trading fees can cover its own running costs.

And finally it does a swap to deal with those fees. This is the step I care about most. The agent does not sign the transaction. It cannot. It sends an intent that says what it wants to do, and the signing happens inside the enclave on a key that never leaves the hardware. The transaction lands on Base. The key stays exactly where it was.

When it all works you get something like this in your terminal:

$ pnpm agent
  DID    did:key:z6Mkv7Tsy...BVDeyw6Lwe
  repo   gitlawb://.../agent-e5eb73ec
  token  0xdED5B8B59089220081A14551E7F225757919CbA3   (Base)
  swap   https://basescan.org/tx/0x12f7...4890d
done. 5 steps complete.

The first time that ran clean I just sat there for a second. Four systems, a real token, a real transaction onchain, and not one key sitting somewhere I had to lose sleep over.

Where the keys actually live

When you set the thing up the first time, your own 1Claw key provisions an agent identity, a vault, and a signing key. Any secret the agent needs later, like your Bankr API key, goes into the vault and gets wiped out of your env file. At runtime the agent grabs what it needs for the half second it needs it, uses it, and moves on. The two things most likely to get an agent drained, the Bankr key and the signing key, are just not in places the agent could spill them from.

Guardrails and LLM security

Keeping keys out of the agent is only half the problem. The other half is what happens when the agent talks to a model. Every LLM call is a surface for prompt injection, data exfiltration, and the kind of hallucination where the model helpfully echoes back a credential it saw three turns ago. So this agent does not talk to the model directly.

Every request and every response runs through Shroud, which sits inside a TEE (trusted execution environment). Shroud does a few things before anything reaches the model or comes back to the agent:

• Secret redaction — if any vault secret appears in the prompt (even base64-encoded or split across tokens), Shroud strips it before it hits the provider. The model never sees the raw value.
• Prompt injection scoring — every inbound message is scored for injection patterns. If it crosses the threshold, the request is blocked or flagged before it can manipulate the model.
• Response filtering — the model's output is scanned for leaked secrets, suspicious URLs, encoded payloads, and markdown-image exfil attempts before the agent sees it.

On the transaction side, the agent cannot just sign whatever it wants. Even though signing happens inside the enclave, every intent goes through guardrails first:

• Address allowlist — the agent can only send to addresses you have pre-approved. Anything else gets a 403.
• Per-transaction cap — a maximum value in ETH per single transaction. Even if the agent is compromised, the blast radius is bounded.
• Daily spend limit — a rolling 24-hour ceiling. Once it is hit, signing stops until the window resets.
• Chain allowlist — the agent can only transact on chains you have explicitly enabled. No surprise deploys to mainnet when you meant testnet.

The combination is what makes the thing feel safe to actually run. The keys never leave the hardware, the model never sees raw secrets, the responses are filtered for exfil, and even if somehow all of that fails, the guardrails cap how much damage a compromised agent can do in a day. Defense in depth, but for agents instead of servers.

Why this matters if you build agents

If you have ever wired up identity plus a git host plus a model plus a token launcher plus an onchain signer, you know it is a weekend of glue code followed by a permanent low hum of anxiety about where the secrets ended up. This collapses the glue into one command, and it takes the secret handling off your plate completely. It is MIT licensed and it is small, one file per step, so you can read the whole thing in a sitting and lift whatever parts you want.

And if you live in the Bankr world specifically, this is sort of the whole point. An agent that funds itself is a genuinely good idea. It also means putting a wallet in the hands of a model, which is exactly the thing that should make you a little nervous. This shows you can keep the good idea and lose the nervous part. The agent launches and swaps just fine, but it cannot be drained, because it never holds the thing that would let it be.

The honest part

Now the honest part, because I would rather you hear it from me than find it out the hard way. This is a reference build. It runs, and every step above happened on live infrastructure, but it is written to be read, not dropped into production tonight. The Uniswap pool parameters in the swap step are still placeholders. The slippage is wide open, which is fine for a demo and not fine for real money. The agent ends up with two identities right now, one from 1Claw and one from GitLawb, because GitLawb cannot import the HSM key yet, and that is on the list to fix. There is no CI for the full run, mostly because it needs live keys to do anything real. None of that is hidden. It is all in the readme.

But the shape of it is real, and the shape is the argument. The agent did capable things and held nothing dangerous. That is it. That is the whole pitch.

If you want to poke at it, it is here: github.com/1clawAI/1claw-gitlawb-bankr-agent. Clone it, read the five steps, try to break it, then tell me what I got wrong. Honestly that is more useful to me than a star.

The agent economy is going to keep handing these things the keys to everything. I would just like the keys to live somewhere the agent cannot lose them.