u/SelectionBitter6821

Been thinking about this since a weird moment last week: I gave an agent a task, it pulled in a file to help, and the file had a line in it that wasn't meant for me, it was meant for the agent. And the agent just read it. No way for it to know that line wasn't part of my actual request.

That's when it clicked that "instructions" and "just some text sitting in a document" are the same thing to a language model. There's no compiler or type-checker telling it "this part is a command, this part is just content," the way there is for basically every other kind of software. It just reads language and decides what to do.

We've spent decades building security around the idea that data and instructions are different things. Agents don't really have that line, and existing standards don't have a home for what breaks because of it: a CVE describes a flaw in a specific package and version, there's no package here. CWE describes a weakness in code, there's no code being executed in the traditional sense, just text being interpreted.

Ended up deep enough in this that a few of us built AVE, an open standard that names these behavioral patterns directly instead of trying to force-fit them into categories built for a different kind of system, 70 records so far, crosswalked into OWASP's and MITRE's own frameworks so it's not reinventing anything that already exists elsewhere.

github.com/aveproject/ave if anyone here working in security wants to poke at it or tell me where it's wrong. Genuinely curious if the "no data/instruction boundary" framing matches how security folks here are already thinking about this, or if there's a sharper way to put it.

TL;DR: real, disclosed RCE in the STDIO transport across several official MCP SDKs (Python, TS, Java, Rust), unsanitized shell passthrough, now cataloged as AVE-2026-00060. Taxonomy's grown to 65 records since I first posted here. Independent cross-validation already happened, unprompted, no shared code.

Posted an early version of this here a while back, coming back with an actual update rather than letting it go quiet.

**The RCE, if you're running an affected MCP SDK version**: tool call parameters get passed straight to a host shell without sanitization, so a crafted parameter executes as a shell command. Independently corroborated by OX Security, CSA, and Microsoft. Worth checking against patched releases directly, not waiting on a scanner to catch it.

On the taxonomy itself: **65 records now**, each a distinct behavioral vulnerability class with a stable ID, scored against OWASP's own AIVSS framework, crosswalked into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS.

The thing that's actually made me trust it holds up beyond my own tooling: an independent developer built an unrelated static config auditor, crosswalked his own findings against this, and tested it directly against my scanner on the same files, **no shared code**. Most overlapping findings converged on the identical ID, unprompted.

Also wrote down real growth discipline since last time: a new record needs a genuinely distinct mechanism, not a label mirroring another framework's category, learned that lesson watching MITRE's own CWE ship a version where new entries were, by outside analysis, zero actual weaknesses.

Apache 2.0, open standard and reference implementation both. Curious if the STDIO finding is news to anyone here, and where the taxonomy's still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: still the same person building this as last time.

Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch.

The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels.

Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither.

AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today.

The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there.

Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: I'm the one building this.

Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch.

The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels.

Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither.

AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today.

The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there.

Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: I'm the one building this.

I'm a DevSecOps engineer, and this is the exact version of a problem I hit at work, not something I noticed from the outside.

Run SAST, SCA, and an AI-agent-specific scanner across the same codebase, and you'd expect some redundancy. What you actually get is worse: the same underlying issue, flagged by two different tools, with two completely different names and no way to tell your pipeline they're the same finding. Multiply that across a real CI/CD setup with several tools chained together, and triage turns into manually reconciling naming conventions instead of fixing anything.

This isn't a new problem in general. A SQL injection gets a CVE ID, maps to a CWE category, and every tool in the pipeline that finds it points at the same reference. That's exactly what makes cross-tool correlation possible for conventional vulnerabilities.

Agentic AI components (MCP servers, agent skills, LLM plugins) had nothing like that, for a real structural reason: CVE needs a package and version to attach to, CWE describes code-level weakness patterns, and neither has a vocabulary for a behavioral pattern that isn't tied to either.

So a few of us built AVE (Agentic Vulnerability Enumeration): an open standard giving these classes stable IDs, the same way CVE does, so a finding from one tool can actually be compared against a finding from another.

What's in it: 59 records, each a distinct behavioral class. Severity scored with OWASP's own AIVSS framework. Crosswalked into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS, plus AVE-in-SARIF, so IDs ride directly into GitHub's own Security tab and CI output without any custom tooling. Apache 2.0.

The part that actually convinced me this holds up outside our own tooling: a completely independent developer built a static config-file auditor, sharing no code with anything we wrote, crosswalked his own findings against AVE's taxonomy, and tested it directly against our scanner on the same files. The large majority of overlapping findings came back with the identical ID, unprompted.

If you're dealing with the same multi-scanner reconciliation problem, in this space or a completely different one, I'd like to hear how you're handling it, and where this looks wrong or incomplete.

