AI Agent Security Checklist: What to Read Before You Run One You Did Not Write

Tomorrow morning I am making a repo public that contains eight AI employees. Some of the people who clone it will run it against their real business inside an hour. A few of them will run a dependency scan first, get a clean result, and treat that as the audit.

It is not the audit. For this kind of repo it barely touches the audit.

An agent repo is not a library you call. It is a set of instructions that a model reads and then acts on, using your accounts, your keys, your logged-in browser and your money. The dangerous part usually is not hidden in a package somewhere. It is written in plain English in a file you skipped, because it looked like documentation.

So here is the security checklist I actually run before an agent I did not write touches anything I care about. It takes about an hour. I have used it on other people's repos and on my own, and I am going to point it at my own repo tomorrow on a live call so you can watch the whole thing rather than take my word for it.

Why vetting an AI agent is not a normal dependency audit

A charting library does one thing and does it when you call it. An agent decides what to do next while it is running, and it decides using text it read a moment ago. That difference breaks most of the habits you already have.

Three properties make the usual audit incomplete.

It acts without being called. Once a routine is scheduled, nobody is in the room. The failure you care about is not a crash. It is a confident, completed action you did not want.

Its permissions are inherited, not declared. A package asks for nothing. An agent runs as you. It can reach every account already signed in on that machine, every key in your environment, and every repo you can push to. Nothing in the repo has to request that. It just arrives with the harness.

Its behaviour comes from prose. The instruction files are the program. A model reading "publish the post when it is ready" will decide for itself what ready means. You are auditing English, and English is fuzzier than a function signature.

The Open Worldwide Application Security Project keeps a good working reference on this class of problem in its AI agent security cheat sheet, and it is worth reading once for the vocabulary. But almost everything written about agent security right now is written for a security team with an identity platform and a budget. If you are one person with one laptop, one browser and a card on file, you need a shorter list you will actually run.

Two kinds of agent repo, two different audits

Before you read anything, work out which kind of repo you cloned. The check changes completely.

A code-shaped agent is a framework. It has a dependency manifest, an install step, a runtime, and usually a server. Here the standard software supply chain audit applies and you should run it: count the direct dependencies, look at anything that executes on install, search the source for hardcoded endpoints and anything that writes a key to a log, and find the tool definitions so you know what the thing is allowed to call. A shell tool with no allowlist is the single highest-risk item in any of these repos.

An instruction-shaped agent is the newer pattern, and it is what most AI employee repos are now. No install step, no runtime of its own, often no dependencies at all. It is a folder of markdown files that a harness you already trust reads and executes. A dependency scanner returns nothing for it, which reads as a clean bill of health and is actually just a scanner finding nothing to scan.

That is the trap. The scariest instruction-shaped repo I have read had zero dependencies and a routine that emailed a customer list on a schedule.

Most repos are one or the other. A few are both, and then you run both passes.

The AI agent security checklist: eight things to read before the first run

Read these in this order. The order matters, because the first two will end the audit early more often than the rest.

1. Does it have a license, and does that license let you do what you plan to do?

No license file means default copyright, which means you have no permission to use it, however public the repo is. GitHub's own guidance on licensing a repository says this plainly and people still skip it.

Then read the license rather than the badge. Plenty of projects call themselves open source and ship a custom license that forbids exactly what you were planning: reselling, running it for clients, or offering it as a service. If you intend to bill someone for work this agent does, that clause is the whole decision.

2. What accounts does it want, and what is the smallest set that still works?

Find every credential the repo asks for. Then ask a harder question about each one: does this need write access, or did the author just use an admin key because it was easier?

Most agent repos ask for more than the job needs. Not maliciously. It is just faster to write instructions against a key that can do everything. You are the one who pays for that when a routine does something surprising at three in the morning.

3. What can it write, send, publish or delete?

This is the single highest-value pass in the list, and almost nobody does it. Search the instruction files for the action verbs: post, send, publish, delete, merge, push, buy, charge, email, submit, approve.

Every hit is a place where a run turns into something the world can see. Read each one and decide, before the first run, whether you want that action to happen unattended at all. I wrote more about where that line belongs in what to gate and what to let run unattended, because the answer is usually not all or nothing.

4. What happens on a schedule, and what does it do the first time it fires?

A scheduled routine is a different risk from a routine you invoke. You will not be watching, and the first firing often happens before you have finished reading.

Find the schedule. Find what the first run does. If the repo installs its schedules as part of setup, that is worth knowing before you run setup, not after.

5. Where does data leave the machine?

Every address in the repo that is not documentation is a place your data can go. Webhooks, third-party interfaces, analytics, an author's own endpoint for usage stats.

Most of these are honest. Some of them will still send your business's content somewhere you would not have chosen. Read the list and make the choice yourself.

6. What does it read from the open internet?

If an agent reads web pages, emails, issues or comments, then hostile text inside that content can try to give it new instructions. This is the injection problem, and it is real but frequently overstated in ways that are not useful.

The practical version: an agent that only reads pages and writes you a summary can be lied to, which costs you a bad summary. An agent that reads pages and then has permission to send, publish or pay is where a lie becomes expensive. Cross-reference this check against check three. The overlap is your actual exposure.

7. What stops it?

Find out what the repo does when something fails. A routine that retries a failed send is a routine that will eventually send the same thing five times. A routine that swallows errors and reports success is worse than one that crashes, because you will trust a report that is not true.

