Let an AI agent help — without handing over your stuff.
AI agents can read your email, your files, and do things for you. That is useful — and risky, because an agent can be tricked by a message it reads. Here is how to stay in control. Takes about 15 minutes.
First, watch it go wrong
You connect an agent to your inbox to help you keep up with email. Then a stranger sends you a message with a hidden instruction inside. The agent reads it — and can’t tell your wishes from the stranger’s.
Ask 3 questions before you connect anything
The screen where most people slip
When you connect an agent, it asks for permission. Most people click “Allow” without reading. Read it. Give the smallest option that still does the job.
- Read all your emailthis is enough
- Send email as youmore than you need
- Delete your emailmore than you need
See “send” and “delete”? You only asked it to read. Pick the smallest option, or say no.
The one habit that matters most
Give it the least it needs — usually "read only" — and make it ask you before it sends, deletes, or pays.
Know the un-do button
If it ever acts weird: open your account's "connected apps," remove the agent, and change your password. That is the un-do button. Find it before you need it.
Let your assistant check it for you
Rather than check all this by hand, paste this into the AI agent you are about to use. It looks over your setup and tells you, in plain words, what to fix. It only looks. It does not change anything.
You are auditing the safety of your own current setup before I trust you with a new agent or more access. This is READ-ONLY. Do not change, create, delete, send, install, revoke, or rotate anything. Do not run commands that mutate state. If a check would require an action, describe the action for me instead of taking it. First, orient yourself: - Identify which assistant/tool you are and where your own configuration lives (MCP servers and their scopes, permission/auto-approve settings, sandbox or isolation state, and the contents of the working directory you can read). Section A — Vet the thing I am adding (only if I name one below). If I name an agent, MCP server, package, or install command, assess: - Who maintains it, how recently it was updated, and how widely it is used. - Exactly what permissions or scopes it requests. - How it installs (flag anything that pipes a remote script straight into a shell, e.g. curl | bash). - Whether it publishes a security policy. Thing I am adding: <leave blank, or paste a repo URL / package / MCP server / install command here> Section B — Audit the environment you will run in. Check and report on: - Secrets in reach: any .env files, credentials, tokens, or SSH keys in a directory you can read. - Scope: any access or connected services broader than the task needs. - Autonomy: whether auto-approve / "always allow" / YOLO mode is on for actions that send, delete, pay, or post. - Limits: whether activity logging is on and whether any spend/token/rate cap exists. - Surprises: any connected apps, MCP servers, or forwarding/automation rules you did not expect. Output: 1. A findings table. Columns: finding, layer (L0 vet / L1 isolate / L2 scope / L3 gate / L4 watch / L5 recover), severity (high/med/low). 2. A punch list of concrete actions for ME to do by hand, most important first. Stay read-only. When you are done, tell me: "Audit complete. Reply 'propose fixes' and I will draft the exact changes without running them, or 'remediate' and I will apply them one at a time, confirming each before I act."
None of this makes you bulletproof. It shrinks the damage when something slips. That is the goal — not "perfectly safe."
Want the technical version? · New to all this? Join the cohort.