0x4D31/endpoint-ai-agent-abuse

What it is

The GitHub repository 0x4D31/endpoint-ai-agent-abuse (EAA), catalog version 0.3.2, released CC0 1.0. The existing summary covers its scope; what it can't carry is how the catalog encodes evidence — the semantics you need to read a claim correctly before acting on it.

How it works

Two dimensions are tracked independently: technique maturity and per-case status.

Maturity has three tiers with precise meanings:

• feasible — an authoritative source establishes the surface and an agent-specific abuse path, but no public implementation is known.
• demonstrated — public research or a malicious artifact implements it.
• observed — an incident-context case shows the scoped action was planted, executed, or produced confirmed impact.

Separately, each case records whether a procedure was present, planted, attempted, executed, or produced confirmed impact. The catalog's scope is deliberately narrow: it is not a general AI-security taxonomy, and product applicability is asserted only where an official doc, primary artifact, incident, or reproducible study supports it — with trust gates, defaults, OS, and product version treated as part of the claim.

The repo is navigated through named files: techniques/index.md (main catalog), scope.md, surfaces.md, tactics.md, cases.md, hunting.md, candidates.md (ideas below the promotion threshold), evidence.md (the full maturity/confidence rules), plus data/catalog.json and data/catalog.schema.json.

What to do

If you contribute or fork, validate structural consistency before submitting:

python3 scripts/validate.py

It cross-checks IDs, metadata, relationships, canonical case mappings, cases, surfaces, tactics, candidates, versions, and local links. Version-bump convention: minor for taxonomy/surface/evidence/naming changes; patch for wording, source updates, and new non-model-changing examples.

Caveats

The two most load-bearing limits, stated by the page itself:

• observed ≠ activated. For a planting technique, "observed" does not imply later activation; nor does it mean every cited artifact executed successfully or that every reported downstream effect was confirmed.
• A passing validator confirms structure, not truth. It verifies internal consistency only — claim-level source review is still required, and applicability is version- and default-dependent, so don't generalize a technique across products the catalog hasn't scoped it to.

flowchart TD
    A[Technique entry] --> B{Maturity}
    B -->|feasible| C[Authoritative surface,<br>no public impl]
    B -->|demonstrated| D[Public research<br>or artifact]
    B -->|observed| E[Incident-context case]
    E --> F{Case status}
    F -->|planted| G[Not necessarily<br>activated]
    F -->|executed / confirmed impact| H[Verified effect]