Natural-Language Sensitive File Disclosure Instruction
This detects text sent to an AI agent that directly instructs it to open and reveal the contents of files known to hold secrets, like SSH private keys, cloud credentials, or password files. The trigger is a command verb paired with a specific sensitive path, not just a passing mention of the file.
How the attack works
An attacker sends the agent a natural-language message containing an imperative verb — read, cat, output, include, append, attach, disclose, or reveal — combined with the path to a known sensitive file such as /etc/passwd, /etc/shadow, ~/.ssh/id_rsa, ~/.aws/credentials, .env, or a kubeconfig file. If the agent has file access and complies, it prints or forwards the contents of that file back through its response. This lets the attacker extract credentials, keys, or system account data without needing separate file-system access of their own.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- ebb9eec0-847b-4239-a900-42ade698c501
- Severity
- Critical
Why it matters
If the agent has read access to the file system and follows the instruction, an attacker can extract SSH keys, cloud credentials, or account data through the AI's own responses, bypassing normal file access controls.
What you can do
- →Restrict the file-system paths and directories an AI agent is allowed to read, especially home directories, credential stores, and system config files.
- →Treat any agent output that reproduces file contents matching sensitive paths as a signal requiring review, even if the request looked like a normal user query.
- →Separate the agent's execution identity from accounts that hold real credentials, so a compromised or manipulated agent cannot reach secrets at all.
- →Review agent logs for prompts combining directive verbs (read/cat/output/attach) with known sensitive paths, since this pattern rarely appears in legitimate use.
Known benign look-alikes
- Security guides explaining file permissions on /etc/passwd and /etc/shadow
- Documentation describing where SSH keys are stored
- Threat intel write-ups discussing this exact pattern
- Setup docs telling users where to place their .env file