Sensitive System File Read (EDR Graph)

How the attack works

An AI agent, or a shell/process it has spawned, opens and reads a file that holds account or authentication data — examples include /etc/passwd, sudoers files, or SSH authorized_keys. The rule reviews the behaviour graph after the fact, looking specifically at file-read activity tied to that agent or its subprocesses. It exists because the live detection path only inspects process-execution events for subprocesses, not the files those subprocesses read, leaving a blind spot that this periodic scan fills. The attacker's goal in reading these files is typically reconnaissance: mapping local accounts, checking for privilege escalation paths, or finding SSH keys to reuse.

Netzilo detection

Why it matters

An attacker or compromised agent can enumerate user accounts, sudo privileges, and SSH key material without triggering any real-time alert, since the only detection path for this activity runs periodically rather than live.

What you can do

• →Restrict which files an AI agent's runtime and any spawned subprocesses can read, using OS-level file permissions or sandboxing.
• →Treat reads of /etc/passwd, sudoers, or authorized_keys by automation as sensitive and review them even when done by known tools.
• →Add live monitoring of file-read events for spawned subprocesses, not just their execution, to close the detection gap this rule works around.
• →Maintain a list of agents and jobs that legitimately need to read these files on a schedule, so real anomalies stand out during review.

Known benign look-alikes

• Configuration-management agents reading account state on a schedule
• Login and session tooling consulting /etc/passwd as designed — a monitored agent that spawns a shell will show that shell's own passwd lookups here
• Compliance scanners auditing sudoers or authorized_keys

Related threats