An agent can only be investigated if someone can see what it did. So what happens when the agent can reach the switches for its own monitoring?
In one customer finding, an agent read local telemetry policy files, ran a script with a session-hook removal argument and edited its agent settings. The finding also recorded a background shell loop and a JSON validation command.
A configuration file is part of the security boundary
Hooks can record activity or apply checks around agent actions. If an agent can change the configuration that installs or invokes those hooks, the monitoring system and the system being monitored share an owner.
Think of a security camera whose power switch is inside the room it watches. The camera may work perfectly until the person in the room can reach that switch. An agent setting is not automatically unsafe to edit, but settings that control security coverage deserve a different protection level from ordinary preferences.
What the team should verify
Start with the before-and-after configuration, not the finding title. Identify the exact hook entries, file owner and effective permissions. Then compare a known-good configuration with what the runtime actually loads. Check command results and the supervisor or endpoint logs to establish whether monitoring stopped.
When telemetry is missing, preserve the gap in the incident record and check sensor health, process execution and configuration changes.
Keep the observer outside the workspace
Protect security hook configuration with an identity the agent cannot modify. Monitor changes from a separate process or platform, and alert when expected hooks disappear. Test both startup and mid-session changes: a control that returns on restart can still leave a running session unobserved.
Provide a supported path for reporting a broken hook. If the only way to finish work is to remove the monitoring process, an operational problem has become a security decision. That decision belongs with the owner of the control, not with the process being watched.