You want to see failures that stop the run and say so. If the repo has no story for this at all, you are the story.

8. Can you read the whole thing in an hour?

If you cannot, that is not a scheduling problem. That is the finding.

An agent you cannot read is an agent you cannot supervise, and you are about to hand it your accounts. Volume is a security property. This is most of why I think an AI employee should be a small set of files you can read in an afternoon rather than a platform you log into, which I argued in more detail in why open source AI employees should be files you can read.

What a clean scan will not tell you

Run the scanners. They are cheap and they catch the loud problems. Just be clear about what a clean result means.

It means no known-vulnerable package version, and no dependency doing something obviously hostile on install. It says nothing about whether the routine posts to the right destination, emails the right list, charges the right card, or deletes the wrong folder. Those are all correct-looking operations on well-formed data. Nothing flags them.

The honest summary: tooling catches malicious code, and reading catches wrong instructions. Almost every incident a solo operator will actually have is the second kind.

This is also why the employees I hand to club members ship as files rather than as a hosted thing you connect an account to. You cannot audit what you cannot read, and I would rather you read mine before you trust them.

How to survive the first run

The read gets you most of the way. The rest you only learn by running it, so run it in a way that cannot hurt you.

Give it one account, not all of them. Whatever the setup instructions say, start with the narrowest credential that lets one routine complete. Add the rest when you have seen it behave.

Stage the last click. For anything that posts, sends or publishes, make the first runs stop one step short and leave the action for you. You find out what it would have done without finding out the hard way. This matters most when the agent is driving accounts you are already signed in to, which has its own set of rules I have written up separately in seven rules for an agent in your logged-in browser.

Do not install the schedule on day one. Invoke it by hand until you have watched a full run end to end. The scheduler is the thing that turns a mistake into a recurring mistake.

Watch the first run live, then read what it wrote. Not the summary it gives you. The actual file, the actual draft, the actual commit. The gap between what an agent reports and what it did is where every bad surprise lives, and you only calibrate that by checking a few times early.

Keep the first day reversible. Nothing that deletes, nothing that mails a list, nothing public. If a routine cannot run in a reversible mode, that is a design answer about how much you should trust it.

The failure that actually happens is scope, not malice

I have read a lot of agent repos this year, and I have yet to find one that was trying to hurt me. What I find constantly are routines that are perfectly correct for the business they were written in and wrong for mine.

An instruction that says to post to the community assumes one community. A routine that cleans up old drafts assumes your idea of old. A step that pushes to the main branch assumes your repo deploys the way the author's did. Every one of those runs cleanly, reports success, and does something you did not want.

That is why the checklist above is mostly about scope rather than malware. You are not hunting for a villain. You are working out which assumptions in someone else's business do not hold in yours, before a scheduler makes those assumptions eight hundred times.

Watch me audit my own repo tomorrow

Saturday, September 19 at 10:00 AM Eastern I am making the eight AI employees I run my own business with public, live on the call, and walking through what is inside them. It is free, and you can save a seat for Open Source AI Employees.

I am going to run this exact checklist against my own repo on screen, including the parts that do not flatter it: which routines can write, which ones are scheduled, which ones touch accounts, and where each one stops and asks. If you are going to clone something of mine and point it at your business, you should see me point the audit at it first.

If you want the background first, the replay of Hire Your First AI Employee covers the onboarding side: what an agent needs to know about your business before any of this matters.

Get the setup instead of assembling it yourself

If you would rather start from something already wired up than vet a stranger's repo at all, that is what the Agent Ops Club is for. Members get the eight AI employees, the Agent Ops Masterclass, and a software library with a licence you can deploy for clients. There is a free plan, so you can read everything before you decide whether the paid side is worth it.

One small ask either way: run the checklist on something this week, even a repo you already trust. The first time you search your own agent for the word send is educational.

Frequently asked questions

Is it safe to run an open source AI agent?

It is as safe as the permissions you hand it, which is a different question from whether the code is honest. Assume the author was well-intentioned and still audit for scope: what it can write, what it sends, what runs on a schedule, and what stops it. Most real incidents are a correct routine running against the wrong account, not malicious code.

Do I need a virtual machine to try an AI agent?

For a code-shaped agent with an install step and dependencies, yes, an isolated environment with no credentials is the right first move. For an instruction-shaped agent that just reads files, a container adds less than people think, because the risk is the accounts you connect rather than the code that executes. Narrow credentials and a staged first run buy you more safety there than isolation does.

What is the most dangerous permission to give an AI agent?

Anything that sends to other people. Publishing, emailing a list, messaging, charging a card. Those actions are irreversible and public in a way that a bad file edit is not. Unrestricted shell access is the close second, because it converts into all of the above.

How long should vetting an agent repo take?

About an hour for a repo of readable size, which is also the test. If a full read is going to take you a week, you are not going to supervise it either, and that fact is more useful than anything you would have found in the read.

Can a web page hijack an AI agent that reads it?

It can try, and sometimes it works. The way to make it survivable is not to stop the agent reading the internet. It is to make sure the agent that reads the internet is not the same agent holding permission to send, publish or pay without you.

How do I check the license on an agent repo?

Open the license file itself rather than trusting the label on the repo page. Confirm it names a licence you recognise, and read any added clauses about resale, client work or offering the tool as a service. If there is no license file, you have no permission to use the code at all, whatever the repo's visibility.