# YAML Include Directive Resolved To Sensitive File Read

- **Severity:** High
- **Signature ID:** `7c1e4a92-3b6d-4f18-9c05-2a8f6d51b4e7`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM04 (Data and Model Poisoning)

## Summary

Some AI agent tools parse YAML configuration that can contain special directives like !include or unsafe object-construction tags. This rule catches cases where such a directive in YAML text actually caused the agent to open a sensitive file or launch a shell/interpreter, not just cases where the YAML text merely contains the directive.

## How the attack works

An attacker plants YAML content, reachable by the agent, containing an !include/!import/!env_file/!ref directive pointing at a sensitive path, or an unsafe deserialization tag like !!python/object/apply. The agent's YAML loader honours the directive, either resolving the include path and reading that file, or executing arbitrary code during deserialization. The detection confirms this by matching the exact file path named in the YAML against a real file read performed by the agent process (or a process it spawned) within a five-minute window, or, for the code-execution style tags, by seeing a shell/interpreter subprocess start in that same window. This linkage between the directive and the follow-on action is what separates a real exploitation chain from an agent just reading its normal config files.

## Why it matters

An attacker who can inject YAML into an agent's input can potentially get it to read credentials, tokens, or other secret files, or to execute arbitrary code, using ordinary configuration parsing as the delivery mechanism.

## What you can do

- Disable or restrict custom YAML constructors (!include, !import, !env_file, !ref) in any loader an agent uses to parse untrusted input; use safe_load without custom tags where possible.
- Never allow YAML from external or tool-result content to be parsed with a loader that supports Python/Ruby object construction tags.
- Restrict which file paths an agent process can read, especially credential and secrets directories, regardless of what a config file requests.
- When triaging alerts, check whether the reason given is an exact-target file match or just a time-window correlation with an unrelated sensitive read, since the latter is more likely a false positive.

## Known benign look-alikes

- Home-Assistant / Ansible / Helm style multi-document configs that legitimately use a custom !include loader pointing at a dotfile directory under the user's home (e.g. !include /home/dev/.config/app/sensors.yaml). The declared target is read on disk, so both stages are satisfied. Reported, never blocked.
- Kubernetes or cloud tooling that legitimately reads ~/.kube/config or /var/run/secrets/... in the same five-minute window as a YAML manifest that contains include directives - the sensitive-read fallback stage will corroborate even though the two are unrelated. The reason string states which stage matched so triage can separate exact-target confirmation from window correlation.
- Security research, CVE write-ups, PyYAML hardening documentation or CTF notes pasted into a tool result that contain !!python/object/apply payload examples, while the agent independently spawns python/bash for unrelated work.
- Secret-scanning, backup or SBOM agents whose job is to read .env and credential files while also processing YAML manifests.

## References

- https://atlas.mitre.org/techniques/AML.T0051
- https://owasp.org/www-project-top-10-for-large-language-model-applications/
- https://attack.mitre.org/techniques/T1552/001/

---
Source: https://www.netzilo.com/threats/yaml-include-file-inclusion-chain