AI agent security for one person: give it one project, not everything

AI agent security sounds like a topic for companies with a security team. It is not only that. The moment you let an agent work on your own projects, you are the security team. The good news is that for one person the rules are short, and most of them come down to one idea: give the agent the smallest amount of access that still lets it do the job.

The one principle: least access

Security people call it least privilege. In plain words, an agent should be able to reach what the work needs, and nothing else. Not because the agent is out to get you, but because agents make mistakes, misread instructions, and follow things they read along the way. When that happens, the question is not whether something went wrong. It is how far it could spread.

Small access means small mistakes. That is the whole trade. You give up a little convenience, and in return a bad afternoon stays a bad afternoon.

Scope it to one project

Start with where the agent works. If you keep your life in projects, as good personal project management suggests, you already have natural walls. The website is one project. The kitchen renovation is another. Your invoices are a third.

An agent that helps with the website should see the website tickets, and nothing about your renovation budget or your clients. If it needs to help with two projects, connect it to each one separately, on purpose, rather than giving it the whole account because that was quicker.

Its own access, revocable at once

Never let an agent sign in as you. Give it its own access, usually a token, that belongs to one agent and one project. Name it so you recognise it later, for example "Website agent".

• One per agent. If you use two agents, each gets its own. Then you can tell their work apart and cut one off without touching the other.
• Revocable in one step. If something looks wrong, you revoke it and the agent is out immediately. You do not have to change your own password or hunt through settings.
• Kept out of shared places. Treat it like a key. Do not paste it into public documents or messages.
• Cleaned up. When a project is finished or an agent is no longer used, revoke its access. Old keys are how forgotten doors stay open.

What an agent should never be able to do

Some limits matter more than others. For personal work, these are the ones worth insisting on:

• Erase the history. An agent may remove a ticket it filed twice by mistake. It should never be able to delete the conversation that explains what happened. The thread is your evidence.
• See unrelated projects. What it cannot see, it cannot leak, misuse or get confused by.
• Change the rules. Which statuses exist, which labels exist, who has access. Those are yours.
• Act as you towards other people. Sending email in your name, paying, accepting terms. If an agent needs to do any of that, it should ask first, every time.

A trail with names

Good AI agent security is not only about stopping things. It is also about being able to see what happened afterwards. Every comment and every status change should carry the name of whoever made it, human or agent.

That gives you two things. You can tell your own notes from the agent's at a glance. And when something is off, you can read the thread from the top and see exactly which step went wrong, instead of guessing from memory or scrolling through an old chat.

Review before anything goes live

The riskiest moment is when work leaves the project and reaches the world: a page is published, an email is sent, a change is released. Put a checkpoint there.

A simple way is to keep two statuses apart. Done means the agent finished and wrote what it did. Deployed means the change is confirmed live. You look at the result in between. The guide on human in the loop for AI agents goes through which decisions should always wait for you.

Be careful with what it reads

Agents read web pages, documents and messages as part of their work. Some of that text can contain instructions that were never meant for the agent, or were planted on purpose. You cannot fully prevent that. You can limit what an agent could do if it follows the wrong instruction, which brings you back to small access and a checkpoint before anything goes live.

When something goes wrong

1. Revoke first. Cut the agent's access to the project. Ask questions afterwards.
2. Read the thread. Start with the last things the agent did, then go back until the story makes sense.
3. Undo what you can. Reopen tickets, restore what was changed, tell anyone who was affected.
4. Fix the cause. Usually that is a vague ticket, a missing stop-and-ask rule, or access that was wider than needed.
5. Reconnect with a new token. Only when you are happy with the fix.

A checklist to keep

• One agent, one project, one token, with a name you recognise.
• No access to projects the agent does not work on.
• History that the agent cannot erase.
• A name on every change.
• Review between done and live.
• Revoke first, investigate second.

None of this needs an IT department. It needs a place where access is small by default. Very Simple Projects is a simple personal project management app built that way: you connect an agent to one project with its own revocable token or through a sign-in flow, it cannot see projects you did not give it (all of them is an option, and this guide is the case for not starting there), it can delete a ticket but never a comment, and every status change lands in the thread with its name. It costs $0.99 a month, and the first month is free.