Security: prompt-injection scanning on inbound P2P skill content before LLM exposure

[VGIL77]

The current P2P skill ingestion pipeline at src/agents/skills/ingest.ts defends against unauthorized injection (Ed25519 signature on the bytes, SHA-256 content hash, SKILL.md schema validation, quarantine-by-default, per-peer rate limiting). What it doesn't defend against: a signed-but-malicious skill from a compromised trusted peer, where the SKILL.md bytes themselves contain adversarial instructions targeting the LLM that later reads the skill.

Threat model

An attacker with control of a previously-trusted pubkey publishes a skill whose content embeds prompt-injection text: "ignore prior instructions," planted role markers, encoded exfil instructions, etc. Under auto policy with that pubkey on the trust list, current code accepts it directly into the skills directory (ingest.ts:139-176). Next time the agent loads the skills snapshot for inference, the payload reaches the LLM with no further gating.

Signing and hashing don't help here. The transport layer can't see what the content layer says.

Proposed defense

Pre-LLM injection scan, run before bumpSkillsSnapshotVersion makes the skill visible to the agent:

• Rule-based heuristics for known patterns (jailbreak strings, unusual role markers, base64/hex-encoded payloads inside descriptions, suspicious YAML frontmatter)
• Optional cheap classifier pass for borderline cases
• Suspicious content gets force-quarantined regardless of pubkey trust level; operator must explicitly approve out of skills-incoming/
• Existing validateSkillContent at ingest.ts:303 is the natural place to layer this in as a tiered validator

Out of scope here

Capability sandboxing on what skills can do once active is a separate problem, filed as its own issue. This one is purely about catching adversarial content before the LLM sees it.

Why now

Surfaced from public scrutiny on the architecture (a r/LocalLLaMA reader called this exact gap). The transport-layer defenses are real but the content-layer defense is the right next thing to ship.

[VGIL77]

Phase A landed in cb09419 on main.

The injection-scan layer (Layer 1 of the planned defense in depth) is live. Adversarial SKILL.md content from a signed-but-malicious peer no longer reaches the LLM unless an operator approves it from quarantine, regardless of trust level.

What shipped

• src/security/skill-injection-scanner.ts runs on the decoded bytes after Ed25519 + hash verification but before either auto-accept or quarantine. It returns categorized severity (ok / low / medium / critical) across instruction-override, role-marker injection, tool-call impersonation, persona-shift, exfil, worm-propagation, encoded-payload, and destructive-command.
• src/agents/skills/ingest.ts Stage 5b: a critical verdict force-quarantines the skill even under auto policy with a trusted publisher. The persisted .envelope.json carries the scan result so the review UX can show why the skill was held. Worm-propagation patterns are weighted heavy on their own; pure self-propagation language has effectively no benign use in a skill body.
• src/agents/skills/workspace.ts Spotlighting: when any active skill carries a .provenance.json (P2P origin marker), the prompt builder prepends a security notice telling the LLM to treat skill bodies as reference material rather than authoritative instructions.
• src/memory/peer-reputation.ts adds recordInjectionFlag(pubkey, severity). 3+ critical hits inside 24h trip an auto-ban for the publisher (first auto-ban path in the system; manual banPeer continues to work as before).
• src/agents/skills/ingest.ts queues a system-event on the main session whenever a skill lands in quarantine, including the reason. Operators see held skills inline rather than having to remember to call skills.quarantine.list.
• New config knob: skills.p2p.injectionScanner: "regex" | "off" (default "regex"). The "classifier" mode is reserved for Phase C.

Tests

• src/security/skill-injection-scanner.test.ts — 16 unit tests including a Phase A ship-gate suite that asserts ≥80% of canonical attacks classify as critical with 0 false-positive criticals on a benign corpus.
• src/agents/skills/ingest.injection.test.ts — 3 integration tests that sign envelopes with real Ed25519 keypairs, route through ingestSkill, and assert the force-quarantine + reputation-flag + scanner-disabled paths.

19/19 tests passing, full repo typecheck clean, lint clean.

What's still open

• src/memory/skill-network-bridge.ts has a parallel ingestion path for crystals into SQLite (separate from the SKILL.md filesystem layer). The scanner is not yet wired into that path. Tracking as Phase A.5; small follow-up.
• Classifier pass (Phase C): an ML scanner shipped in-bundle (StackOne Defender-class, ~22MB ONNX) for borderline cases the regex pass misses. Architecture is in place via the injectionScanner enum; the model itself is not yet bundled.
• Per-skill boundary markers: today the Spotlighting notice is global. Per-skill <<<EXTERNAL_UNTRUSTED_CONTENT>>> wrapping requires forking pi-coding-agent's formatSkillsForPrompt; deferred to Phase B where we already need to fork it for capability declarations.

Community ask: extend the adversarial corpus

The scanner is rule-based, which means it has a finite test surface. The strongest contribution we can take here is adversarial test cases: novel injection payloads or jailbreak strings the regex set might miss. If you can break the scanner with a payload that ends in a wallet.send_usdc invocation, a .env exfil, or a self-propagation instruction, please drop it as a comment with the expected severity. Acceptance criterion is that adding the payload to src/security/skill-injection-scanner.test.ts produces a verdict ≥ medium. We'll either tune the patterns or escalate to the classifier pass on Phase C.