Repo: github.com/aveproject/ave
Site: aveproject.org

(Disclosure: I'm one of the people building this.)

I’ve been working on an open-source project called AVE (Agentic Vulnerability Enumeration), the behavioral classification standard and would really appreciate feedback from security professionals.

The motivation is that we’re starting to secure things like:
- MCP servers
- Skill files
- System prompts
- Agent plugins
- Agent workflows

But today’s vulnerability identifiers (CVE, OSV, etc.) are designed around software packages and versions. They don’t describe behavioral attacks that exist only because an LLM interprets instructions.
For example:
- Prompt injection hidden inside a skill
- Tool description poisoning
- MCP server-card injection
- Memory poisoning
- Cross-agent prompt injection
- Silent tool registration
- Unsafe delegation chains
These aren’t tied to a vulnerable library version, they’re behavioral attack classes.

So AVE attempts to provide:
- Stable IDs for behavioral attack classes (currently 59)
- A JSON schema for interoperability
- AIVSS scoring (built on CVSS concepts with agent-specific risk factors)
- Crosswalks to OWASP MCP Top 10, MITRE ATLAS, NIST AI RMF, and other AI security frameworks
- A reference scanner (Bawbel Scanner) that detects AVE patterns in skill files, MCP manifests, and related agent artifacts

I’m not claiming this is the right solution, and I know standards only become useful if practitioners find them valuable.

I’d really appreciate criticism on questions like:
- Does this solve a real problem, or are existing standards already sufficient?
- Should these behavioral classes live under something like CVE/CWE instead of a new namespace?
- Are the attack classes too broad or too granular?
- Does the AIVSS scoring model make sense, or is there a better way to score agentic AI risk?
- What important attack classes am I missing?
- If you were building security tooling for AI agents, would a registry like this be useful?

I’m especially interested in feedback from people working in AppSec, AI security, offensive security, detection engineering, or anyone building MCP/agent ecosystems.

I’m looking for honest technical criticism more than praise. If you think this is the wrong direction, I’d genuinely like to know why.

Thanks for taking a look.

We build a security scanner for MCP servers and agent skills. Early on we hit something that shouldn't still be a problem: comparing our findings against other scanners on the same test servers, we'd all catch roughly the same bad behavior and call it three different things. No shared ID, no way to say "scanner A's finding X is the same class as scanner B's finding Y."

A SQL injection gets a CVE ID, gets mapped to a CWE, and every tool that finds it points at the same identifier. Agentic AI components had nothing like that. CVE maps to package plus version. It has no vocabulary for "this tool description contains a hidden instruction."

So we built AVE (Agentic Vulnerability Enumeration): an open, vendor-neutral behavioral classification standard.

What's in it:

* 59 records, each a distinct behavioral class. Deliberately conservative, no padding with variants.
* Stable IDs (AVE-2026-NNNNN), meant to work the way a CVE ID works.
* Real MCP-specific classes: tool description injection (AVE-2026-00002), server card injection (AVE-2026-00041), OAuth discovery rebinding (AVE-2026-00051), a tool hook hijack that's our only CRITICAL-rated record so far (AVE-2026-00046).
* Maps to OWASP's MCP Top 10, plus the Agentic Security Initiative Top 10 and MITRE ATLAS where applicable. Sits underneath frameworks people already use, not a replacement for them.
* Scored with OWASP's own AIVSS (v0.8), not a severity number we invented.

It's early. One reference implementation right now, our own scanner, and we're looking for a second, independent one to prove this works outside our own tooling. If you maintain a scanner and any of this is useful, wrong, or missing something obvious, we'd like to hear it.

Repo: github.com/aveproject/ave Site: aveproject.org

(Disclosure: I'm one of the people building this.)

We build a security scanner for MCP servers and agent skills. Early on we hit something that shouldn't still be a problem: comparing our findings against other scanners on the same test servers, we'd all catch roughly the same bad behavior and call it three different things. No shared ID, no way to say "scanner A's finding X is the same class as scanner B's finding Y."

A SQL injection gets a CVE ID, gets mapped to a CWE, and every tool that finds it points at the same identifier. Agentic AI components had nothing like that. CVE maps to package plus version. It has no vocabulary for "this tool description contains a hidden instruction."

So we built AVE (Agentic Vulnerability Enumeration): an open, vendor-neutral behavioral classification standard.

What's in it:

• 59 records, each a distinct behavioral class. Deliberately conservative, no padding with variants.
• Stable IDs (AVE-2026-NNNNN), meant to work the way a CVE ID works.
• Real MCP-specific classes: tool description injection (AVE-2026-00002), server card injection (AVE-2026-00041), OAuth discovery rebinding (AVE-2026-00051), a tool hook hijack that's our only CRITICAL-rated record so far (AVE-2026-00046).
• Maps to OWASP's MCP Top 10, plus the Agentic Security Initiative Top 10 and MITRE ATLAS where applicable. Sits underneath frameworks people already use, not a replacement for them.
• Scored with OWASP's own AIVSS (v0.8), not a severity number we invented.

It's early. One reference implementation right now, our own scanner, and we're looking for a second, independent one to prove this works outside our own tooling. If you maintain a scanner and any of this is useful, wrong, or missing something obvious, we'd like to hear it.

Repo: github.com/aveproject/ave Site: aveproject.org

(Disclosure: I'm one of the people building this.)

A pattern we keep seeing: an agent tool or MCP server is clean at install, passes hash verification and static analysis, then the remote endpoint it fetches instructions from changes weeks later. Artifact-layer defenses are blind to this by design. Is anyone doing runtime monitoring for this, something like snapshotting remote content at install, re-fetching on use, and diffing for semantic drift? Or is there existing tooling outside of research papers that handles post-install behavioral change?

We support 200+ developers and rolled out agentic coding tools this year. The failure modes were not what we expected. Not "AI wrote insecure code" but things like agents committing credentials from local env files, installing unvetted dependencies to satisfy a task, and pipeline tokens with way too much scope being handed to autonomous processes. Interested in what surprised other teams, especially in regulated industries.

Hot take from a banking DevSecOps team: treating prompt injection as something the model vendor should fix is a dead end. The real issue is that the context window has no provenance. The model cannot tell user instructions from a poisoned README or a tool response. Until that changes, the practical mitigations look a lot like classic supply chain controls: pin your dependencies, verify what you fetch, restrict what each component is allowed to do. Anyone mapping this to SLSA-style controls yet?

Our devs are pulling MCP servers and agent skills from GitHub like npm packages, but there is no equivalent of a lockfile audit for “this tool description can instruct the model to exfiltrate data.” Static scanning catches some of it, but a server can change its remote behavior after install and nothing flags it. Curious what others are doing: allowlists, manual review, network egress controls, or just accepting the risk for now?

CVE was built for code vulnerabilities that have patches.

Agentic AI vulnerabilities are behavioral patterns in natural language. No binary to patch. The attack surface is every sentence an agent reads.

Why that required a new standard:

1/ The scoring problem:

Same prompt injection attack in two contexts:

Stateless chatbot, no tools: CVSS 4.0

Agent with persistent memory, tool access, multi-agent spawning: 8.5

CVSS captures neither the autonomy level nor the tool blast radius.

AIVSS does. 10 Agentic Risk Amplification Factors, each 0.0/0.5/1.0.

2/ The detection problem:

CVE records describe what happened after an exploit.

They do not include behavioral fingerprints for static analysis.

AVE records include:

- Behavioral IOCs

- Detection methodology

- Pattern examples

- OWASP MCP + ASI mapping

- Remediation

3/ The standard problem:

"Tool poisoning" and "tool description injection" are the same attack.

Without stable IDs, you cannot write detection rules that share a taxonomy.

AVE gives every attack class a stable ID, 48 records. Apache 2.0. Open for contributions.

The sequence is always the same: registry launches and grows fast, minimal vetting because the priority is growth, first wave of incidents, community outrage, tooling catches up, security becomes a baseline expectation. npm took about three years to go from event-stream to npm audit being standard. Docker Hub took similar.

MCP is at step 2 heading into step 3. The numbers from a scan of 500 Smithery servers this month: 18.8% had security findings, 6 had live hardcoded credentials, none were caught by a pre-publication scan because there is no pre-publication scan. A Check Point research disclosure in February showed an 8.7 CVSS attack chain against Claude Code where the entire payload was natural language in a config file.

The difference from npm is what the malicious content does. An npm package executes unauthorized code. A malicious MCP skill file gives unauthorized instructions to an agent that already has access to your tools, file system, and APIs. The LLM cannot distinguish between instructions from the user and instructions from a skill file. Both arrive in the context window and both get acted on. Existing security tooling has no model for this.

The fix is the same three layers it always is: pre-publication registry scanning, CI integration for consumers, and a public advisory database. None of the three exist yet in any mature form for MCP.

Whether the timeline is one year or three depends on whether registry operators move proactively or wait for a sufficiently public incident. Based on how npm and Docker played out, my bet is on the incident coming first.

We built a static scanner for this: pip install bawbel - scans skill files and MCP server configs without executing anything. The vulnerability database it checks against the AVE.

bawbel scan-server-card for scanning MCP server-cards before connecting, rug pull detection with git-committed pins, and conformance scoring. 5 new AVE records covering the MCP 2026 attack surface. Free, open-source, Apache 2.0.

pip install "bawbel-scanner==1.1.0"