An AI agent's configuration file is often the richest credential store on a developer's laptop: one file can hold the keys for every tool, MCP server and model provider the agent uses. MITRE ATLAS tracks the theft of those keys as AML.T0083 Credentials from AI Agent Configuration, in the Credential Access tactic (AML.TA0013). ATLAS notes that although secret managers and encrypted vaults exist, API keys, tokens and connection strings are often placed in less protected locations for convenience. The Runtime Secrets Injection for AI Agents Without Prompt Exposure guide covers how to design secrets out of the agent; this page covers the technique itself: which files are targeted, how attackers reach them, how to detect access, and how to respond when a configuration file has been read. It is for endpoint, platform and SOC teams supporting developers and agent users.
Key takeaways
- The file is the target, not the model. AML.T0083 is about reading credentials stored for the agent's tools, which then give access to systems outside the agent.
- The agent can be turned against its own file. In ATLAS case studies AML.CS0045 and AML.CS0054, injected instructions made the agent read its own MCP configuration and send it out.
- Exposed control panels show the file directly. In AML.CS0048 a researcher found model provider keys, bot tokens and OAuth credentials in plaintext in exposed agent dashboards.
- References beat values. A configuration that points to a secret manager or a credential helper leaves nothing worth stealing in the file.
- Treat a read as a leak. If an untrusted process or prompt could have read the file, rotate every credential in it, not only the one you think was used.
How the technique works
ATLAS created AML.T0083 in September 2025 and rates it as demonstrated. It is the AI-specific cousin of ATT&CK T1552.001 Credentials In Files and of ATLAS AML.T0055 Unsecured Credentials, narrowed to configuration the agent itself uses. There are three common routes to the file.
| Route | ATLAS example | What the attacker needs |
|---|---|---|
| Agent tricked into reading its own configuration | AML.CS0045: a web page scraped through an MCP tool told the agent to find and send its MCP configuration and model API key | Content the agent will read |
| Poisoned tool description | AML.CS0054: a tool description told the agent to read mcp.json and pass it as a tool parameter | A tool the user installs |
| Exposed agent control interface | AML.CS0048: credentials in an agent's configuration file were visible through internet-exposed dashboards | Network access to the interface |
| Malware or malicious extension on the host | The ClawHub malicious skills campaign included a skill that read an agent's .env file | Code running as the user |
What sits in agent configuration
| Configuration item | Typical credential | What it unlocks |
|---|---|---|
MCP client configuration (for example mcp.json) | API keys and tokens in server env blocks or headers | Every tool the agent connects to: code hosts, databases, ticketing, cloud |
| Agent application settings file | Model provider keys, chat platform bot tokens, OAuth credentials | Model spend, messaging channels, user data |
.env files in agent and project folders | Provider keys, database connection strings, cloud keys | Back-end systems and cloud accounts |
| Agent framework or workflow definitions | Connection objects with embedded secrets | Integrated SaaS and internal APIs |
| Process environment of the agent | Everything exported to the shell that started it | Whatever the user can reach; see AML.T0098 below |
The configuration file guide for coding assistants and the Local MCP Server Security Guide cover file locations for specific tools. Plan for the general case: any file the agent reads at start-up may hold secrets.
Detection
| Data source | What to look for |
|---|---|
| Endpoint file access events | Reads of agent configuration and .env files by processes other than the agent itself, or by shells the agent started |
| Agent tool call logs (AML.M0024) | File read tools pointed at configuration paths; tool parameters containing key-shaped strings |
| Command history the agent ran | Commands that search for credential files or print the environment, followed by an outbound request |
| Provider and SaaS audit logs | Use of a key from a new network, user agent or region; spikes in model usage |
| Internet exposure scans | Agent dashboards or gateways reachable from the internet |
| Secret scanning | Agent configuration files committed to repositories or baked into images |
D3FEND D3-FA File Analysis supports scanning configuration for embedded secrets, and D3-UBA User Behavior Analysis supports spotting a key used from an unexpected place. A canary token placed in agent configuration is a cheap tripwire; see AI Agent Honeytokens and Canaries.
Measuring it
- Plaintext count: number of literal secrets found in agent configuration across managed endpoints (target falling to zero).
- Reference rate: share of agent tool credentials loaded from a secret manager or credential helper.
- Exposure: agent control interfaces reachable from the internet (target zero).
- Credential age: median age of keys in agent configuration.
- Rotation time: time from suspected file read to every credential in the file rotated.
Prevention and hardening
ATLAS does not link a mitigation directly to AML.T0083 in the release we checked (2026.09). The controls below are NHI Mgmt Group recommendations, mapped to related ATLAS mitigations.
- Store references, not secrets: have configuration point to a secret manager, OS keychain or credential helper so the file holds no usable value. The runtime secrets injection guide describes tool-layer and proxy patterns.
- Short-lived, scoped credentials: where a value must exist locally, use per-tool tokens with narrow scope and short lifetime, issued per user. ATLAS AML.M0027 Single-User AI Agent Permissions Configuration asks for delegated, least-privilege access.
- Block reads of credential paths: deny the agent's file and shell tools access to its own configuration directory and to
.env, SSH and cloud credential paths, using tool allowlists or sandbox mounts (AML.M0032 Segmentation of AI Agent Components). - Confirm before sensitive actions: AML.M0029 Human In-the-Loop and AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data stop a scraped page from triggering a file read and an outbound call without a person seeing it. Show full tool arguments in confirmations (NHI Mgmt Group recommendation).
- Close control interfaces: require authentication on agent dashboards, bind them to localhost or a private network, and never display stored secrets in a user interface.
- Restrict file permissions: configuration files readable only by the user, excluded from sync folders, backups shared with others and container images.
Implementation
- Discover: scan managed endpoints and images for known agent configuration paths and
.envfiles, and count literal secrets. - Prioritise: start with credentials that reach production, cloud administration or customer data.
- Migrate: move each credential to a secret manager or credential helper, replacing the value with a reference; rotate the old value as you go, since it may already be copied.
- Restrict: add tool and sandbox rules that block agent access to credential paths, in audit mode first to find breakage.
- Monitor: add file access and key-use detections, and place canaries.
- Roll back: keep the previous configuration available for a short window if a tool fails, but never by restoring the old secret value.
Where identity fits
Every credential in agent configuration is a non-human identity, usually with no owner, no expiry and far more scope than the agent needs. The fix is identity work: give each tool connection its own credential, tie it to the human or service it acts for, set an expiry, and record it in your inventory so it can be rotated in one place. See the AI Agent Credential Lifecycle and Rotation Guide and the OWASP Agentic Top 10 ASI03 Guide.
Response
- Assume every value is exposed: list every credential in the configuration file and in the agent's environment at the time.
- Revoke and rotate: start with the highest-privilege credentials; revoke rather than wait for expiry.
- Hunt for use: check each provider's audit logs for use from new networks since the earliest possible read.
- Find the route: establish whether the read came from an injected prompt, a tool, an exposed interface or malware, and close it.
- Clean up: replace values with references so the next read finds nothing. For model provider keys, follow the LLMjacking Response Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0083 (AML.TA0013); related AML.T0055, AML.T0098 | Technique and related credential access |
| MITRE ATLAS mitigations | AML.M0024, AML.M0027, AML.M0029, AML.M0030, AML.M0032 | Telemetry, delegated access, approvals, tool restriction, segmentation |
| MITRE ATT&CK | T1552.001 Credentials In Files | Equivalent enterprise technique |
| NIST SP 800-53 Rev. 5 | IA-5, SC-28, AC-6, SI-4 | Authenticator management, protection at rest, least privilege, monitoring |
| NIST CSF 2.0 | PR.AA-05, PR.DS-01, DE.CM-09 | Access policy, data at rest, runtime monitoring |
| MITRE D3FEND | D3-FA, D3-UBA, D3-CR | File analysis, behaviour analytics, credential revocation |
Common failure patterns
- One file, every key: a single MCP configuration holding long-lived tokens for code hosting, cloud and ticketing.
- Agent can read its own secrets: file and shell tools with no path restrictions.
- Rotating one key: rotating the key that was abused and leaving the rest of the file's credentials live.
- Dashboards on the internet: self-hosted agent interfaces exposed without authentication, showing stored credentials.
- Configuration in images and repositories: agent settings copied into containers or committed with their secrets.
Practitioner checklist
- Scan endpoints and images for agent configuration files with literal secrets.
- Replace stored values with references to a secret manager or credential helper.
- Issue scoped, short-lived, per-user credentials for each tool connection.
- Block agent tools from reading configuration,
.env, SSH and cloud credential paths. - Require confirmation with full arguments for file reads followed by outbound calls.
- Authenticate agent dashboards and keep them off the internet.
- Alert on configuration file reads by unexpected processes and on key use from new locations.
- On suspected read, rotate every credential in the file.
Standards and references
- MITRE ATLAS: Credentials from AI Agent Configuration
- MITRE ATLAS: Data Exfiltration via an MCP Server used by Cursor
- MITRE ATLAS: Exposed ClawdBot Control Interfaces
- MITRE ATLAS: Data Exfiltration via Remote Poisoned MCP Tool
- MITRE ATT&CK: T1552.001 Credentials In Files
Related NHI Mgmt Group resources: Runtime Secrets Injection for AI Agents Without Prompt Exposure · Agent Skills Security Guide · Local MCP Server Security Guide · MITRE ATLAS Guide