# Agent Self-Modifying Its Own Trust/Approval Configuration to a Wildcard

- **Severity:** High
- **Signature ID:** `185be3cd-1162-4aad-a9f2-056d621e1995`
- **MITRE ATLAS:** AML.T0053 (AI Agent Tool Invocation)
- **OWASP:** ASI10 (Resource Exhaustion and Denial of Wallet), LLM06 (Excessive Agency)

## Summary

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.

## 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

## References

- https://agentthreatrule.org/en/rules/ATR-2026-02192
- https://aws.amazon.com/security/security-bulletins/rss/aws-2025-019/
- https://embracethered.com/blog/posts/2025/aws-kiro-aribtrary-command-execution-with-indirect-prompt-injection/

---
Source: https://www.netzilo.com/threats/atr-agent-self-modifying-its-own-trust-approval-configuration-to