An agent connected to email, chat, document stores and code repositories can search all of them for passwords and keys faster than any human attacker, and it does so with the user's own access. MITRE ATLAS tracks this as AML.T0098 AI Agent Tool Credential Harvesting, in the Credential Access tactic (AML.TA0013): adversaries use their access to an agent to retrieve credentials from the sources its tools reach, which ATLAS lists as document stores such as SharePoint, OneDrive or Google Drive, code repositories such as GitHub or GitLab, email and Slack, and local note-taking tools such as Obsidian or Apple Notes. The sibling technique, credentials stored in the agent's own configuration, is ATLAS AML.T0083 Credentials from AI Agent Configuration; for keeping secrets out of agents see Runtime Secrets Injection for AI Agents Without Prompt Exposure. This page covers the connected data the agent can search, how to reduce what it finds, and how to detect and respond. It is for teams rolling out connected assistants and the SOC teams who monitor them.
Key takeaways
- Connectors turn old leaks into new risk. Passwords pasted into chats, notes and documents years ago become searchable the day an agent is connected.
- The agent's search is the attacker's search. AML.T0098 needs no exploit, only an instruction to the agent to look for credentials in the places it can reach.
- The shell is a tool too. In ATLAS case study AML.CS0048, a researcher asked an exposed agent to print its environment, and its bash skill returned secrets for other services.
- ATLAS links segmentation. AML.M0032 Segmentation of AI Agent Components is the mitigation ATLAS maps to this technique; least-privilege connectors and secret clean-up do most of the rest.
- Harvesting usually precedes exfiltration. In AML.CS0054 the harvested file went straight out through a tool parameter, which is AML.T0086.
How the technique works
ATLAS created AML.T0098 in November 2025 and rates it as demonstrated. The attacker first needs a way to direct the agent: a prompt injection (AML.T0051) in content the agent reads, a poisoned tool (AML.T0110), or direct access to an exposed agent interface. The agent then uses its normal search and read tools to collect secrets.
| Source reached through agent tools | Credentials commonly found there | Clean-up owner |
|---|---|---|
| Document stores (SharePoint, OneDrive, Google Drive) | Runbooks with passwords, spreadsheets of service accounts, exported key files | Content owners with security support |
| Code repositories (GitHub, GitLab) | Hard-coded keys, .env files, keys in history and in issues | Engineering, via secret scanning |
| Onboarding mails with temporary passwords, vendor API keys, reset links | Users and messaging admins | |
| Chat (Slack and similar) | Tokens and passwords shared in channels or direct messages | Workspace admins |
| Local notes (Obsidian, Apple Notes) | Personal credential lists, recovery codes | Users, guided by policy |
| Agent shell or code execution tool | Environment variables, credential files on the host | Platform team |
Where it shows up
- Exposed self-hosted agents: AML.CS0048 (January 2026) records a researcher who found hundreds of internet-exposed agent control interfaces, some without authentication, and prompted one to run
envthrough its bash skill, revealing secrets for other services. - Poisoned tools: in AML.CS0054 (research exercise, 2025), a tool description told the agent to read
mcp.json, which often holds credentials for other MCP servers. The researchers also showed the agent reading the user's SSH private key. - Connected enterprise assistants: any assistant with search over mail, files and chat applies the user's full access; an injected instruction in one email can direct a search across all of it.
- Malicious skills: the ClawHub malicious skills campaign targeted SSH keys, browser passwords, cloud credentials and the agent's stored credentials, showing how add-ons can harvest through the agent's reach.
Prevention and hardening
- AML.M0032 Segmentation of AI Agent Components: put boundaries around tools and data sources, run code execution in sandboxes built from a clean image with limited network access, and rate-limit tool invocation. A sandboxed shell with no host credentials returns nothing useful to
env. - Least-privilege connectors: scope each connector to the sites, mailboxes, channels and repositories the use case needs, not the user's whole estate. ATLAS AML.M0027 asks for delegated access and least privilege for agents acting for a user.
- Clean the sources: run secret scanning on repositories, and discovery for credentials in document stores, mail and chat, before connecting an agent; rotate what you find rather than only deleting it. See Git Secret Scanning Guide.
- Keep credentials out of agent-searchable stores: give users and teams a password manager or secret manager and a policy that credentials never go into chat, notes or documents.
- Restrict tools after untrusted input: AML.M0030 limits search and read tools once untrusted content is in context, so an injected email cannot start a credential search.
- Filter outputs: AML.M0033 Input and Output Validation can mask credential patterns in tool results before they reach the model or leave in a tool call.
Decision guidance
| Situation | Priority control (our recommendation) |
|---|---|
| Enterprise assistant with mail, file and chat search | Credential discovery and clean-up across those sources first, then scoped connectors |
| Coding agent with shell access | Sandbox with no host credentials in the environment; credential helpers instead of exported keys |
| Self-hosted personal agent | Authenticated interface on a private network, sandboxed skills, no secrets in the host environment |
| Agent that reads external content (mail, tickets, web) | Restrict search tools after untrusted content, and require approval for bulk searches |
| Small organisation without discovery tooling | Start with repository secret scanning and a ban on credentials in chat, then add sources |
Detection
| Data source | What to look for |
|---|---|
| Agent tool call logs (AML.M0024) | Search queries for terms such as password, token, API key, secret or private key; many reads across unrelated sources in one turn |
| Document store and mail audit logs | Agent identity or delegated session opening files and messages the user has never accessed |
| Agent shell history | Commands that print the environment or read credential files |
| Canary credentials | Use of decoy keys placed in documents, notes and repositories |
| Provider and cloud audit logs | First use of a credential from a new location soon after agent search activity |
D3FEND D3-UBA User Behavior Analysis fits the search pattern, since the agent acts as the user. Decoy credentials are especially effective here because a harvesting agent reads indiscriminately; see AI Agent Honeytokens and Canaries.
Measuring it
- Secrets in reach: live credentials found in sources connected to agents (target falling to zero).
- Connector scope: share of connectors limited to named sites, channels or repositories rather than all.
- Sandboxed execution: share of agents whose shell or code tool runs in a sandbox without host credentials.
- Canary coverage and trips: number of sources seeded with decoys, and any use of them.
- Time to rotate: time from discovering a credential in a connected source to rotation.
Implementation
- Map reach: for each agent, list every source its tools can search or read, and with which identity.
- Discover and rotate: scan those sources for credentials and rotate, starting with production and cloud admin access.
- Scope connectors: reduce each connector to what the use case needs; pilot with one team before the estate.
- Sandbox tools: move shell and code execution into sandboxes without host credentials.
- Seed canaries and monitor: place decoys and add search-pattern detections, in alert-only mode at first.
- Roll back: keep previous connector scopes documented so a team blocked by a change can be restored quickly while the scope is corrected.
Where identity fits
AML.T0098 turns a human's accumulated access into an attacker's search scope. Two identity controls cut it down: connectors that act with delegated, scoped access rather than the user's full rights, and a programme that keeps non-human credentials in vaults where they have owners and expiry, rather than in mail and chat. Every credential the agent finds is an unmanaged non-human identity. See the Agent Identity and Access Guide and the OWASP Agentic Top 10 ASI03 Guide.
Response
- Contain the agent: suspend the agent or its connectors and revoke its delegated sessions.
- List what it read: from tool logs and source audit logs, list every document, message and file read during the suspect window.
- Rotate every credential found there: treat each as exposed, whether or not you can prove it left.
- Check for exfiltration: review write tool calls in the same window, as AML.T0086 usually follows.
- Close the trigger and clean the source: remove the injected content or tool, and delete credentials from the source after rotation. See the AI Agent Incident Response Playbook.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0098 (AML.TA0013); related AML.T0083, AML.T0055; often followed by AML.T0086 | Technique and neighbours |
| MITRE ATLAS mitigations | AML.M0032 (linked by ATLAS); AML.M0027, AML.M0030, AML.M0033, AML.M0024 | Segmentation, delegated access, tool restriction, validation, telemetry |
| MITRE ATT&CK | T1552 Unsecured Credentials | Equivalent enterprise technique |
| NIST SP 800-53 Rev. 5 | AC-6, IA-5, SI-4, AU-12 | Least privilege, authenticator management, monitoring, logging |
| NIST CSF 2.0 | PR.AA-05, DE.CM-09, RS.MI-01 | Access policy, monitoring, containment |
| MITRE D3FEND | D3-UBA, D3-CR | Behaviour analytics, credential revocation |
Common failure patterns
- Connecting first, cleaning later: agents connected to mail and file stores full of old credentials.
- Whole-tenant connectors: search across every site and channel because scoping was harder.
- Host environment in the sandbox: shell tools that inherit the user's exported cloud and API keys.
- Deleting without rotating: removing a pasted password from a document but leaving it valid.
- Ignoring personal notes: local note tools connected to assistants with no policy on what they hold.
Practitioner checklist
- Map every source each agent can search, and with which identity.
- Scan connected sources for credentials and rotate what you find before go-live.
- Scope connectors to named sites, mailboxes, channels and repositories.
- Run shell and code tools in sandboxes with no host credentials.
- Restrict search tools after untrusted content enters context.
- Mask credential patterns in tool output.
- Seed canary credentials in connected sources and alert on use.
- On suspicion, rotate everything the agent read, then check for exfiltration.
Standards and references
- MITRE ATLAS: AI Agent Tool Credential Harvesting
- MITRE ATLAS: Segmentation of AI Agent Components
- MITRE ATLAS: Exposed ClawdBot Control Interfaces
- MITRE ATLAS: Data Exfiltration via Remote Poisoned MCP Tool
- MITRE ATT&CK: T1552 Unsecured Credentials
Related NHI Mgmt Group resources: MITRE ATLAS Guide · Agent Threats and Attacks Guide · Agent Egress Control and Network Isolation Guide · Runtime Secrets Injection for AI Agents Without Prompt Exposure