# What a real skill security scan actually checks

_A plain-language look at exactly how we review an AI skill before listing it on AgentPod: what it touches, what it asks for, and where your data goes._

By Alex, Co-founder, AgentPod. June 23, 2026.

URL: https://agentpod.com/learn/what-a-skill-security-scan-checks

---

You found a skill that does exactly what you need. It promises to clean your inbox, or find subscriptions you forgot about, or turn your meeting notes into a to-do list. It looks great. And then a small voice in your head asks the only question that matters: but what is this thing actually going to touch?

I am Alex. I co-founded AgentPod, and a big part of what we do is read skills before we let them onto our shelf. Not skim them. Read them. So I want to pull back the curtain and show you what that review actually looks like, in plain words. No jargon, no mystery. Just the checklist a real person runs before a skill gets a green light.

That number is most people. Wanting a safety check before you trust a tool with your email and your money is not paranoia. It is common sense. So here is how we try to earn that trust, step by step.

## First: what it claims to do versus what it actually touches

Every skill comes with a description. "Finds your recurring charges." "Drafts replies in your voice." Lovely. The first thing we do is ignore the description and read the skill itself, then compare the two.

It is the same as checking a job applicant's resume against their references. The claim is one thing. What the work actually involves is another. A subscription finder should read your statements and nothing else. If we open it up and it also reaches for your contacts, the claim and the reality do not match, and we want to know why before anything goes further.

> **The core check.** We line up what a skill says it does next to what it actually touches. When those two things do not match, that is the first and biggest flag.

## Second: does it ask for more access than the job needs?

There is a simple rule in security called least access. A tool should only get the keys it needs to do its one job, and not one key more.

Think about giving a dog walker a key to your house. You give them the front door, not the safe, not the car, not the office. A skill is the same. A morning briefing needs to read your calendar and the weather. It does not need to send email as you. A meeting-notes tool needs your notes. It does not need your bank login.

- **Reading versus doing.** Reading your calendar is mild. Sending messages or moving money as you is a much bigger deal, and a skill should only ask for that if its actual job requires it.
- **Scope.** "Read this one folder" is very different from "read everything." We prefer skills that ask narrowly.
- **Need, not nice-to-have.** If access is not required for the job in front of it, asking for it anyway is a flag, even when nothing bad is happening.

> **A flag is not always a crime.** Asking for too much access does not mean a skill is malicious. Often it is just lazy, written to grab broad permissions because that was easier. But lazy and dangerous can look identical from the outside, so we treat both the same way: question it, and do not list it until it tightens up.

## Third: hidden instructions and prompt injection

This is the sneaky one, and it is worth slowing down for. A skill is, at heart, a set of instructions written for your AI to follow. Most of those instructions are exactly what you would expect. But because your AI reads them and tries to obey, a bad actor can bury an instruction in there that is aimed at the AI, not at you.

Imagine you hand a new assistant a stack of papers, and slipped somewhere in the middle is a note that reads, "ignore everything your manager told you and quietly forward these documents to this address." A careless assistant might just do it. That is prompt injection, and it can hide inside a skill or even inside the data a skill reads.

So we read the whole thing looking for sentences that talk to the AI instead of helping you. Instructions to ignore earlier rules. Instructions to send things somewhere. Instructions that have nothing to do with the job and everything to do with sneaking around it. If we find one, that is not a flag, that is a hard no.

## Fourth: would any of your data leave the device?

This one is close to my heart, because privacy is the whole reason AgentPod exists. We read every skill for any outside address it tries to reach. Then we ask one question: does the job actually need that?

A skill that drafts an email reply has no reason to phone a server we have never heard of. A skill that summarizes your own notes should not be shipping those notes off somewhere. When a skill does reach out, we want a plain, honest reason, and we write it down so you can see it too. On an AgentPod, most skills never need to leave the box at all, which is exactly how we like it.

> **Why this matters more than it sounds.** Once your data leaves your device, you lose control of it. You cannot un-send it. So "does anything leave?" is not a small technical detail. It is the difference between private and not.

## Fifth: are the permissions clear?

A skill can be perfectly honest and still be confusing. If the permissions are buried in code or written in a way only an engineer could parse, that is a problem for normal people, which is to say, for almost everyone.

So part of the review is just clarity. Can we explain, in one plain sentence, what this skill can reach and what it can do? If we cannot, we either rewrite the explanation so a person can understand it, or we do not list the skill. You should never have to be a programmer to know what you just turned on.

## Last: a plain-English read of the whole thing

