Third-party marketplaces list well over a million agent skills with no consistent vetting process. Some of those artifacts read credentials and act autonomously the moment they're installed. Existing security infrastructure, audit logs that record something changed after the fact, and detection tools built to hunt known-bad signatures, weren't built to answer the question that actually matters here: what is a given skill or MCP configuration actually built to do.
Why monitoring after the fact isn't enough
An audit log telling you a file changed is useful forensic evidence once something has already gone wrong. It doesn't tell you, before install, whether a new skill's actual behavior matches what it claims to do. Similarly, tooling built to hunt for known indicators of compromise depends entirely on that indicator already existing somewhere in a threat feed. A newly written malicious agent skill, unique to this attacker, this campaign, this moment, has no prior signature to match against. Genuine defense in depth here means inspecting the artifact itself, not waiting for its behavior to already be cataloged as bad somewhere else.
What existing tools structurally miss
Roughly half of the attack surface in this category lives in language, not code: SKILL.md directives, tool descriptions, metadata, IDE rule files. Signature-based tools built to scan code read none of that. That's not a minor gap. It's the layer where hidden instructions, coercive directives, and deceptive tool descriptions actually live, and it's exactly why a code-only scanning approach leaves half the problem uncovered by design, regardless of how well it performs on the half it does cover.
Inspecting the artifact itself, at every point it enters the environment, is a fundamentally different posture than monitoring for signs that something already went wrong.
Measuring upstream, not just what's already inside your walls
Most existing approaches only see an artifact once it's already reached your environment. Tracking what changes across the registries and marketplaces developers actually install from flips that timeline: a compromised publisher gets flagged everywhere their artifacts appear, not just in the single instance your organization happened to encounter, and that intelligence can inform your own environment automatically rather than waiting for a direct hit.
Bringing it together under one verdict
Defense in depth doesn't mean five disconnected tools each catching a different slice of the problem and reporting separately. It means static rules triaging every pull request, sandboxed execution validating suspicious findings against honeypot credentials, and a reasoning layer adjudicating the ambiguous cases, all resolving to one consistent verdict rather than requiring a human to reconcile five different opinions about the same artifact. Ambiguous cases escalate to review instead of silently becoming just another alert in a queue nobody clears.
FAQ
Isn't this just a more complicated version of existing endpoint security? It's complementary, not a replacement. Existing endpoint and detection tooling is built to catch known-bad signatures and behavioral anomalies at the system level. This layer is built specifically to read and evaluate the AI artifacts themselves, code and natural-language instructions together, which most existing tooling was never designed to parse.
Does defense in depth here mean deploying everything at once? No. It means the different layers, browser, endpoint, source control, upstream registries, governance, are designed to work together under one policy engine, so an organization can start with the layer that closes their most urgent visibility gap and expand from there.
What's the actual risk of not doing this? An unvetted agent skill or MCP configuration with credential and network access, running with a developer's or a service account's permissions, without your organization having any visibility into what it's actually built to do before it does it.
Related reading: "Five Layers, One Policy Engine: Inside Our Coverage Model," "Trust Tiers: A Governance Framework for Agent Skill Allowlisting"











