Agent Self-Modifying Its Own Trust/Approval Configuration to a Wildcard
An AI coding assistant can be manipulated into editing its own configuration file to remove the requirement that a human approve its actions. Once changed, the agent can run any future command without asking permission again.
How the attack works
An attacker hides instructions inside content the agent will read, such as source code or project files in a workspace. When the agent processes that content, the hidden instructions tell it to modify its own IDE or agent configuration file. Specifically, it sets a trusted-commands or auto-approve setting to a wildcard (like '*' or true), turns off a require-approval or require-confirmation flag, or switches an autonomy setting to 'full'. This is not a one-time bypass of a single confirmation prompt -- it rewrites the standing configuration, so every command the agent runs afterward, in that workspace, executes without any human check.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 185be3cd-1162-4aad-a9f2-056d621e1995
- Severity
- High
Why it matters
An organization loses the human checkpoint meant to catch dangerous or unintended agent actions. Once trust is set to wildcard, any later prompt injection or attacker-controlled content in that workspace can trigger arbitrary command execution with no approval step in the way.
What you can do
- →Review agent and IDE configuration files (e.g. .vscode/settings.json, autonomy/trust settings) for wildcard trust entries or disabled approval flags you did not set yourself.
- →Treat any agent-initiated write to its own trust, approval, or autonomy configuration as a high-priority event requiring manual review, even if the agent claims a user requested it.
- →Keep confirmation gates and command trust lists outside the agent's own write access where possible, or require a separate human action to change them.
- →Audit workspaces that ingest external or third-party source code for injected instructions before letting an agent operate on them autonomously.
Known benign look-alikes
- A user explicitly and knowingly reconfiguring their own agent's trust settings in a direct, first-person request -- legitimate but rare; the persistence and severity of a blanket-trust grant still warrants a human check
- A rule/config *documentation* example (e.g. a README showing the schema of trustedCommands) rather than an actual write instruction
- Reading back the CURRENT value of these keys (e.g. 'what is autoApprove set to?') rather than setting a wildcard/false value
- Turning a safety gate ON in the safe direction -- 'set requireApproval: true' or 'set requireConfirmation: true' (re-enabling human confirmation) -- must not fire
- Turning a risky skip OFF in the safe direction -- 'set skipConfirmation: false' (making sure confirmation is NOT skipped) -- must not fire