Threat dossier · P2
Workspace and instruction-file poisoning
Instruction files can persist in a repository and silently affect many future tasks without appearing in the user prompt.
Direct answer
What is workspace and instruction-file poisoning?
Workspace instruction poisoning places hostile or misleading natural-language policy inside files an agent automatically treats as project guidance.
Coverage statements below are limited to the current HOL Guard support contract and do not imply universal model or harness protection.
Representative attack path
Defensive model only. This sequence omits weaponized payloads and is not attributed to a specific incident unless a source explicitly says so.
Step 1
Attacker changes an instruction/configuration file.
Step 2
Agent loads it automatically or by convention.
Step 3
Repository-controlled text is treated as authority.
Step 4
Future tool/file/command behavior changes.
Coverage boundary
What this control can cover
- Supported inspection of instruction-bearing artifacts where available.
- Guard-visible downstream actions remain subject to runtime policy.
What it does not prove or prevent
- A guarantee that every instruction file is detected or semantically classified.
- Model-internal reasoning before a Guard-visible action.
Policy pattern
Policy pattern for workspace and instruction-file poisoning
Keep untrusted context or overbroad autonomy from becoming unconditional execution authority on supported action surfaces.
Use when: Instruction files can persist in a repository and silently affect many future tasks without appearing in the user prompt.
Decision pattern
- Identify the trust boundary and consequential action class.
- Apply least privilege and the narrowest supported policy.
- Require review for sensitive or ambiguous actions.
- Preserve only redacted, versioned evidence needed to reproduce the decision.
Limitations
- A guarantee that every instruction file is detected or semantically classified.
- Model-internal reasoning before a Guard-visible action.
If you suspect prompt injection
Step 1
Response 1
Review repository/config diffs and ownership.
Step 2
Response 2
Restore verified instruction files.
Step 3
Response 3
Treat external/repository instructions as untrusted context.
Step 4
Response 4
Retest sensitive actions after cleanup.