An attacker who can edit an agent's configuration does not need to inject a prompt every time: the change does the work on every future run, for every agent that shares the file. MITRE ATLAS tracks this as AML.T0081 Modify AI Agent Configuration, listed under two tactics, Persistence (AML.TA0006) and Defense Evasion (AML.TA0007). ATLAS describes changes to system prompts, knowledge sources and connected tool settings, and also the switching off of safety settings such as human approval for risky actions. Coding assistant rules files have their own page, the Coding Agent Configuration File Attacks guide, so this page covers the wider technique: personal and self-hosted agents, approval and sandbox settings changed through an agent's own API, configuration as a persistence store, and an ATLAS-mapped detection and response runbook. It is for platform teams running agents and the SOC analysts who will investigate them.
Key takeaways
- Configuration is the persistence layer. ATLAS notes that a malicious change survives beyond one agent session and affects every agent that shares the configuration.
- Security settings are the prime target. ATLAS case study AML.CS0050 records a researcher turning off an agent's command approval prompt and its sandbox through the agent's own gateway API.
- Shared files spread the change. In AML.CS0041 a poisoned rules file pulled from a shared source replaced the assistant's configuration and affected all future code generation.
- Integrity monitoring catches most of it. Agent configuration is a small set of known files and settings, so hashing, change control and alerts on security settings are practical and cheap.
- The agent should not be able to rewrite itself. Keep configuration out of the write path of the agent's own runtime identity and its tools.
How the technique works
ATLAS created AML.T0081 in September 2025, last modified it in February 2026, and rates its maturity as demonstrated. It usually follows an entry step such as AML.T0051 LLM Prompt Injection, AML.T0010 AI Supply Chain Compromise or stolen access to the agent's control interface. What makes it a distinct technique is the target: the settings that decide how the agent behaves, rather than a single conversation.
| What is changed | Example from ATLAS | Effect |
|---|---|---|
| System prompt or instruction files | Rules file with hidden instructions (AML.CS0041) | Covert instructions applied to every task |
| Knowledge sources | Technique description: tampering with or replacing knowledge sources | Agent answers from attacker-chosen content |
| Connected tool settings | Technique description: redirecting tools to malicious services | Outputs or tool calls sent to the attacker |
| Approval and sandbox settings | Command approvals turned off and sandbox disabled (AML.CS0050) | Harmful actions run with no human check |
| Agent writes its own future instructions | Injected instructions planted into future system prompts (AML.CS0051) | Agent becomes a command and control implant |
The Defense Evasion tactic matters as much as Persistence. Turning off approvals, logging or the sandbox removes the controls that would otherwise detect or block the next step, which is why ATLAS lists both.
Where it shows up
- Self-hosted personal agents: in AML.CS0050 (February 2026), a security researcher showed that a token stolen through a malicious link let them use the agent's gateway API to turn off the setting that prompts the user before dangerous commands, and to move command execution out of the container onto the host. The fix added a confirmation before the web app connects to a new gateway, and the researchers advised upgrading and rotating any token that may have been exposed.
- Coding assistants: in AML.CS0041 researchers showed rules files carrying instructions hidden with invisible Unicode characters, which stayed invisible in pull request review and affected every later session for the team. The configuration file guide covers this family in depth.
- Repository-supplied agent configuration: a project file that tells an agent which MCP servers to start is configuration supplied by whoever wrote the repository. The Amazon Q MCP config vulnerability shows why: opening a folder could start commands defined in a repository's MCP file, with the developer's credentials in the environment.
- Agents that can edit their own files: AML.CS0051 records HiddenLayer research in which indirect prompt injection caused an agent to plant persistent instructions into its future system prompts.
- Low-code and hosted agent builders: anyone with edit rights to the agent definition can change its instructions, knowledge and connected actions, so builder permissions are configuration permissions.
Detection
ATLAS mitigation AML.M0024 AI Telemetry Logging asks for logs of agent steps, data access, tool use, installation commands and the agent's identity. For this technique add one thing: a record of every configuration change and who made it.
| Data source | What to look for |
|---|---|
| Agent configuration files and instruction files | Hash change outside the deployment pipeline; hidden or bidirectional Unicode characters; new URLs, email addresses or tool endpoints |
| Agent control plane or gateway API logs | Calls that change approval mode, sandbox mode, allowed commands, tool lists or model endpoints, especially from a new client or network |
| Agent builder audit logs | Edits to instructions, knowledge sources or connected actions by users outside the owning team |
| Repository and pull request events | Changes to agent instruction files, MCP server definitions or rule directories without a named reviewer |
| Process and file events on the agent host | The agent process itself writing to its own configuration directory |
| Tool call logs | New tool destinations, or high-risk actions with no approval record after a configuration change |
D3FEND maps the core control to D3-FIM File Integrity Monitoring, with D3-FA File Analysis for scanning instruction files for hidden characters and D3-UBA User Behavior Analysis for unusual control plane sessions. Treat a change that weakens approvals or sandboxing as a high severity alert by default, not a configuration note.
Measuring it
- Coverage: share of agents whose configuration and instruction files are hashed and monitored.
- Out-of-band changes: number of configuration changes detected outside the deployment pipeline per month (target zero).
- Security setting drift: agents running with approvals off or sandbox disabled compared with the approved baseline.
- Review rate: share of changes to instruction and rules files merged with a named reviewer.
- Time to restore: time from detecting an unauthorised change to restoring the known-good configuration.
Prevention and hardening
As of the ATLAS data release we checked (2026.09), ATLAS does not link a mitigation directly to AML.T0081, so the controls below are NHI Mgmt Group recommendations, mapped to related ATLAS mitigations where one applies.
- Read-only configuration: store system prompts, instruction files, tool lists and approval settings where the agent's runtime identity and its tools cannot write them. This is the single most effective control against self-modification (AML.CS0051).
- Configuration as code: manage agent configuration in version control with review, and deploy it through a pipeline. Changes made any other way are drift to alert on.
- Lock security settings: where the platform allows, enforce approval and sandbox settings through managed or administrator policy that a user session or API token cannot override.
- Protect the control plane: treat agent gateway tokens and admin interfaces as privileged credentials: authenticate every interface, bind it to localhost or a private network, check request origin, and keep token lifetimes short. ATLAS mitigation AML.M0026 Privileged AI Agent Permissions Configuration covers least privilege for privileged agents.
- Untrusted repository configuration: do not let an agent start servers or apply instructions from a repository until the workspace is trusted and the file reviewed.
- Scan instruction files: reject hidden and bidirectional Unicode characters in instruction and rules files, and review AI configuration with the same scrutiny as executable code.
- Restrict tools after untrusted input: AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data stops a page or document from causing a configuration write as a side effect. AML.M0032 Segmentation of AI Agent Components keeps a compromised component from reaching configuration it does not own.
Implementation
- Inventory configuration: for each agent, list system prompts, instruction and rules files, tool and MCP server definitions, knowledge sources, approval and sandbox settings, and where each is stored.
- Baseline and hash: record a known-good version of each, with a hash, and store it outside the agent host.
- Monitor in audit mode: alert on changes for two to four weeks without blocking, to find legitimate change paths you did not know about.
- Move changes into the pipeline: route every legitimate change through review and deployment, then remove write access from the agent runtime and from broad user groups.
- Enforce: lock approval and sandbox settings by policy and block start-up when a configuration hash does not match.
- Roll back safely: keep versioned configuration so you can restore the last good version in minutes; test the restore before you need it.
Where identity fits
Configuration changes are authorised actions, so the question is which identities can make them. Three identities matter: the agent's own runtime identity, which should have no write access to its configuration; the tokens that drive the agent's control plane, which carry administrator power and should be short-lived and revocable; and the human builders and repository contributors who can edit instructions. Each should be a named, owned identity, reviewed like any other privileged access. See the Agent Identity and Access Guide and, for the OWASP framing of unexpected changes to agent behaviour, the OWASP Agentic Top 10 ASI10 Guide.
Response
- Contain: stop the affected agent or switch it to read-only operation, and revoke control plane tokens and sessions that could have made the change.
- Compare with the baseline: diff every configuration item against the known-good version, including approval, sandbox, tool and knowledge settings, not only the prompt.
- Find the change path: use control plane, builder, repository and host logs to establish which identity made the change and how it got that access.
- Check every agent that shares it: ATLAS stresses that shared configuration affects all agents using it, so scope by file, template and repository, not just by host.
- Restore and rotate: redeploy the known-good configuration and rotate credentials the agent held while it ran without approvals or sandboxing.
- Review actions taken: examine tool calls and commands run while the change was in place; see the AI Agent Incident Response Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0081 (AML.TA0006, AML.TA0007); entry via AML.T0051, AML.T0010 | Technique and common entry steps |
| MITRE ATLAS mitigations | AML.M0024, AML.M0026, AML.M0030, AML.M0032 | Telemetry, privileged agent permissions, tool restriction, segmentation |
| NIST SP 800-53 Rev. 5 | CM-3, CM-6, SI-7, AC-6, AU-12 | Change control, settings, integrity, least privilege, logging |
| NIST CSF 2.0 | PR.PS-01, DE.CM-09, RS.MI-01 | Configuration management, runtime monitoring, containment |
| MITRE D3FEND | D3-FIM, D3-FA, D3-UBA | Integrity monitoring, file analysis, session analytics |
Common failure patterns
- Agent can edit its own instructions: one injection becomes a permanent change.
- Approvals as a user preference: a safety setting any session or token can turn off with one call.
- Control interface on the network: agent dashboards and gateways reachable without authentication or origin checks.
- Restoring the prompt only: fixing the system prompt but leaving a changed tool endpoint or knowledge source in place.
- Unreviewed shared rules: rules files and templates copied from public collections into many repositories with no review.
Practitioner checklist
- Inventory every configuration item for each agent, including approval and sandbox settings.
- Remove write access to configuration from the agent's runtime identity and tools.
- Manage configuration as code with review, and hash it at start-up.
- Alert at high severity on any change that weakens approvals, sandboxing or logging.
- Authenticate and network-restrict agent control interfaces, with short-lived tokens.
- Scan instruction and rules files for hidden Unicode characters.
- Do not apply repository-supplied agent configuration until the workspace is trusted.
- Rehearse restore from a known-good version.
Standards and references
- MITRE ATLAS: Modify AI Agent Configuration
- MITRE ATLAS: OpenClaw 1-Click Remote Code Execution
- MITRE ATLAS: Rules File Backdoor
- MITRE ATLAS: OpenClaw Command and Control via Prompt Injection
- MITRE ATLAS: AI Telemetry Logging
Related NHI Mgmt Group resources: Coding Agent Configuration File Attacks · OWASP Agentic Top 10 ASI05 Guide · Agent Controls and Monitoring Guide · MITRE ATLAS Guide