Walid Boulanouar recently shared something that caught my attention: "people are installing molbot like a cute personal assistant. then giving it their real email. and a real computer. that combo is how you get erased." That framing is blunt, but it lands because it captures a new reality of AI agents.

We are not just chatting with a model anymore. We are increasingly giving software the ability to read email, click buttons, download files, and authenticate into services. As Walid put it, "once an agent can read your inbox… password resets become a feature, not a threat model." If that does not change how you think about setup and security, you are one incident away from learning it the hard way.

In this post, I want to expand on Walid's mental model and turn it into a practical, founder-friendly checklist you can actually apply.

The core mental model: any agent that can click is an employee

Walid's simplest line is also the most useful:

"any agent that can click is an employee."

If an agent can take actions (browser automation, email access, GitHub access, Stripe, cloud console, internal admin panels), treat it like a human hire from a risk perspective. That means:

It needs an identity (accounts) separate from yours.
It needs a device or environment you can isolate.
It needs role-based access, not "whatever makes it work" permissions.
It needs logging and oversight.

Most teams do the opposite. They prototype fast by handing the agent their primary email and a browser profile full of saved passwords, then they paste in long-lived API keys until the demo works. That is convenience now, chaos later.

Why inbox access is a security multiplier

Email is the skeleton key for most startups and personal stacks. If an agent can read your inbox, it can often:

Trigger password resets for SaaS tools
Confirm reset links and 2FA prompts
Find invoices, contracts, and customer data
See one-time codes, magic links, and invites

Even without "malice," agents can be tricked. Prompt injection is real in the messy, web-connected world: an email, a support doc, or a webpage can contain instructions that override your intent. If the agent has broad permissions, the blast radius is whatever it can reach.

Walid connected this to recent reports of token leakage: if a platform leaks tokens (or logs them in the wrong place), you can go from "vibe coding" to "vibe incident response" instantly. The point is not to pick on one tool. The point is that the ecosystem is moving faster than its security defaults.

Threat modeling an agent like a junior employee (who never sleeps)

If you would not give a junior contractor full access to your personal accounts, do not give it to an agent.

Here is a quick way to think about risk:

1) Capability risk: what can it do?

Read email and files
Browse and click
Run shell commands
Access cloud resources

The more action-oriented the agent, the closer it is to "operator" access.

2) Credential risk: what secrets can it see?

Password manager vaults
Browser-saved passwords
API keys in env vars
Tokens in localStorage/cookies

Secrets tend to be present even when you did not explicitly provide them.

3) Exfiltration risk: how can data leave?

Walid called out the boring but critical paths:

"assume screenshots + clipboard + downloads are 'data exfil paths'"

Add uploads, email sends, webhook calls, and pasted content into chats. If an agent can take a screenshot, it can capture anything you can view. If it can access the clipboard, it can copy secrets you never intended to share.

4) Destruction risk: what is the default failure mode?

Another Walid line that hits hard:

"assume 'deleting files' is the default failure mode"

Automation fails in surprising ways. Agents can mis-click, interpret instructions loosely, or retry aggressively. Without guardrails, "clean up" can become "wipe." Your safety net is backups plus permissions that prevent catastrophic actions.

A safer setup checklist (expanded)

Walid listed a "quick setup that saves you later." I agree, and I would expand each item with practical details.

1) Create a separate email for the agent

Use an email like agent-ops@yourdomain.com, not your founder inbox.

Disable forwarding to your main inbox.
Turn on 2FA, but store recovery codes securely.
Use it only for the services the agent needs.

If an incident happens, you can contain it by disabling one account instead of detonating your entire identity.

2) Use a fresh browser profile with zero saved passwords

A dedicated profile prevents accidental access to:

Your password manager extension
Existing sessions in Gmail, AWS, Stripe, GitHub
Auto-filled addresses and payment methods

If the agent needs access, grant it deliberately via the agent identity, not via your browsing history.

3) Run it in a VM or on a dedicated cheap laptop

Isolation is underrated. A VM (or separate machine) gives you:

A clean environment you can reset
Fewer cross-contamination paths (cookies, files, SSH keys)
Better control over what is installed

If possible, keep that environment off your personal iCloud/Google sync.

4) Use least-privilege API keys and short-lived tokens

This is where most "it was only a prototype" incidents come from.

Prefer OAuth scopes over raw keys where possible.
Create role-based API keys that can only read what is needed.
Use expiring tokens and rotate regularly.
Separate dev, staging, and prod credentials.

If you must use a powerful key temporarily, time-box it and revoke it after the test.

5) Treat screenshots, clipboard, and downloads as exfil paths

Assume anything the agent can see can leave.

Practical moves:

Disable clipboard sharing between VM and host.
Restrict downloads and uploads if your tooling allows.
Do not open sensitive docs in the agent environment.
Watermark or redact sensitive data in test environments.

6) Never give it your primary API keys or full personal info

This includes:

Your personal email, calendars, and contacts
Root cloud credentials
Payment and banking access
Production database admin tokens

Give agents the minimum they need to complete the task, not the minimum you need to feel less annoyed.

7) Assume deletion and irreversible actions will happen

Put guardrails in place:

Use read-only permissions by default
Add approval steps for destructive actions
Implement "dry run" modes
Keep a recycle bin or versioning where possible (S3 versioning, Git protections)

8) Back up everything daily

Backups are not a nice-to-have when automation touches real systems.

Automate backups
Test restores (a backup you cannot restore is theater)
Keep at least one offline or separate-account copy

What to do if you already gave an agent too much access

Walid's advice is simple: "go check what you already gave your agent. main email? rotate everything." Here is an actionable sequence:

Revoke active sessions: log out everywhere for the agent accounts and your accounts.
Rotate credentials: API keys, OAuth tokens, refresh tokens, webhook secrets.
Change passwords for any account the agent could access.
Review email rules and OAuth app grants in Google Workspace or Microsoft 365.
Check logs: sign-in history, unusual IPs, new devices.
Reduce permissions: rebuild with least privilege.

If you are unsure, treat it like a real incident and document what you do. Future you will thank you.

The bigger point: hype does not reduce blast radius

Walid also nailed the cultural trap:

"communities forming around these tools is cool. but shared hype does not reduce your blast radius"

Agentic tools are exciting because they compress work. But they also compress failure. A single misconfiguration can turn a productivity experiment into a security event, especially when email and browsers are involved.

My takeaway is the same as Walid's: treat agents like employees. Give them separate identities, separate environments, and scoped permissions. If something goes wrong, you want a small, containable problem, not an existential one.

This blog post expands on a viral LinkedIn post by Walid Boulanouar, building more agents than you can count | aiCTO ay automate & humanoidz | building with n8n, a2a, cursor & ☕ | advisor | first ai agents talent recruiter. View the original LinkedIn post →