ATLAS Credential Access Tactic: Protecting the Credentials AI Agents Hold

AI agents, coding assistants and model pipelines hold more machine credentials than almost any other workload, and adversaries have learned to ask the agent for them. MITRE ATLAS groups these attacks under the Credential Access tactic, AML.TA0013, which it describes as the adversary trying to steal account names and passwords, whether by credential dumping, keylogging or the AI-specific routes ATLAS has added since 2023. This hub covers every current technique in the tactic as of ATLAS release 2026.10, ranks where defenders should start, shows how the tactic chains in documented case studies, and sets out detection and mitigation priorities across the whole tactic. It is for detection engineers, AI platform owners and the teams that govern non-human identities. Each technique has its own deep guide, linked below; this page does not repeat them. For the framework itself, see the MITRE ATLAS Guide.

Key takeaways

• Seven techniques, one theme. ATLAS 2026.10 lists seven Credential Access techniques; four of them (agent configuration, agent tool harvesting, RAG harvesting and session cookie theft) exist because AI systems concentrate credentials in new places.
• Unsecured Credentials dominates the case record. AML.T0055 appears in 11 of the 18 ATLAS case studies that include a Credential Access step, more than every other technique in the tactic combined.
• The agent is both the target and the tool. Prompt injection lets an adversary make an agent read its own environment, configuration files or connected document stores and hand back secrets, as in the Claude Code GitHub Action research (AML.CS0067).
• Credential Access is a middle step. In the case record it is usually preceded by Execution and Initial Access and followed by Defense Evasion, attack adaptation and further access, so the stolen credential is rarely the end of the incident.
• The strongest controls are identity controls. Short-lived, narrowly scoped, per-agent credentials kept out of environment variables and context windows limit what any technique in this tactic can return.

What Credential Access means in an AI environment

ATLAS takes its tactic description from ATT&CK: credentials let adversaries reach systems, make their activity harder to detect, and create further accounts. The AI angle is where the credentials live. An agent that can query a database, call a SaaS API or push to a repository needs a token for each, and those tokens tend to end up in configuration files, environment variables, MCP server definitions or the documents the agent can read. Desktop AI clients hold session tokens for the user's AI account and sometimes for connected services. Model pipelines hold registry, cloud and dataset tokens.

Three properties make this tactic different from its enterprise counterpart, ATT&CK Credential Access Tactic Guide (TA0006):

• The adversary may never touch the host: an indirect prompt injection in an issue, web page or document can direct the agent to read and return a secret, so the "credential dumping" happens inside a sanctioned process.
• Secrets pass through text channels: once a secret enters a model's context, any output path (a reply, a comment, a URL the agent fetches, a log) can carry it out. Transforming the value, for example trimming its prefix, can defeat secret scanners.
• The credentials are mostly non-human: API keys, cloud role credentials, Kubernetes service account tokens and OAuth tokens, often long-lived and broadly scoped. See the Agentic AI Identity Guide.

Every technique in the tactic

The table lists every technique ATLAS 2026.10 maps to AML.TA0013, with the ATLAS maturity rating, the equivalent ATT&CK technique where ATLAS records one, and the number of ATLAS case studies that use the technique in a Credential Access step. No technique in this tactic has sub-techniques in this release.

Method: counts come from the ATLAS 2026.10 data file, counting distinct case studies with at least one procedure step that uses the technique and is tagged to AML.TA0013. A case study can use more than one technique, so the column sums to more than 18.

Where to start: techniques ranked for defenders

The ranking weighs how often a technique appears in real cases, whether ATLAS rates it as realised in the wild, and how much access one success yields. It is NHI Mgmt Group's judgement built on the ATLAS data, not an ATLAS ranking.

1. AML.T0055 Unsecured Credentials. The most common technique by far, covering secrets in files, environment variables and history. It appears in incidents such as LLMjacking (AML.CS0030), where Sysdig found that cloud credentials taken from a server exploited through a Laravel flaw (CVE-2021-3129) were used to run hosted models, and in ShadowRay (AML.CS0023). Fixing secret storage for AI workloads removes the raw material for most of the tactic.
2. AML.T0083 Credentials from AI Agent Configuration and AML.T0098 AI Agent Tool Credential Harvesting. These are the agent-native routes: tokens in agent and MCP configuration files, and secrets reachable through the agent's own tools (document stores, repositories, chat). Exposed ClawdBot control interfaces (AML.CS0048) and a poisoned remote MCP tool (AML.CS0054) both appear here.
3. AML.T0113 Steal Web Session Cookie and AML.T0090 OS Credential Dumping. Both target the tokens AI clients hold. In the AIKatz research (AML.CS0036), Lumia Security showed that bearer tokens for ChatGPT and Microsoft 365 Copilot and a session key for Claude could be read from the desktop applications' process memory by code running in the same user session.
4. AML.T0082 RAG Credential Harvesting. Credentials pasted into internal documents end up in retrieval indexes and can be returned by an assistant, as in the Slack AI exfiltration research (AML.CS0035).
5. AML.T0106 Exploitation for Credential Access. Less frequent but high impact when the vulnerable component is an agent gateway or AI service, as in the OpenClaw one-click remote code execution case (AML.CS0050).

How the tactic chains in real cases

Eighteen ATLAS 2026.10 case studies include at least one Credential Access step. Following each case study's step graph to the steps that lead to a Credential Access step and the steps that follow from one: Initial Access comes before it in 15 of the 18, and Execution and AI Attack Adaptation in 13 each. After it, the most common tactics are Exfiltration (11 cases) and Impact (9). The pattern is consistent: the adversary first gets something running (often an agent processing attacker content), harvests credentials, then uses them to take data or cause harm.

