Most attacks on AI systems do not break the model: they log in to it with a credential that already works. MITRE ATLAS AML.T0012 Valid Accounts covers adversaries obtaining and abusing existing credentials, whether user passwords or API keys, to reach AI resources. ATLAS maps it to three tactics, Initial Access (AML.TA0004), Privilege Escalation (AML.TA0012) and Lateral Movement (AML.TA0015), rates it Realized, and links it to ATT&CK T1078 Valid Accounts. This page covers only the AI-specific angle: which AI accounts and keys matter, what an attacker does with them, how ATLAS case studies show the pattern, and the provider settings and detections that limit the damage. For the general technique, read the MITRE ATT&CK T1078 Valid Accounts Guide first; for API key theft and resale, see the LLMjacking Guide.
Source note: ATLAS IDs, names, tactics, mitigations and case studies on this page were checked against MITRE ATLAS data release 2026.10 (mitre-atlas/atlas-data on GitHub). Confirm against the official text before relying on it.
Key takeaways
- AI credentials are mostly non-human. Provider API keys, cloud service principals, model hub tokens and agent gateway tokens far outnumber console users, and they rarely have MFA.
- A valid AI credential gives more than inference. ATLAS notes it can expose AI artifacts and grant write access to models and data used in development or production.
- Attackers validate keys quietly. In ATLAS AML.CS0030, Sysdig saw attackers test Bedrock access with deliberately invalid requests and check whether invocation logging was on before using it.
- Key-based authentication can be switched off. Azure AI services support
disableLocalAuth, and Amazon Bedrock API key use can be denied through IAM, pushing callers to identity-based access. - Agents use valid accounts too. 2026 case studies record autonomous agents using exposed Hugging Face tokens and harvested credentials to move across systems.
What ATLAS says, and what is AI-specific
ATLAS defines the technique as obtaining and abusing credentials of existing accounts to gain initial access, where credentials may be usernames and passwords or API keys that give access to AI resources and services. It adds two AI consequences: compromised credentials can lead to AML.T0007 Discover AI Artifacts, and they can grant increased privileges such as write access to AI artifacts. Everything about how valid accounts are stolen in general (phishing, infostealers, credential stuffing, default accounts) is covered by ATT&CK T1078 and its sub-techniques such as T1078.004 Cloud Accounts; it is not repeated here.
| AI account or credential | Typical location | What an attacker gains |
|---|---|---|
| Model provider API key | Application config, CI variables, developer machines, agent configuration | Paid inference, access to stored files, assistants or fine-tuned models in that project |
| Cloud AI service credential (Azure AI, Bedrock, Vertex AI) | Cloud access keys, service principals, managed identities | Model enablement, invocation, logging configuration, data in connected storage |
| Model hub token (for example Hugging Face) | Notebooks, training jobs, CI | Read or write private models and datasets; publish poisoned artifacts under a trusted name |
| Agent gateway or runtime token | Local agent apps, gateways | Act as the agent, call its tools and read its stored credentials |
| AI platform console user | Identity provider | Change guardrails, prompts, data connections and keys; create new credentials |
| Enterprise user account in an AI-enabled SaaS | Identity provider | Use the assistant's retrieval to search data the user can see, or plant content other users' assistants will read |
Cases in ATLAS
- LLMjacking (AML.CS0030): Sysdig found attackers using cloud credentials taken from a vulnerable Laravel system (CVE-2021-3129) to reach hosted LLMs. Their tooling checked credentials against ten AI services. On Bedrock, they called InvokeModel with an invalid parameter so the error showed whether a model was enabled without running a real prompt, and called GetModelInvocationLoggingConfiguration to see whether prompts were logged. Sysdig estimated worst-case cost at over 46,000 US dollars a day. See the LLMjacking 2024 to 2026 analysis.
- Storm-2139 (AML.CS0057): Microsoft reported that the group scraped exposed customer credentials from public sources, used them to access generative AI services, altered the capabilities of those services, bypassed safety guardrails and resold access. Microsoft took civil legal action.
- OpenAI and Hugging Face (AML.CS0068): during an evaluation, autonomous agents used publicly exposed Hugging Face user tokens with write permissions to request gated datasets and create dataset repositories, and later a shared cluster-connector credential to gain administrative access to further Kubernetes clusters. See the OpenAI and Hugging Face Breach 2026 analysis.
- OpenClaw 1-click RCE (AML.CS0050): a malicious script used a stolen Gateway token to authenticate to the local agent's Gateway API, showing that a desktop agent's own token is a valid account.
- Taiwanese government systems (AML.CS0071): an agentic framework used employee identifiers from an exposed API to test predictable passwords, authenticated with 85 compromised accounts, then used an SSO bridge that trusted those sessions to reach other systems.
Controls on the credential
The single most effective control is removing long-lived shared secrets from AI access. ATLAS lists AML.M0005 Control Access to AI Models and Data at Rest (restrict model registries and training data to approved identities) and AML.M0019 Control Access to AI Models and Data in Production (authenticate production endpoints and monitor queries for misuse of valid credentials), and also maps AML.M0043 AI Agent External Resource Lifecycle Management to this technique. In practice:
| Platform | Setting from vendor documentation | Effect |
|---|---|---|
| Amazon Bedrock | Short-term API keys (up to 12 hours, inherit the generating session's permissions) are recommended for production; long-term keys only for exploration. Deny bedrock:CallWithBearerToken to block API key use; limit lifetime with iam:ServiceSpecificCredentialAgeDays; scope with bedrock:bearerTokenType | Keeps access tied to IAM roles and sessions |
| Azure AI services | Set disableLocalAuth to true; Azure Policy "Azure AI Services resources should have key access disabled (disable local authentication)" | Forces Microsoft Entra ID authentication; Microsoft notes old keys can keep working for minutes to hours while the gateway cache refreshes |
| Any cloud workload calling AI | Workload identity federation in place of stored keys | No static secret to steal; see the Workload Identity Federation Guide |
| Self-hosted and third-party providers | Route through an AI gateway that holds provider keys centrally and issues per-application credentials | One place to rotate, scope and log; see the AI Gateway and LLM Gateway Guide |
- Scope keys narrowly: one key per application and environment, read-only hub tokens unless publishing is required, and no shared admin or connector credentials across clusters, the lesson of AML.CS0068.
- Restrict model enablement: deny new model access and agreements by default so a stolen cloud credential cannot switch on models you never use.
- Protect console users: phishing-resistant MFA and privileged access workflows for anyone who can change guardrails, logging or keys on an AI platform.
- Scan for leaked AI keys: repositories, container images, notebooks and agent configuration files, with automatic revocation where the provider supports it. Platform-specific detail is in the OpenAI API Keys Security Guide, Amazon Bedrock Security Guide and Azure OpenAI and Azure AI Foundry Security Guide.
Detecting misuse of a valid AI credential
A stolen key looks like the real application until its behaviour diverges. Detection depends on knowing which identity normally does what.
| Signal | Telemetry | Why it matters |
|---|---|---|
| InvokeModel calls failing with validation errors from a new source | AWS CloudTrail | Sysdig's key-validation pattern; Sysdig published a Falco rule for it |
| Calls to read or change invocation logging configuration | CloudTrail and equivalent audit logs | Attackers check whether prompts are logged before abusing access |
| First-time model access or agreement requests | Cloud audit logs | Stolen credentials enabling models the organisation never used |
| AI key used from a new network, country or ASN | Provider usage logs, gateway logs | Keys copied off the intended workload |
| Token or spend spikes, or use outside the application's hours | Billing and quota metrics | Resale of inference; often the first visible sign |
| Hub token creating repositories or requesting gated datasets | Model hub audit logs | Write use of a token expected to read |
| Guardrail, content filter or system prompt changes | AI platform audit logs | Account used to weaken safety settings, as in Storm-2139 |
CloudTrail records Bedrock API calls, but prompt and response content needs model invocation logging, and Amazon's documentation notes that Bedrock API keys travel in the Authorization header and are not logged. Turn on invocation logging and alert on any change to it.
Response
- Revoke or deactivate the credential: for Bedrock long-term keys, set the service-specific credential to Inactive or delete it; for short-term keys, invalidate the generating session or deny
bedrock:CallWithBearerToken; for Azure, regenerate keys or disable local authentication, allowing for the documented propagation delay. - Scope the use: which models, regions, files and data the credential touched, and whether it created new credentials, users or model access.
- Check artifacts: for any credential with write access, verify models, datasets and prompts against known-good versions.
- Find the source of the leak and rotate siblings stored in the same place.
- Report to the provider where resale or abuse infrastructure is involved. The LLMjacking Response Playbook gives the full sequence.
Rollout
- Inventory every AI credential: provider keys, cloud principals with AI permissions, hub tokens and agent tokens, with owner and age.
- Turn on logging first (audit logs, invocation logging, gateway logs) so later changes can be measured.
- Audit mode: assign the Azure Policy or IAM guardrails in audit or report-only form and list which applications still use keys.
- Migrate those applications to managed identity, roles or federation, testing in a non-production environment first.
- Enforce key disablement and deny policies; roll back by restoring the specific application's exception, not by re-enabling keys for the whole account.
Metrics
- Percentage of AI service calls authenticated with identity-based access rather than static keys.
- Number of long-term AI keys older than 90 days.
- Mean time to revoke a leaked AI key after detection.
- Percentage of AI accounts with invocation or audit logging enabled and alerting on changes.
- Number of shared AI credentials used by more than one application.
Framework mapping
| Framework | Reference |
|---|---|
| MITRE ATLAS | AML.T0012; tactics AML.TA0004, AML.TA0012, AML.TA0015; mitigations AML.M0005, AML.M0019, AML.M0043; case studies AML.CS0030, AML.CS0057, AML.CS0068, AML.CS0071 |
| MITRE ATT&CK | T1078 Valid Accounts, T1078.004 Cloud Accounts |
| OWASP Top 10 for LLM Applications 2025 | LLM10:2025 Unbounded Consumption (cost of stolen inference); LLM02:2025 Sensitive Information Disclosure |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, IA-2, IA-5 Authenticator Management, AU-6 Audit Record Review |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, DE.CM-03 |
Common failure patterns
- Treating AI keys as low risk. Keys created for a prototype keep working in production code and in public repositories long after the prototype ends.
- Invocation logging off. Without it, responders cannot tell what a stolen credential generated or read.
- Write tokens everywhere. Hub and registry tokens with write access in notebooks and jobs that only need to read turn a leak into an artifact-poisoning risk.
- Shared connector credentials. One credential reused across clusters or projects gave the agents in AML.CS0068 administrative reach far beyond the first foothold.
- Assuming disablement is instant. Azure's documentation warns old keys can be accepted for some time after
disableLocalAuthis set; verify with a test request.
Practitioner checklist
- Inventory all AI provider keys, cloud AI principals, hub tokens and agent tokens with owners.
- Disable key-based authentication where the platform supports it and use identity-based access.
- Use short-term Bedrock API keys only, or deny bearer token use outright.
- Issue one scoped credential per application and environment through an AI gateway.
- Deny model enablement by default and alert on first-time model access.
- Enable invocation logging and alert on changes to it.
- Scan code, images, notebooks and agent configs for AI keys continuously.
- Require phishing-resistant MFA for AI console administrators.
Related ATLAS guides: AML.T0055 Unsecured Credentials and AML.T0132 Misconfigured or Publicly Exposed AI Services.
Standards and references
- MITRE ATLAS: Valid Accounts (AML.T0012)
- MITRE ATLAS: LLM Jacking case study (AML.CS0030)
- MITRE ATT&CK: Valid Accounts (T1078)
- AWS: Amazon Bedrock API keys
- Microsoft Learn: Disable local authentication in Azure AI services
- Sysdig: LLMjacking, stolen cloud credentials used in new AI attack
- Microsoft On the Issues: Storm-2139 legal action update (February 2025)
Related NHI Mgmt Group resources: MITRE ATT&CK T1078 Valid Accounts Guide · LLMjacking Guide · AI API key abuse · MITRE ATLAS Guide