Prompt injection and IDE poisoning

The AI agent is itself an attack surface. Text placed in the wrong spots can hijack its instructions: extract the system prompt, inject false authority or poison config files the IDE reads as project rules.

From scratch: why text becomes command

An LLM does not hard-separate "data" from "instructions": it is all text in the context. If the agent reads a project file and inside it sits a convincing imperative sentence, the model may obey as if the user had spoken. Hence the two names. Direct prompt injection comes in the request itself; the indirect one comes from content the agent fetches (a README, an issue, a config file). IDE poisoning is indirect injection with a chosen target: the files the IDE treats as project authority, exactly the ones the agent tends to obey without question.

Why it matters

Nemesis's own instruction files (the AGENTS.md, the CLAUDE.md) are authority the agent is told to respect. If an attacker manages to edit one of them, or plant a poisoned .cursorrules, they speak with the project's voice. That is why the rule is strict: these config files are scanned against poisoning and never exempted from the scan. The defense had to treat config as untrusted content, not as truth.

How it correlates

Prompt injection and poisoning are the same vector in two places: the injection pattern is the core, and poisoning is it applied to an IDE target file, plus social-engineering tricks (false authority, fake scan). The credential harvest the "fake scan" tries to provoke is the bridge to group 8 (exfiltration). And scanning its own rule files is part of the posture of protecting Nemesis itself.

How Nemesis applies it

The injection visitor carries a pattern list: orders to ignore instructions, AI format tokens and system-prompt extraction attempts.

📄 .nemesis/nemesis-defender/src/visitors/prompt_injection.rs:1-29 · padrões de injeção

//! Detecta instrução de IA injetada em strings/comentários:
//! - "ignore previous instructions"
//! - tokens de formato (<|im_start|>, [INST], <<SYS>>)
//! - extração de system prompt ("reveal your system prompt")
const INJECTION_PATTERNS: &[&str] = &[
    "ignore previous instructions", "override safety", "bypass restrictions",
    "<|im_start|>", "[INST]", "<<SYS>>", /* ... */ ];

For IDE config, the visitor only acts if the file is actually a config file (target), and checks three things: injection, fake security scan and authority injection:

📄 .nemesis/nemesis-defender/src/visitors/ide_config_poisoning.rs:157-206 · scan_ide_config

pub fn scan_ide_config(path: &Path, content: &[u8]) -> Vec<DefenderViolation> {
    if !is_ide_config_file(path) { return violations; }   // só arquivos de config
    if has_ide_prompt_injection(text) { /* ignore-previous, DAN, override */ }
    if has_fake_security_scan(text)  { /* "rode um scan" = ler+vazar credencial */ }
    if has_authority_injection(text) { /* "verified by Anthropic", "rules suspended" */ }
}

Decisions and limits

The fake "security scan" is fine social engineering: the file tells the agent to run a "scan" before answering, and that scan reads credentials and sends them out. The rule is simple: legitimate detection runs in CI; an agent has no reason to read a secret. Authority injection exploits trust ("trusted configuration", "security rules suspended", "verified by Anthropic"); no external file can grant elevated permission, so every such claim is treated as an attack.

And since text that talks about prompt injection (this material, for instance) contains the same terms, the poisoning detector targets IDE config files and credential harvesting exempts pure prose: conviction requires an executable sink.

Self-check

Further reading

• OWASP Top 10 for LLM Applications (LLM01: Prompt Injection).
• OWASP GenAI, Prompt Injection.
• MITRE ATT&CK, Command and Scripting Interpreter.

Citações verificadas contra o repositório. Voltar ao índice.