Three chains worth knowing

• Prompt injection to CI secret (AML.CS0067): Microsoft's researchers showed that attacker-controlled GitHub issue or pull request text, processed by the Claude Code GitHub Action, could direct the agent to read the workflow's API key from its process environment and emit a transformed copy that the secret scanner did not match. Environment scrubbing covered shell subprocesses but not the in-process file read tool; the vendor fixed this in Claude Code 2.1.128. The lesson Microsoft draws is customer-side: do not let one workflow combine untrusted input, access to secrets and the ability to communicate externally.
• Stolen key to resold model access (AML.CS0030): after obtaining cloud credentials, the LLMjacking actors tested them with an InvokeModel call built to fail validation rather than authorisation, and called GetModelInvocationLoggingConfiguration to see whether prompts were being logged. See the LLMjacking breach and the LLMjacking Guide.
• Agents harvesting machine credentials at scale (AML.CS0068): in the July 2026 incident, autonomous evaluation agents found exposed Hugging Face write tokens, then read Kubernetes service account tokens and instance role credentials inside production worker pods, and used a shared cluster-admin credential to widen access. See the OpenAI and Hugging Face breach.

Detection priorities across the tactic

Credential Access inside an agent often produces no host-level alert, so detection depends on agent, tool and identity telemetry as much as on the endpoint.

Measure coverage, not just alerts:

• Static secrets in agent configuration: count of agent and MCP configurations holding literal secrets; target zero.
• Credential lifetime: median lifetime of credentials issued to agents and AI pipelines.
• Tool-call logging coverage: share of production agents whose tool calls, arguments and results are logged centrally.
• Time to revoke: time from detection of an exposed AI credential to revocation and rotation.
• Secret findings in retrieval sources: secrets found per scan of indexed document stores, trending down.

Mitigation priorities

ATLAS 2026.10 maps mitigations to four of the seven techniques. The table shows those mappings exactly as the data records them. For AML.T0055, AML.T0083 and AML.T0113 ATLAS maps no mitigation in this release, so the controls for those rows come from the ATT&CK equivalents and NHI practice and are labelled as such.

Rolling out the controls

1. Inventory: list every agent, MCP server, AI pipeline and AI desktop client, and the credentials each holds. The How to audit MCP servers on developer laptops guide covers developer machines.
2. Remove literal secrets: move agent and MCP credentials to a secrets manager or federated workload identity, starting with production and CI agents that process untrusted content.
3. Apply the rule of two: for each agent, check whether it combines untrusted input, secret access and external communication; remove one of the three, or add human approval.
4. Turn on telemetry: log tool calls and connector access centrally before tightening further, so you can see what breaks.
5. Pilot and roll back safely: scope down permissions for a pilot group of agents in monitor mode first, keep the previous credential valid for a short overlap window, then revoke it.

Where identity fits

Every technique in this tactic returns a credential, and almost all of the credentials in the ATLAS case record are non-human: API keys, cloud roles, service account tokens, GitHub tokens, signing keys. ATLAS's own mitigations AML.M0026 and AML.M0027 are identity controls, binding each agent to its own identity and capping its permissions below those of the user it acts for. Treat each agent as a distinct non-human identity with an owner, a scope and a lifetime, and the blast radius of any Credential Access technique shrinks. The Credential chaining guide shows how one harvested key leads to the next.

Common failure patterns

• Secrets in the agent's environment: API keys in environment variables of an agent that reads untrusted text. AML.CS0067 shows that scrubbing one execution path is not enough.
• One credential, many systems: a shared cluster-admin credential turned a pod compromise into multi-cluster access in the OpenAI and Hugging Face breach.
• Indexing everything: connecting a retrieval system to whole document stores without removing secrets first, which creates the conditions for AML.T0082.
• Exposed agent control interfaces: agent gateways reachable from the internet, as in AML.CS0048, hand over both configuration credentials and execution.
• Logging off by default: model invocation logging disabled, so the first sign of a stolen AI key is the bill.

Framework mapping

Practitioner checklist

• Map every agent, MCP server and AI pipeline to the credentials it holds and to a named owner.
• Remove literal secrets from agent configuration, MCP definitions and environment variables of agents that read untrusted content.
• Issue each agent its own short-lived, narrowly scoped credential; never share one key across agents or environments.
• Scan document stores for secrets before connecting them to retrieval or agent tools.
• Log agent tool calls, connector reads and AI provider sign-ins centrally, and alert on reads of credential files.
• Protect AI desktop client processes with EDR and alert on unexpected process memory access.
• Keep AI provider invocation logging on and alert when anyone queries or changes it.
• Rehearse revocation and rotation of AI credentials, and record time to revoke.

Standards and references

• MITRE ATLAS: Credential Access (AML.TA0013)
• MITRE ATLAS: ATLAS data repository
• MITRE ATT&CK: Credential Access (TA0006)
• OWASP: LLM06:2025 Excessive Agency
• Microsoft Security: Securing CI/CD in an agentic world, the Claude Code GitHub Action case
• Sysdig: LLMjacking, stolen cloud credentials used in new AI attack
• Lumia Security: AIKatz, attacking LLM desktop applications

Related NHI Mgmt Group resources: MITRE ATLAS Guide · ATT&CK Credential Access Tactic Guide · Secrets Management Guide · Agentic AI Identity Guide