AI CEO Lab← All free guides
Agents ยท Safety

Set Up Your Agent So It Can't Hurt You

Its own email. A disposable wallet. Read only until it earns writes. Nothing tied to your personal accounts. The five rules I set before any agent touches my business, and the prompt that audits yours.

Agents are exciting right up until one does something you did not ask for. Sends the email. Changes the ad budget. Deletes the contact. It will not be malicious. It will be confidently wrong at 2am.

So before I give any agent a job, I decide what it can see, what it can propose, and what it can change. Permission to analyze is not permission to act. That distinction is the whole security model.

Here is the honest version. I learned each of these rules after something went sideways. A tool that could write to my CRM because it was easier than building the read-only path. A card on file that an automation could charge. A browser profile that was mine, logged into everything, handed to a bot.

None of it required a hacker. It required me being lazy once. These five rules make the lazy path the safe path.

Drawn from how my own agents are provisioned, the read-only-by-default model my team uses for internal API tools, and one incident I will not describe in public. The permissions ladder came from a client call in September 2026.

The three levels

Level 1 · Manual

The agent runs in your browser, on your Google account, with your card, and can write to everything. It works until it doesn't.

Level 2 · AI + connections

Its own email and browser profile, a capped virtual card, read-only access by default, and an approval gate for anything that sends, spends or changes a record.

Level 3 · Agents on cadence

Every write is logged with who approved it. Secrets live in a store the agent reads by name, never in a chat. A kill switch a human can flip. You can take a week off and nothing it touches can cost you more than the cap.