Phase B (capability declarations + runtime gate, addressing #21) is up next.

[VGIL77]

Phase A.5 landed in 1f2e6b5 — wired the injection scanner into the second ingestion path.

The Phase A scanner only sat on the SKILL.md filesystem ingest at src/agents/skills/ingest.ts. Crystals can also reach the active memory through src/memory/skill-network-bridge.ts:ingestNetworkSkill (the SQLite-backed parallel path). That route now runs the same scan: a critical verdict rejects the envelope outright (the bridge has no quarantine, so rejection is the analog), and the same recordInjectionFlag signal feeds reputation. Inserted before the existing SkillVerifier pass so categorized severity + reputation feedback land even when the older blocklist would have caught the same content.

This closes the parallel-path gap noted at the end of the original Phase A status comment.

[thynt2]

Good catch — this is a clear gap between transport integrity and content safety.

Signatures and hashes ensure authenticity, but they don’t protect the LLM from malicious instructions embedded in otherwise valid skills. A compromised trusted peer is enough to bypass current defenses.

A pre-LLM injection scan before bumpSkillsSnapshotVersion makes sense as the missing layer. Heuristics + optional classifier + force quarantine (regardless of trust level) is a reasonable approach.

validateSkillContent looks like the right place to plug this in.

Agreed this should stay separate from capability sandboxing — even with sandboxing, letting adversarial content reach the model is unnecessary risk.

[bestiya]

+1. Signing proves origin, not safety — this is a content-layer gap.

Scanning before exposure to the agent and quarantining on suspicion feels like the right minimal guardrail. Integrating it into validateSkillContent keeps the pipeline clean.

[bulltickr]

We've been solving the same problem at the MCP tool-call layer in McpVanguard — a few findings that map directly here:

Your Phase A → Phase C progression mirrors our L1/L2 model. Regex gets you 80%, a cheap LLM semantic scorer (we use Groq/llama-3.3-70b) catches the persona-obfuscation and role-marker patterns that regex misses at ~300ms latency — well within pre-ingestion budget.

A gap worth flagging for Phase B: Behavioral Fragmentation — splitting a payload across multiple trusted skills so no single one triggers critical. We accumulate risk tokens across a session window to catch the composite. Worth considering before capability declarations land.

On the adversarial corpus ask: happy to port relevant payloads from our Chaos Engine test suite to your skill-injection-scanner.test.ts format.

[VGIL77]

Thanks for the detailed read. The architecture mapping holds: your L1 (deterministic rules) ↔ our Phase A regex, and your L2 (semantic scorer) is what Phase C is shaped around. Phase B (capability declarations) sits orthogonal to both layers, which is why your Fragmentation point is uncomfortably good.

Confirmed it's a real gap on our side. recordInjectionFlag (src/memory/peer-reputation.ts:145) only stacks critical-severity hits per pubkey across 24h. An attacker splitting a payload into five low/medium-severity fragments from the same author never accumulates anywhere because low/medium only adjust the trust edge per-envelope. I'll file this as its own issue rather than tucking it inside Phase B since session-window risk accumulation across envelopes is a different design call.

On the corpus port: yes, PR welcome against src/security/skill-injection-scanner.test.ts. If each ported fixture has a one-line comment pointing back to its McpVanguard source file we keep clean provenance on both sides, which helps when either of us updates a payload class.

One question if you're up for it: are your L2 semantic-scorer prompts public? core/semantic.py shows the decision shape but the actual scoring prompt body isn't obvious from the file tree. No pressure if it's intentionally closed; the test corpus alone is high value.

[bulltickr]

yes, the prompt is fully public and MIT licensed. We are building in public. It lives in core/semantic.py under the _SYSTEM_PROMPT variable (around line 50).

We don't abstract it behind a config because the exact wording is critical to the defense. The short version of our design:

4 named attack classes baked directly into the prompt: PERSONA OBFUSCATION, CREDENTIAL HUNTING, FRAGMENTATION, JAILBREAK INSTRUCTIONS.
Explicit score bands per severity (0.0–0.2 benign → 0.9–1.0 critical).
Default posture: "when in doubt, score HIGHER (0.8+)".
We found that generic "is this malicious?" prompts produce too many ambiguous 0.5 warnings on sophisticated attacks. Naming the attack classes explicitly in the system prompt moves borderline cases to 0.85+ blocks reliably.

On the corpus: I have the PR drafted locally. As expected, your Phase A regex catches the basics but currently returns ok or medium for our advanced persona obfuscation and fragmentation payloads. I'm going to run a few more tests on it tonight and then push the PR up or i can help you thru discord if you like.

[VGIL77]

Push it up. Phase A was always meant to be the cheap layer; if your advanced obfuscation and fragmentation payloads come back as ok or medium, that's exactly the signal Phase B and C need to be sized against. A failing test corpus committed alongside the regex is more durable than a Discord exchange, and gives the next phases something concrete to measure against rather than my own intuitions.

Happy to do nuance on Discord after, but the PR is the artifact that compounds. Drop it whenever it's ready.