ATLAS AML.T0125: Create Account on AI Platforms

An attacker who can create a new account on your AI platform no longer needs the foothold that got them in. MITRE ATLAS AML.T0125 Create Account describes adversaries creating accounts to keep access to an AI system or its supporting infrastructure, giving them secondary credentialed access without leaving remote access tools behind. ATLAS added the technique in version 2026.09 under the Persistence tactic (AML.TA0006), rates it Realized, and links it to ATT&CK T1136 Create Account. This page covers only the AI-specific angle: which AI platforms and agent registries can mint new identities, what that looks like in logs, and how to make unexpected account and agent creation stand out. For the general technique on Windows, directories and cloud tenants, read the MITRE ATT&CK T1136 Create Account Guide.

Key takeaways

AI estates have many places to create an identity. ATLAS lists AI platforms, model and dataset repositories, development environments, experiment trackers, orchestration services and data stores, each with its own user, service, workload or automation accounts.
Agents can now create the account themselves. In ATLAS case study AML.CS0069, a jailbroken coding agent created a local backdoor account in a compromised environment as part of a largely automated intrusion.
Agent identity registries are new creation points. Microsoft Entra agent identity blueprints and the Amazon Bedrock AgentCore agent identity directory both provision identities for agents, so they need the same scrutiny as user directories.
Inherited permissions multiply impact. In Entra Agent ID, permissions granted to a blueprint apply to every agent identity created from it, so one new identity can arrive already privileged.
Detection is mostly baselining. Legitimate creation follows pipelines and named owners; creation by an unusual principal, outside change windows or by an agent at runtime is the signal.

What ATLAS says, and what is AI-specific

ATLAS defines AML.T0125 as creating an account to maintain access to an AI system or its supporting infrastructure. With enough access, a new account becomes a second way back in that does not depend on malware or a persistent remote session. Accounts may sit on local systems, enterprise domains, cloud tenants, identity providers or individual services. The AI-specific part is the list of targets: user, service, workload or automation accounts in AI platforms, model or dataset repositories, development environments, experiment trackers, orchestration services, data stores and other AI operations infrastructure. As of ATLAS 2026.10 one ATLAS mitigation is formally mapped to the technique, AML.M0043 AI Agent External Resource Lifecycle Management (treat accounts and other resources an agent creates as attributable, lifecycle-managed assets), and the controls below draw on the agent and logging mitigations that apply in practice.

The closely related move of adding a new key or token to an account that already exists is a different ATT&CK technique (T1098 Account Manipulation, including T1098.001 Additional Cloud Credentials). On AI platforms the two often happen together, because creating a service account is usually followed by issuing it a token.

Where an account or identity can be created	Examples of what gets created	Why it suits persistence
Model and dataset hub organisation	Organisation member, service account, service account token	Read or write private models and datasets; publish under a trusted organisation name
Agent identity registry	Agent identity from an Entra blueprint; agent identity in an AgentCore agent identity directory	Looks like one more agent among many; may inherit blueprint permissions
Cloud tenant hosting AI services	IAM user, service principal, managed or workload identity	Direct access to model endpoints, training data storage and logging settings
AI provider console or project	Project member, project service account and its API key	Paid inference, stored files and fine-tuned models in that project
MLOps tooling	Users in experiment trackers, notebook servers, orchestration and pipeline tools	Access to training code, checkpoints, credentials in job definitions
Host running an agent or model	Local operating system account	Survives agent shutdown; the pattern seen in AML.CS0069

Case: an agent creating its own backdoor account

ATLAS case study AML.CS0069, GTG-1002 Claude Code Espionage Campaign, is the reference case. Anthropic reported in November 2025 that it detected the activity in mid-September 2025 and assessed with high confidence that the group was Chinese state-sponsored. The operators targeted about 30 organisations in technology, finance, chemical manufacturing and government, and succeeded against a small number. They got past the model's safeguards by posing as a defensive security firm and splitting the work into small, innocent-looking tasks, then connected the agent to scanning and other tooling through the Model Context Protocol (MCP).