Connections for this guide: A separate email account for the agent, a virtual card with a hard limit (Privacy.com or your bank's virtual cards), a separate browser profile or its own machine, a secrets store or env file it reads by name, and one channel where every action it takes is logged.

The mental model

Wrong

Give it access and tell it to be careful.

Right

Give it an identity that is not yours, money it cannot exceed, read access only, and a gate before anything changes.

RoleTalks to youJob
ReadDefaultApproved data only, can summarize and propose
ProposeAfter it is usefulDrafts sends, budgets, records; nothing leaves
ApproveYouAn exact yes on the exact action
ExecuteExplicitly permitted actions onlyLogged, capped, revocable

The five rules, in order

1. Give it its own email address

Not an alias on your Gmail. A separate account, ideally on a separate domain or workspace user. Every tool it signs into, every OAuth grant, every notification goes there. If it is compromised you close one account, not your life. It also means you can read every message it receives.

2. Give it a disposable wallet

A virtual card with a hard monthly cap and a per-transaction limit, funded from an account that holds only that cap. Never your main card on file anywhere the agent can reach. When a subscription needs a card, it is this one. If a bot decides to buy five hundred credits, it hits the cap and stops.

3. Read only first

Every integration starts as read. My team's internal tools block every non-read request unless a human sets an explicit flag for that run. The agent can pull the ad account, the CRM, the calendar, and tell you what it would do. It cannot do it. You will be surprised how much value lives at this level, and how many bugs you catch before they cost anything.

4. Nothing tied to anything personal

Its own browser profile or its own machine. Never your logged-in Chrome. Never your Apple ID, your personal phone number, your bank login, your health records, your photos. If a task needs something personal, the task is wrong, not the rule.

5. An approval gate for every live write

Sends, publishes, spends, and record changes need an exact yes on the exact action. Not "go ahead". "Yes, send that email to that list." Drafts are free. Everything else waits. The gate is code or a human, never a sentence in the prompt, because prompt rules fail silently.

Then: secrets by name, a log, a kill switch

Keys live in an env file or a secrets manager and the agent references them by name; a key pasted into a chat is a key you have to rotate. Every action posts to one channel with what, when, and who approved. One field or one command a human can flip to stop it mid-task.

Earning writes

Each phase has a done-when. If you have not hit it, do not start the next one. Every failure I have seen came from skipping ahead.

Week 1

Identity and money

  • Separate email account and browser profile
  • Virtual card with a cap, nothing else on file
  • Move every key into a store the agent reads by name
Done when: You could hand the whole setup to a stranger and they could not reach your bank, your inbox or your phone.
Weeks 2 to 3

Read and propose

  • Every integration connected read-only
  • Daily brief of what it sees and what it would change
  • A log channel with every action
Done when: It has proposed ten changes and you agreed with most of them, and it has executed none.
Week 4

Earn one write

  • One narrow action, explicitly permitted, capped, logged
  • Approval gate tested with a wrong yes
  • Revocation tested: flip the kill switch mid-task
Done when: One write, one log line, one human who said yes to exactly that.

Operating principles

  1. Permission to analyze is not permission to act.
  2. Its identity is not yours. Own email, own profile, own machine.
  3. It cannot spend past the cap, because the cap is at the bank, not in the prompt.
  4. Read first. Propose second. Write last, and narrowly.
  5. An exact yes on an exact action. "Go ahead" is not consent.
  6. Gates are code or a human, never a line in the prompt.
  7. Secrets by name, never by value. A pasted key is a rotated key.
  8. Log everything it does, in a place you read.
  9. A kill switch exists before the first task.
  10. Read-only access still exposes data. Treat what it can see as leaked to the model vendor.

Starter prompts

Paste these as written. They are short on purpose, because the long ones drift.

The prompt: audit my setup

Act as a security reviewer for my AI agent setup. I will describe how my agent is provisioned. Check it against five rules and for each give me a pass or fail, the specific risk if it fails, and the first fix: (1) Does the agent have its own email account and browser profile, separate from mine? (2) Does it have its own capped virtual card, with no other payment method reachable? (3) Is every integration read-only by default, with writes requiring an explicit human flag per run? (4) Is it tied to anything personal: my Apple ID, phone number, bank, health data, photos, main Gmail? (5) Is there an approval gate, in code or a human, before any send, publish, spend or record change, and a log of every action? Then give me a permissions matrix for one workflow with four rows: read, propose, approve, execute, and tell me which rows it should have today. Here is my setup: [describe it].

The identity setup prompt

Give me a checklist to provision a new AI agent with its own identity: email account, browser profile, virtual card with a cap of [amount], a secrets file it reads by name, a log channel, and a kill switch field. For each item say what to create, where, and how to test that it is isolated from my personal accounts.

The write-permission prompt

I want to allow my agent one live action: [describe]. Define the exact condition it needs (the exact yes), the cap, what gets logged, how I revoke it, and what it must never do even with permission.

Failure modes

Every one of these has happened to me or to someone I set this up for.

FailureFix
Agent runs in your logged-in ChromeOwn profile or own machine; nothing personal in reach
Main card on file in a tool the agent usesCapped virtual card, nothing else
"Be careful" in the system prompt as the only guardrailGate in code or a human; prompts fail silently
API key pasted into a chat to get it workingRotate it; store by name
Write access granted because read-only was more workRead-only path built first; writes earned one at a time
No log, so nobody knows what it did overnightOne channel, every action
"Go ahead" treated as approvalExact yes on the exact action

The free skill

It carries the five rules, the read-propose-approve-execute permission ladder, the audit checklist, and the revocation steps. Point it at your current setup and it tells you where you are exposed and what to change first.

How to use it: copy the whole thing, paste it into your bot (or save it as a skill file if you use Claude Code), and say “audit my agent setup”. It walks you through the rest. Works with any agent that can read your files.
agent-guardrails.md
---
name: agent-guardrails
description: Audits and provisions an AI agent so it cannot hurt its owner, own email and browser profile, a capped virtual card, read-only integrations by default, nothing tied to personal accounts, an approval gate before any live write, secrets by name, a log and a kill switch. Trigger on "audit my agent setup", "is my agent safe", "give my agent access to", "set up a new agent safely".
---

# Agent Guardrails

Permission to analyze is not permission to act. Decide what the agent can see, propose and
change before it does anything.

## The five rules, in order
1. **Its own email address.** A separate account, not an alias. Every sign-in, OAuth
   grant and notification goes there. Compromise closes one account.
2. **A disposable wallet.** A virtual card with a hard monthly cap and a per-transaction
   limit, funded from an account that holds only the cap. Nothing else on file anywhere the
   agent can reach.
3. **Read only first.** Every integration starts as read. Writes require an explicit
   human flag per run. The agent can pull data and say what it would do; it cannot do it.
4. **Nothing personal.** Its own browser profile or machine. Never a logged-in personal
   Chrome, Apple ID, phone number, bank, health records or photos. If a task needs
   something personal, the task is wrong.
5. **An approval gate for every live write.** Sends, publishes, spends and record
   changes need an exact yes on the exact action. Gates are code or a human, never a line
   in the prompt.

Then: secrets by name in an env file or store (a pasted key is a rotated key), one channel
logging every action with who approved it, and a kill switch a human can flip mid-task.

## The permission ladder
| Level | Can | Cannot |
| --- | --- | --- |
| Read | approved data, summaries, proposals | change anything |
| Propose | drafts of sends, budgets, records | send them |
| Approve | a human gives an exact yes | anything not named |
| Execute | the one permitted action, capped, logged | anything else |

Start every agent at Read. Earn one write at a time after weeks of good proposals.

## Audit checklist
- [ ] Separate email account and browser profile or machine
- [ ] Virtual card with cap; no other payment method reachable
- [ ] Every integration read-only unless flagged per run
- [ ] No personal accounts, devices or data in reach
- [ ] Approval gate in code or human before any send, publish, spend, record change
- [ ] Secrets in a store, referenced by name; none in chat history
- [ ] Log channel with every action and its approver
- [ ] Kill switch tested once
- [ ] What it can read is treated as visible to the model vendor

## Earning a write
Define the exact condition (the exact yes), the cap, what is logged, how it is revoked,
and what it must never do even with permission. Test the gate with a wrong yes. Test
revocation mid-task.

What done looks like at thirty days

Want the guardrails built into your agent from day one?

Every agent we set up inside the AI CEO Lab starts read-only with its own identity. The 3 Day AI Bootcamp walks the setup with these rules built in.

Pick a side.

Most people read this and forget it by Friday.

The other kind builds the thing that week. They stop needing free guides, because they are too busy running actual systems.

Free guides stay free. The room is where the builds happen.