How should a solo founder give an AI agent its own credentials safely?

How to Give an AI Agent Credentials Without Getting Burned

Give an AI agent its own scoped account, never your personal one, and design the blast radius before you design the workflow. The June 2026 wave of agent-gone-wrong incidents — Bunq, Fedora, the bankrupted DN42 scanner — all came from agents holding too much authority. Kahneman would call this a pre-mortem: ask what the worst plausible failure looks like before you grant the key.

In a two-week window this month, three separate stories taught the same lesson and almost nobody connected the dots. On 10 June a security firm showed that a single one-cent bank transfer could compromise Bunq's AI banking assistant. A day later, the Linux Weekly News covered an AI coding agent that ran amok inside the Fedora project's infrastructure. On 12 June, the front page of Hacker News carried the story of an AI agent that bankrupted its operator while trying to scan an obscure network called DN42 — a runaway cloud bill produced by an agent with billing credentials and no off-switch. Different agents, different domains, identical root cause: the agent was acting with credentials and authority that belonged to a human, on a blast radius nobody had drawn before turning it on.

If you are a solo founder, this is the moment to design before you grant. The instinct is to plug an agent into your personal account because it is fastest — your AWS, your Stripe, your email, your GitHub — and ask it to "go do the thing." That instinct is the same one Daniel Kahneman warns about in "Thinking, Fast and Slow": System 1 makes the decision before System 2 has run the pre-mortem. The pre-mortem is the cheap insurance. Five minutes of asking "what is the worst plausible outcome if this agent does exactly what I am about to authorise, but wrongly?" prevents most of the disasters in the news cycle.

The concrete pattern that has emerged this June, and that I now use as the default, is to give the agent its own account, not yours. Cloudflare shipped Temporary Accounts for AI Agents on 19 June precisely because this is the right shape: the agent runs a temporary wrangler deploy, gets a sandboxed Worker, and there is no path from that sandbox to your production billing. The same logic generalises. For Stripe, create a restricted API key scoped to the one action the agent needs, with a low daily volume limit, and tie it to a sub-account whose ceiling is the worst case you would tolerate losing. For GitHub, use a fine-grained personal access token, scoped to one repo, with no admin permissions. For AWS, use IAM roles with explicit deny rules on anything destructive and a billing alarm that triggers below your real pain threshold, not at it. The agent gets a key; the key opens one door; the room behind that door is small enough that a bad day is recoverable.

The harder part is the part you cannot solve with permissions. The Bunq exploit worked because the attacker crafted a message that looked like normal transaction metadata and the agent followed it as an instruction. This is the prompt-injection problem and it does not go away by tightening the API key. It goes away — partially — by treating any input the agent reads from the wider world as untrusted, the same way you would treat raw user input in a web form. Mollick, in "Co-Intelligence," frames the issue as the agent being "shockingly literal" about what it reads, and the practical implication is that any data path from the internet into the agent's context window is a route an attacker can use to issue commands. Filter, sanitise, or, where you cannot, simply do not let the agent take irreversible action on the basis of content it pulled in.

The third habit, and the one most under-used, is the kill switch. The DN42 founder did not lose money because the agent was malicious; they lost money because nothing told the agent to stop. Set a hard timeout. Set a hard spend cap. Wire a Slack or email notification on any state change above a threshold, and keep your phone on. None of this is glamorous, but Sir John Whitmore's coaching framework has a clean version of the point: before you delegate, agree on the goal, the reality, the options, and the way forward. Agents need the same conversation. "Do X, with these credentials, up to this limit, and ping me if anything looks like Y" is a vastly safer brief than "go do X."

None of this is an argument against using agents. I run several daily and the leverage is real. It is an argument for the boring discipline of designing the worst-case before you grant the keys, because the news cycle of June 2026 is going to repeat itself, and the founders who quietly skip that month are the ones who took five minutes to sketch the blast radius first.