ATLAS records that, after gaining access, the agent created a local backdoor account to maintain access (procedure step S16), and Anthropic states that backdoors were created as part of the operation. Anthropic estimated the AI performed 80 to 90 percent of the campaign, with humans making roughly four to six critical decisions per campaign. For defenders, the lesson is speed and volume: account creation that once needed a human operator can now be one step in a chain an agent runs at machine speed, so detections cannot rely on attackers pausing between stages. Anthropic responded by banning the accounts involved, notifying affected organisations, coordinating with authorities and expanding its classifiers.

Two further points matter for AI platforms specifically. First, the agent in this case held whatever access its tools gave it; an agent whose tools include identity administration can create accounts as readily as it can query a database. Second, the provider side of the same incident is account-based too: the attacker used provider accounts, which is why AI providers ban and monitor accounts at their end. See the AML.T0012 Valid Accounts page for the credential side.

Agent identity registries: the new creation point

Agent identity services make agents first-class identities, which is good for governance and also creates a new place where an attacker can register something that looks legitimate.

Microsoft Entra Agent ID: every agent identity in a tenant is created from an agent identity blueprint. Microsoft's documentation describes the blueprint as an identity type whose one operation is provisioning or deprovisioning agent identities, using the Microsoft Graph permission AgentIdentity.CreateAsManager. Creation is recorded in audit logs as executed by the blueprint principal. Permissions an administrator grants on the blueprint principal from an inheritable resource application flow to all agent identities created from it. Treat blueprint credentials and the AgentIdentity.CreateAsManager grant as high-value: whoever holds them can mint agent identities.
Amazon Bedrock AgentCore Identity: AWS describes an agent identity as a workload identity with agent-specific attributes, held in an agent identity directory that acts as a central registry for agent identities, their metadata and access policies. Restrict who can create identities in the directory, and review new entries against the deployment pipeline that should have created them.
Agent platforms generally: wherever an agent builder can register a new agent with its own credentials, that registration is account creation for the purposes of this technique. See the Agent Identity and Access Guide and Cloud Agent Identity Services Compared (Entra, AgentCore, Google).

What to log and detect

ATLAS mitigation AML.M0024 AI Telemetry Logging and Monitoring asks for logs of agent intermediate steps, tool use and the identity of the agent. For this technique, combine those agent logs with the identity events below.

Source	Events to collect	What makes it suspicious
Hugging Face organisation audit log (Team and Enterprise plans)	`org.add_user`, `org.invite_user`, `org.join.from_domain`, `org.join.automatic`, `org.change_role`, `org.service_account.token.create`	New member or service account token outside onboarding; role raised soon after joining; export of the log itself (`org.audit_log.export`) by an unexpected user
Microsoft Entra audit logs	Agent identity creation by a blueprint principal; consent grants on blueprints	Blueprint used outside its deployment pipeline; new permissions granted to a blueprint
Cloud audit trail of the AI tenant	User, role, service principal and access key creation in accounts that host AI services	Creation by a workload identity, a notebook role or an agent execution role
Agent tool-call logs and MCP gateway	Tool calls that invoke identity administration APIs or run account commands on hosts	Any account creation not part of the agent's declared task
Hosts running agents or model servers	Local account creation events from the operating system	New local account on a host whose build never creates one

Useful detection logic: alert on any identity creation whose actor is a non-human identity that is not one of your provisioning pipelines; alert when an agent's runtime credential performs identity administration at all; and correlate new accounts with first use from a new network location or token within the following hours.

Mitigations

