Building a Bank That Doesn't Exist

Most of my career has been spent showing up after something went wrong and working out what happened. Lately the “something” increasingly involves an AI agent: a tool with credentials, a prompt, and a job to do. Some of those jobs are ours. Some aren’t.

I wanted to know what it’s actually like to run a platform where agents do most of the work and humans steer, not from reading vendor blogs but from building one, breaking it, and investigating it with my own tools. So I started a lab on AWS, and gave it a customer: Bank of Glass.

Bank of Glass is not a real bank. It holds fake money, has synthetic customers, and offers no financial services.

Why a bank?

Because a bank makes every platform problem real at once. Money has to add up. Fraud has to be caught. Some data can’t leave certain boundaries. Uptime matters. And when something goes wrong, somebody is going to ask you to prove what happened.

A to-do app would have been easier. It would also have let me skip every interesting decision.

The bank also gives the security team something to do. Its tooling is a DFIR evidence pipeline, and the investigation side runs on the same tools I’ve been publishing here: Recap for timelines, Spoke for relationships, Huddle for playbooks.

The ground rules

Before anything existed, I wrote down how it would work:

  • Everything is code. Nothing reaches an AWS account except through a merged pull request.
  • Agents propose, humans approve. Agents open pull requests and issues. They never apply changes, move money, or approve their own work.
  • Autonomy scales with blast radius. Low-risk, reversible changes in the sandbox can merge themselves once every check passes. Production, identity and data-boundary changes always need a person.
  • Everything is logged. Every agent run (prompt, tool calls, output) and every apply lands in a store nobody can delete from.
  • There is a kill switch. One switch stops every agent.
  • Under $25 a month, and I should know exactly what drives the cost.

The last rule shapes more than you’d think: one region, serverless where possible, and small.

Day one is mostly saying no

The first few days weren’t about agents at all. They were about the boring foundation an agent would eventually stand on, and a surprising amount of it was turning down helpful defaults.

AWS’s new simplified sign-up. My first account landed in a streamlined experience where AWS manages the Organization and guardrails for you. That’s lovely if you want to build an app. It’s the opposite of what a platform team needs: you have to own your guardrails. Converting it later is irreversible, so I started over with the “advanced” sign-up and built the Organization myself.

The offer to wire my AI tools into my admin session. While setting up the CLI, I was offered a one-click hookup of AWS’s AI skills and MCP server to my coding tools. That would hand them my full admin session on the management account. No thanks. Agents get their own narrowly scoped roles, and that rule has held every time it came up since, including when a DNS provider wanted account-wide OAuth for its agent setup.

A zero quota that looked like a permissions error. Bedrock told me a newer Claude model was “not available for this account.” It wasn’t a permissions problem at all: new accounts start some models at a quota of zero tokens per minute, and a zero quota surfaces as an access error. I’m filing that one away for the next time someone tells me an error message means what it says.

One region, on purpose. Everything runs in us-east-1, and every other region is denied by policy. It’s simple and it’s where CloudFront certificates have to live anyway. The trade-off is us-east-1’s outage history, and I wrote that down as an accepted risk rather than pretending it isn’t there.

Then came the parts that make it a platform: four accounts (management, security, sandbox, prod-demo), an organization-wide CloudTrail written to an Object Lock bucket in the security account, GuardDuty, Config, budgets and anomaly alerts, and a CI pipeline where pull requests only ever get a read-only role and applies happen after merge.

The audit stack is applied by hand, never by the pipeline it audits. If the pipeline goes wrong, I don’t want it able to edit the record of itself going wrong.

Keeping a journal

Every session ends with an entry: what I did, what I decided and why, what broke, what it cost, and the exact next step. That last line is what makes this a pick-up-and-put-down project instead of one I abandon the first busy week.

It’s also turned out to be the most useful part. When something surprises me, the surprise goes in the journal before the fix does.

Where it’s going

The foundation is the point, but it’s not the interesting part. What I actually want is a place to study what agents leave behind.

When an agent does something, what evidence exists? Can I reconstruct every run, every tool call, and who approved what, the way I’d reconstruct an intruder’s session? What happens when someone plants instructions in a log the agent is going to read? (Spoiler: the first lesson wasn’t about the model at all. It was about what the model wasn’t shown. That’s its own post.)

Since this was written, the lab has grown agents, a drift detector that opens its own import PRs, a ledger, and a sign-in page. I’ll write those up as they settle. For now, the bank is open, the money is fake, and the logs are very, very real.