Giving an AI agent a Google Cloud project without handing it the keys

0:00Cold open

This is the first evening of the build: one session, two phases, and an agent doing all of it. By the end of it there is a new cloud project inside its own box, an identity the agent borrows instead of owns, and a budget that stops the meter instead of sending an email. Along the way, the safest key in the whole system turns out to be the one that never gets created. Here is how it went, in the words I said while it was happening.

0:33A fresh profile, and the shell you pick

It starts on a fresh Windows profile with nothing installed, which is deliberate. The tools go on by the package manager, and the shell is PowerShell with the Git tools for Windows on top, not the Linux subsystem, because we want native file access and because plain PowerShell trips an agent on backticks, quotes, and slashes. The Git tools smooth those gaps, so we spend less time tripping over our shoelaces on command syntax. And then the first lesson, which cost twenty minutes: I signed in to Google Cloud from the ordinary Windows shell, and the agent, running in PowerShell, kept reporting no account. Credentials live in a context. You authenticate where the agent works. On a new profile you take one step forward and two back for a while. That is not failure. It is the investment that makes every later session fast.

1:31Why the command line, and where the agent stops

Next, why the agent works through the command line at all. The cloud's command-line tool is its interface in text: nearly everything you would click through in the console is a command, and an agent can issue a command far more reliably than it can drive a browser. So the browser is the fallback, connected through an extension in the agent's own Chrome, signed in as its own account, for the few things that only a page can show. And there is a line the agent will not cross. Rule one of its instructions says that anything touching the workspace admin console goes to a relay, and it stops. The relay is a directory on this machine, a queue between two agents: this one, on camera, drops a request; a second one, in a private profile that owns the shared business account, picks it up, does the privileged work, and drops the result back. The privileged identity and the working identity never share a screen.

2:39The keys, and the last four characters

The provider keys are the first real secret the build touches, and the rule is that a key only ever appears on screen as its last four characters. A checker script reads the key file, tries each provider, and prints a table: five seats, five keys, each one a green check and four characters. One key was missing that night, the voice key, and I chose not to go get it on camera. That is the rule in practice: the way you avoid exposing a secret is to never put yourself in the position of handling it while recording.

3:18The repository is the safety net

Before the project exists, the repository does. A private repository, created by the agent from the command line, with a secrets scanner installed as a pre-commit hook before the first commit. The hook fired on the first attempt and blocked it, a false positive on the word Secretary, which the agent marked and moved on. Seventy-six files, pushed. That repository is the safety net for every phase after it: if we make an oops, we roll back to a commit that is dated, timed, and described. I push at the end of every phase, and I let the agent write the commit messages, because it knows what it did, and it is the one that will search those messages later to find the way back. And a habit that goes with it: before I close any session, one last message. Update the documentation, the memories, push to the repository. It almost always finds something it had not saved.

4:23Phase one: the project in its box

Phase one is the project itself. It goes under a folder made for the show, on the agent's own billing account, which carries the three hundred dollar credit a new cloud account gets, a credit I wrote into the plan on purpose so the build would run on it rather than discover it later. One command creates the project. Nineteen services enabled in one call. The whole thing sits in a box that can be shut down, moved, or handed off without arms and legs reaching into anything else, and its bill is its own bill.

4:59The identity: borrowed, never owned

Then the part that matters most. The agent does not get a key. It gets a service account, and it gets permission to impersonate that account, which means every command it runs is signed with a short-lived token minted on the spot, never a file that can be copied. The first attempt at that failed with permission denied, and the agent unset its own configuration, checked the binding directly, found it correct, and retried: a propagation delay, not a mistake. Then the proof: impersonation okay, with no token ever printed. And behind it, a policy on the project that forbids creating service-account keys at all, enforced so that even an owner cannot make one. That is what least privilege looks like when it is built rather than promised. If a piece is compromised, what leaks is what that piece needed, not the whole project. The safest key is the one that never exists.

6:05The budget that stops the meter

With the identity in place, the wall around the money. Every project gets a budget, and I want to be careful about what a budget is: on its own, it sends mail. You have seen the stories, the cloud provider billed me ten thousand dollars over a weekend, and almost every one of them is a person whose budget only sent a notification. So the budget here publishes an alert to a message topic, a small service subscribes to it, and at one hundred percent that service detaches billing from the project. The proof was a synthetic alert at one hundred percent, with the service in dry run: the log said, would detach billing. Then the dry run was switched off, and it has been live since. A budget without an action is a notification. A budget with a stop is a circuit breaker.

6:58What a combed plan buys you

By the end of the evening the agent ran twenty minutes of work on its own, several items in a row, while I watched. That is not luck. It is the direct result of a plan that was reviewed, combed, and reviewed again before anything was built. When the planning is done well, implementation is mostly a waiting game. The plan was written in a large model that thinks well and executed in a middleweight one that works well, at a fraction of the cost, and each phase was sized to fit one context window so the agent never drifts from its instructions. Plan heavy in the big model. Execute in the cost-effective one. Not cheap. Cost-effective.

7:44The reach, read aloud

The phase ends the way every phase ends: the agent reads its own reach back to me. Editor on this one project and nothing else. No changes to identities, billing, or the organization. That reach was deliberately generous for a build, and it is deliberately narrowed later, once the system is running and we know exactly which rows each identity needs. That narrowing is its own story. For now: a project in a box, an identity that is borrowed, a key that was never made, and a budget that stops. Next, the project gets its domain.