Remove identity administration from agents: AML.M0026 Manage AI Agent Service Access and AML.M0028 Enforce Access Controls for AI Agent Tools call for least privilege on agents and the tools they share. An agent that does not need to create users should hold no permission to do so, and MCP servers should pass the caller's restrictions to the tool.
Stop authority expansion at runtime: AML.M0037 AI Agent Authority Expansion Controls says the maximum authority should be granted before runtime and new identities discovered during execution treated as out of scope. Creating an account is the clearest form of authority expansion.
Require a human for identity changes: AML.M0029 Human In-the-Loop for AI Agent Actions fits any agent workflow that legitimately provisions accounts, for example IT helpdesk agents.
Watch for scope drift: AML.M0038 AI Agent Scope Drift Detection checks that planned actions stay aligned with the authorised objective; an account creation step in a reporting or coding task should halt the run.
Provision only through pipelines: create service accounts, hub service accounts and agent identities through infrastructure as code with a named owner, and treat anything created outside that route as an incident until explained. See NHI lifecycle automation.
Use approval workflows on token issue: Hugging Face organisations can turn on a token approval policy; its audit events (org.token_approval.enabled, org.token_approval.authorization_request and the authorised, denied and revoked outcomes) give a record of each request to grant a token access.

Response and testing

Contain: disable the new account or agent identity, revoke its tokens and keys, and check whether it created further identities or tokens.
Trace the creator: identify the principal that created it. If it was an agent, pull the agent's tool-call log and the prompt or data that led to the call, and treat the agent's own credential as compromised.
Review inherited access: for blueprint-created agent identities, review what permissions the blueprint carries and whether any were added recently.
Sweep for siblings: list every identity created by the same actor or in the same window across the hub, cloud tenant and agent registries.
Test: in a test tenant, have a test agent attempt an identity creation call through its tools. The call should be denied by policy, raise an alert, and appear in the agent log with the agent's identity. Repeat after every change to agent tool permissions. AML.M0035 AI Red Team exercises are a natural home for this check.

Metrics

Percentage of AI-platform and agent identities with a named owner and a creating pipeline on record.
Number of identities created outside approved pipelines per month, and median time to investigate each.
Number of agent runtime credentials holding any identity administration permission (target zero, or a documented exception list).
Coverage: share of AI platforms whose identity audit logs reach the SIEM.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0125 Create Account; tactic AML.TA0006 Persistence; case AML.CS0069	The technique itself
MITRE ATT&CK	T1136 Create Account (T1136.001 Local Account, T1136.003 Cloud Account); T1098.001 Additional Cloud Credentials	Enterprise mirror and the related token step
NIST SP 800-53 Rev 5	AC-2 Account Management, AC-2(4) Automated Audit Actions, AC-6 Least Privilege, AU-12 Audit Record Generation	Account lifecycle, auditing of creation, least privilege for agents
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03	Managed identities, least-privilege permissions, monitoring of activity
OWASP Top 10 for Agentic Applications	ASI03 Identity and Privilege Abuse; ASI10 Rogue Agents	Agents misusing identity rights; unauthorised agents in the estate

See the OWASP Agentic Top 10 ASI03 Guide and the MITRE ATLAS Guide.

Common failure patterns

Collecting only directory logs. Account creation on a model hub or experiment tracker never reaches the SIEM, so a new organisation member goes unnoticed.
Giving agents broad admin roles for convenience. An agent built to automate operations holds a role that can create users, and nothing distinguishes a legitimate call from an injected one.
Treating blueprints as configuration, not identities. Blueprint credentials stored loosely let anyone who finds them create agent identities that inherit the blueprint's permissions.
No owner field on agent identities. Without an owner, a rogue agent identity is indistinguishable from an abandoned experiment.
Revoking the attacker's original access but not the accounts they created. The secondary account is the reason the technique exists; responders must sweep for it.

Practitioner checklist

List every AI system that can create users, service accounts or agent identities.
Send identity audit logs from model hubs, AI clouds and agent registries to the SIEM.
Remove identity administration permissions from agent runtime credentials.
Protect agent identity blueprint credentials and creation permissions as privileged access.
Create AI service accounts and agent identities only through pipelines with named owners.
Alert on identity creation by non-human actors that are not provisioning pipelines.
Include new-account sweeps in AI incident response runbooks.
Test agent tool permissions for identity creation in red team exercises.

AML.T0125 Create Account: Spotting Rogue Accounts and Agent Identities on AI Platforms