Your AI assistant can now check your calendar, book restaurants, send emails, and order groceries. You didn't build those features yourself. You installed them. They're called "skills" — little packages of functionality that extend what your AI agent can do. Just like browser extensions. Just like app store downloads. Just like every other thing you've clicked "Allow" on without reading.

A security firm just proved something nobody wanted to hear: they built a fake AI agent skill, made it look helpful, pushed it through a popular skill marketplace and ran Instagram ads for it. It passed every security scan. It reached roughly 26,000 AI agents before they pulled it down.

The skill did exactly what they designed it to do. And nobody — not the marketplace, not the security scans, not the 26,000 deployers — caught it.

Here's what an AI agent skill actually is: code that runs with your agent's permissions. When you install a skill that helps your AI "read your email and summarize it," you just gave a third-party developer access to your inbox. When you add a skill that "checks your bank balance and suggests budgets," you just handed your financial API access to someone you've never met.

The promise is convenience. The reality is a supply chain attack surface that makes browser extensions look quaint.

Browser extensions ask for permissions. You can see the list. You can deny them. AI agent skills don't work that way — they inherit the agent's access, and your agent has access to everything you connected it to. Email. Slack. Google Drive. Your CRM. Your cloud console. The skill doesn't ask. It just gets.

Security firm AIR built their proof-of-concept to demonstrate exactly this. They created a skill that looked legitimate, functioned as advertised, and contained hidden behavior that would only trigger under specific conditions. Multi-stage attack logic. Time-delayed execution. The kind of thing that doesn't show up in basic security scans because it's not actively malicious until it needs to be.

26,000 agents installed it. The marketplace approved it. The scans passed it.

That number — 26,000 — isn't the scary part. The scary part is that nobody noticed until the researchers announced it.

In the last eighteen months, AI agents went from experimental tools to business-critical systems. Companies are deploying agents that handle customer support, process invoices, manage cloud infrastructure, and access internal databases. Every single one of those agents is being extended with third-party skills because nobody has time to build everything from scratch.

Skill marketplaces are exploding. Developers are racing to build the "Zapier for AI agents." Venture capital is pouring into companies that want to be the skill layer for the agent economy. And every single one of them is learning the same lesson the app stores learned a decade ago: it is nearly impossible to scan code for malicious intent when that intent is designed to hide.

Static analysis doesn't catch multi-stage attacks. Sandboxing doesn't catch logic that only triggers after 30 days or when a specific API call happens. Code review doesn't scale when thousands of skills are being published every week. And reputation systems don't work when attackers can build credibility with a dozen safe skills before publishing the malicious one.

We are watching the mobile app supply chain attack playbook get copied into the agent ecosystem in real time. Except this time, the apps have direct access to your company's most sensitive systems.

1. Audit what your AI agents can actually access. Open the admin panel for every AI tool your company uses. Look at what it's connected to. If your customer support agent has access to your entire user database when it only needs read access to support tickets, fix that today.

2. Treat agent skills like you treat browser extensions — with suspicion. Before you install a skill, ask: who built this? What does it actually need access to? Is there a way to do this without a third-party skill? If you can't answer those questions, don't install it.

3. Ban third-party skills in production environments until you have a review process. If your company is deploying AI agents that touch real data, make a rule: no skills get installed without security review. Not because skills are all bad, but because one bad skill can access everything.

4. If you're building an AI agent, implement least privilege at the skill level. Every skill should explicitly request the permissions it needs. If a calendar skill asks for access to your file storage, that's a red flag. Build your agent architecture so skills can't inherit god-mode access by default.

5. Watch for skills that update frequently or request new permissions after install. The attack pattern here is: build a safe skill, get it approved, gain user trust, then push an update that adds malicious behavior. If a skill you installed six months ago suddenly asks for new access, treat it like a security incident.

I've done enough agent architecture reviews in the last 12 months to tell you the skills problem isn't theoretical — it's already in your environment, you just haven't looked.

The pattern I keep seeing: a team deploys an AI assistant to handle internal helpdesk tickets or Jira triage. They connect it to Slack, Confluence, and GitHub because that's where the context lives. Then someone on the team installs a productivity skill from the marketplace — something that summarizes meeting notes or formats output — without a ticket, without a review, without even telling security it happened. The skill inherits the agent's OAuth grants. It now has read access to your entire internal wiki and your code repositories.

The thing most orgs haven't internalized yet is that agent skills don't operate in isolation. When you grant an agent access to five systems and then install a third-party skill, that skill effectively has access to all five. There's no per-skill permission scoping in most platforms today — that's not a vendor criticism, it's just where the ecosystem is.

What I tell clients right now: treat your agent's connected integrations like a blast radius calculation. Before you add any skill, ask what the agent already has access to. That's your exposure if the skill is malicious or gets compromised in a future update. If the blast radius is "everything," you have an architecture problem that no skill vetting process fully solves.

But here's the problem that compounds fast once organizations scale beyond one or two agents: permissions are being managed inside each agent individually. There's no centralized place to see what every agent can access, which skills are installed across all of them, or what happens when an employee leaves and their connected accounts need to be revoked. You end up with the same sprawl problem we had with service accounts before PAM and identity governance tools existed — except now it's multiplying faster because spinning up a new agent takes minutes.

The short-term fix is a skills whitelist enforced at the admin level — nothing gets installed that hasn't been reviewed. The longer-term fix is treating AI agents as identity principals in your IAM program: centrally inventoried, governed with the same lifecycle management you apply to human accounts, and auditable at any point in time. If your identity governance platform doesn't have an answer for non-human identities yet, that conversation needs to happen now — before the agents do.

Look at the AI tools you installed in the last six months. How many of them asked to connect to your email, your calendar, your Slack, your cloud accounts? How many skills or integrations have you added since then?

What did you give them access to?

—

Identity Decoded publishes every week at identity-decoded.com