AI CEO LabAI Agent Guardrails: Set Up An Agent That 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.
The three levels
The agent runs in your browser, on your Google account, with your card, and can write to everything. It works until it doesn't.
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.
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.
The mental model
Give it access and tell it to be careful.
Give it an identity that is not yours, money it cannot exceed, read access only, and a gate before anything changes.
| Role | Talks to you | Job |
|---|---|---|
| Read | Default | Approved data only, can summarize and propose |
| Propose | After it is useful | Drafts sends, budgets, records; nothing leaves |
| Approve | You | An exact yes on the exact action |
| Execute | Explicitly permitted actions only | Logged, 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.
Starter prompts
Paste these as written. They are short on purpose, because the long ones drift.
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].
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.
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.
| Failure | Fix |
|---|---|
| Agent runs in your logged-in Chrome | Own profile or own machine; nothing personal in reach |
| Main card on file in a tool the agent uses | Capped virtual card, nothing else |
| "Be careful" in the system prompt as the only guardrail | Gate in code or a human; prompts fail silently |
| API key pasted into a chat to get it working | Rotate it; store by name |
| Write access granted because read-only was more work | Read-only path built first; writes earned one at a time |
| No log, so nobody knows what it did overnight | One channel, every action |
| "Go ahead" treated as approval | Exact 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.
--- 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
- The agent has its own email, profile and capped card
- Every integration is read-only unless a human flagged a specific run
- Every key lives in a store and none has been pasted into a chat
- Every action it took this month is in one channel with an approver
- The kill switch has been tested once
- It has exactly the writes it has earned, and no more
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.