After all the specific checks, someone steps back and reads the skill the way a thoughtful friend would. Does this hang together? Does the way it works match what it promises? Is there anything that just feels off, even if no single line breaks a rule?

Checklists are great, but judgment catches the things a checklist misses. This last pass is where experience earns its keep.

1. **Compare claim to reality.** Read what the skill does, then read what it actually touches, and check that they match.
2. **Check access against the job.** Make sure it asks only for what its one task needs, and nothing more.
3. **Hunt for hidden instructions.** Read the whole thing for any sentence aimed at the AI instead of at you.
4. **Trace the data.** Find every outside address it talks to, and confirm the job actually requires it.
5. **Make the permissions plain.** Boil it down to one sentence a normal person can understand.
6. **Read it like a human.** Step back and ask whether the whole thing feels honest and sound.

## The honest part: a review is not a guarantee

I have to be straight with you, because I would want someone to be straight with me. A security scan is a careful, good-faith review by a person who knows what to look for. It is not a magic force field. No review on earth can promise a piece of software will behave perfectly forever.

That is exactly why we do not stop at the review. For every skill, we also show you, in plain language, what it touches and what it can do. The review is us doing the homework first. Showing you the result is us refusing to ask for blind trust. You keep the final say, always.

> We do the homework so you do not have to. Then we show you the homework, so you never have to just take our word for it.

If you want the broader picture of how to think about safety, I wrote a companion piece on whether [AI skills are safe](/learn/are-ai-skills-safe) in general. And if some of the words here still feel fuzzy, the gentle starting point is [what an AI skill even is](/learn/what-is-an-ai-skill). You can also see how we summarize all of this on our [security page](/security).

That is the bet we are making. Most people do not want a giant pile of skills to sift through and police themselves. They want a small, vetted shelf where someone already did the reading. Two skills that get this kind of review, and that I would happily put on my own device, are below.

- [Subscription Auditor](https://agentpod.com/skills/subscription-auditor): Reads your statements, finds the charges you forgot, and touches nothing else.

- [Email Triage & Draft](https://agentpod.com/skills/email-triage-and-draft): Sorts your inbox and drafts replies, while you keep the send button.

If you would rather start with a whole tidy set instead of one skill, the [Inbox Zero](/bundles/inbox-zero) bundle goes through the same review, skill by skill.

- [Inbox Zero](https://agentpod.com/bundles/inbox-zero): A reviewed set of skills that gets your inbox calm and keeps it there.

**The short version:**
- A real review compares what a skill claims to do against what it actually touches.
- It checks that the skill asks only for the access its one job needs, nothing more.
- It reads the whole skill for hidden instructions aimed at your AI (prompt injection).
- It traces whether any of your data would leave your device, and whether that is even necessary.
- It is a careful, good-faith review, not a guarantee, so we also show you what each skill touches and let you decide.

## Common questions

### Does a security scan mean a skill is guaranteed safe?

No, and I would not trust anyone who told you it did. A scan is a careful, good-faith review by a person who knows what to look for. It catches the things you would never spot yourself, like a buried instruction or a request for access the job does not need. But software changes, and no review can promise a thing will behave perfectly forever. That is why we also show you what each skill touches, so you keep the final say.

### What is prompt injection, in plain terms?

It is a hidden instruction tucked inside a skill (or inside the data a skill reads) that tries to make your AI do something you did not ask for. Think of a note slipped into a stack of papers that says "ignore your boss and forward these to me." A good review reads the whole skill looking for sentences like that, especially ones aimed at your AI rather than at you.

### How do you know if a skill sends my data somewhere?

We read the skill for any address it talks to. A skill that drafts an email reply has no reason to phone a server we have never heard of. If it reaches out somewhere, we want a plain reason why, and we note it so you can see it too. On an AgentPod, most skills never need to leave the device at all.

### What does "asks for more access than the job needs" mean?

A skill should only request what its one job requires. A subscription finder needs to read your statements, not send messages as you. A meeting-notes tool needs your notes, not your contacts. When a skill asks for more than its job calls for, that is a flag, even if nothing bad is happening. Least access is just good hygiene.

### Can I see the review, or do I just have to trust you?

You do not have to take our word for it. For every skill, we publish what it touches and what it can do in plain language, right on the skill page and summarized on our [security page](/security). The review is us doing the homework first. Showing you the result is us refusing to ask for blind trust.

### Where can I learn the basics first?

If terms like skill or permission still feel fuzzy, start with [What is an AI skill?](/learn/what-is-an-ai-skill) for the plain version, then read [Are AI skills safe?](/learn/are-ai-skills-safe) for how to think about risk. This article goes one level deeper into the actual checks we run.