Before an attacker poisons a model hub or abuses an AI service, they usually sign up for it, and that new account is often the earliest point where a defender can notice them. MITRE ATLAS AML.T0021 Establish Accounts covers adversaries creating accounts with services to use in targeting, to gain access to resources needed to further their operations, or for victim impersonation. ATLAS places it in the Resource Development tactic (AML.TA0003), rates its maturity as Realized, and links it to ATT&CK T1585 Establish Accounts. This page covers only the AI-specific angle: accounts and organisations on model hubs, registrations on AI-enabled services, and the provider-side and consumer-side controls that stop a fresh account becoming trusted. The general technique (social media personas, email accounts, cloud accounts) is covered in the MITRE ATT&CK T1585 Establish Accounts guide and is not repeated here. The audience is AI platform owners, ML engineers who consume public models, and teams that run AI-enabled onboarding.
Key takeaways
- The account is the staging ground. On a model hub, an attacker-owned user or organisation is where poisoned models and datasets are published and where look-alike brands are built.
- Names are trusted more than owners. ATLAS case AML.CS0065 shows that re-registering a deleted Hugging Face namespace lets an attacker serve a model under a path that pipelines already trust.
- Unverified organisations still attract members. In AML.CS0027, employees asked to join a researcher's fake company organisations and uploaded models into them.
- Open registration is an access control decision. AML.CS0006 records a password-protected code repository that let any user register, which exposed AI training data and production credentials.
- AI-enabled onboarding is a target in its own right. Three ATLAS cases record attackers registering accounts with victim identity data after defeating facial recognition and liveness checks.
What ATLAS says, and what is AI-specific
ATLAS describes AML.T0021 as adversaries creating accounts with various services for use in targeting, to gain access to resources needed to further their operations, or for victim impersonation. The ATLAS 2026.10 entry adds bulk or fraudulent registration of AI service account pools, and autonomous AI agents creating accounts as prerequisites for later activity. The ATT&CK parent technique T1585 has sub-techniques for social media, email and cloud accounts; ATLAS adds the services that matter for AI: public model and dataset hubs, AI service APIs, and products that use AI models to decide who gets an account. In the ATLAS case studies covered here the technique appears in three distinct patterns. ATLAS 2026.10 also links it to agent evaluation incidents (AML.CS0073, AML.CS0074) and distillation campaigns (AML.CS0075, AML.CS0076).
| Pattern | Account created on | What it enables next | ATLAS case |
|---|---|---|---|
| Namespace and brand squatting | Public model hub (user or organisation) | Publishing malicious models under a trusted or look-alike name; collecting members and their uploads | AML.CS0027, AML.CS0065 |
| Self-registration into a protected system | A service that should have been invite-only | Access to source code, training data and credentials around an AI product | AML.CS0006 |
| Fraudulent onboarding | Financial or government service that uses face recognition for identity checks | Victim impersonation and fraud, after evading the verification model | AML.CS0004, AML.CS0033, AML.CS0034 |
Related ATLAS techniques have their own pages: AML.T0012 Valid Accounts covers abuse of accounts that already exist, and MITRE ATLAS AML.T0111 AI Supply Chain Reputation Inflation covers making a new account look established.
Cases in ATLAS
- Organization Confusion on Hugging Face (AML.CS0027, 2023): a security researcher registered organisation accounts on Hugging Face under the names of real companies that had no official presence. His write-up explains that claiming such a name did not require matching the brand's domain, and that the organisations stayed unverified. Engineers from those companies still requested to join, which gave him admin rights over the organisation, visibility of models members uploaded, including private ones, and write access to them. He notes that the missing verified status did not appear to change members' behaviour.
- Model Namespace Reuse (AML.CS0065, 2025): Unit 42 showed that when a Hugging Face author is deleted, the
Author/ModelNamepath becomes available again. When a model was transferred to a new owner and the old author then deleted, Hugging Face had been redirecting the old path (HTTP 307); re-registering the old name overrides that redirect. Unit 42 registered abandoned namespaces and showed malicious replacements deploying from the Google Vertex AI Model Garden and the Azure AI Foundry model catalog, and found thousands of open source repositories with reusable names hard-coded or set as default arguments. The original owners' accounts were never compromised: the attacker simply created a new one. - ClearviewAI Misconfiguration (AML.CS0006, 2020): the company's source code repository was password protected but allowed an arbitrary user to register. Researchers at spiderSilk did so and reached production credentials, keys to cloud storage holding 70,000 video samples, application builds and Slack tokens. ATLAS notes that access to training data gives an attacker the ability to cause arbitrary misclassification in the deployed model.
- KYC onboarding cases (AML.CS0004, AML.CS0033, AML.CS0034): in each, the attacker used victim identity information to register an account after defeating facial recognition: camera hijacking against a tax system's face check (reported fraud of 77 million US dollars), a red team's face-swapped image injection that evaded liveness checks on mobile, and the ProKYC deepfake tool sold to defeat KYC on cryptocurrency exchanges. The defences for the verification step are in the Deepfake-Resistant Identity Verification Guide; this page covers the account side.
Controls if you run the AI service or hub organisation
ATLAS 2026.10 maps three mitigations to AML.T0021: AML.M0043 AI Agent External Resource Lifecycle Management (treat accounts and other resources created by AI agents as attributable, lifecycle-managed assets), AML.M0005 Control Access to AI Models and Data at Rest (verify identities before granting access to model registries, so newly established accounts cannot automatically reach protected artifacts) and AML.M0019 Control Access to AI Models and Data in Production (the same principle for production AI services). The practical meaning is that a new account should start with nothing.
| Control | Example setting (Hugging Face organisation documentation) | Why it matters for AML.T0021 |
|---|---|---|
| Bind membership to your identity provider | Single sign-on for the organisation, with access rules mapped from the IdP | Removes self-service membership as a route in |
| Control who can join | "Organization email domain" lets any Hub user with a matching email address join; "Allow requests to join from the organization page" adds a request queue for admins | Set the domain only to a domain you control, and review join requests as access requests |
| Least privilege for members | Roles no_access, read, contributor, write, admin; Resource Groups for per-repository access | A new member gets read or contributor, never write across every repository |
| Restrict token types | Token policies: "Only access via fine-grained tokens" or "Require administrator approval" | An account added in error cannot mint broad tokens against organisation resources |
| Record membership changes | Audit logs with events such as org.add_user, org.change_role and repo.create, exportable as JSON | Evidence and alerting for unexpected joins and new repositories |
| Claim your names | Register your organisation and product names on the hubs you use, even if unused, and verify the domain | Removes the brand gap that AML.CS0027 relied on |
Resource Groups, token policies and audit logs are described as Team and Enterprise plan features in the Hugging Face documentation; other hubs and internal registries have equivalent settings under different names. For internal model registries and AI platforms, the same rule applies: disable open self-registration, require approval for new accounts and organisations, and grant no repository or model access by default. Do not keep orphaned namespaces: if you rename or delete an organisation, consider keeping a placeholder so the old name cannot be claimed by someone else.
Controls if you consume models from public hubs
Most organisations meet AML.T0021 as consumers: the attacker's account is on the hub, and the risk is that your pipeline trusts it. The Unit 42 research recommends three controls, and the other two rows follow from the cases above.
- Pin to a commit: load models with the
revisionparameter set to a specific commit, not byAuthor/ModelNamealone, so a re-registered namespace cannot silently replace the artifact. - Mirror to trusted storage: for production, copy approved models into an internal registry after scanning and verification, and load only from there.
- Scan code for model references: treat model identifiers in code, default arguments, notebooks, docstrings and comments as dependencies, and review them like package names.
- Check the owner, not just the name: record the expected publisher for each approved model and alert when the owning account or organisation changes, or when a path that used to redirect starts resolving directly.
- Verify artifacts: ATLAS AML.M0014 Verify AI Artifacts and AML.M0013 Code Signing apply where publishers sign models; see the Model Signing and OpenSSF Model Signing Guide.
Detecting attacker accounts
Account creation happens on infrastructure you often do not own, so detection splits into what a provider or organisation admin sees and what a consumer can watch from outside.
| Signal | Where to look | Who can see it |
|---|---|---|
| New hub organisation or user using your brand, product or executive names | Periodic search of model and dataset hubs and code hosts; brand monitoring | Anyone |
| Join requests or auto-joins from unexpected accounts | Organisation audit log (org.add_user, automatic join events), join request queue | Organisation admins |
| New repositories or renamed repositories inside your organisation | Audit log repo.create, repo.update_settings | Organisation admins |
| Approved model now owned by a different account, or old path no longer redirecting | Model inventory compared with hub metadata on each pipeline run | Consumers |
| Bursts of sign-ups sharing devices, networks or document templates | Onboarding and identity verification logs | Service providers |
| Self-registered accounts on systems meant to be invite-only | Identity provider and application account creation logs | System owners |
How to test
- Self-registration review: for every system that holds models, datasets, prompts or AI code, attempt to create an account without an invitation, in a test tenant. Any success is a finding, as in AML.CS0006.
- Default access check: create a fresh member in each hub organisation and internal registry and list what it can read and write before any role is granted.
- Namespace exercise: take the model identifiers found by your code scan and check each one: does the author still exist, has it moved, is the reference pinned?
- Brand sweep: search the hubs you use for organisations and users carrying your names, and record the ones you do not own.
- Onboarding red team: for AI-enabled sign-up, commission authorised testing of injection and deepfake resistance against the verification step.
Metrics
- Pinned references: percentage of production model loads that use a commit revision or an internal mirror (target: 100).
- Orphan exposure: number of model references in code whose author no longer exists or has changed owner.
- Look-alike accounts: unowned hub organisations using your names, and time to takedown request.
- Default access: number of AI systems where a new account receives any repository or model access before approval (target: zero).
- Join review time: median time from join request to decision in hub organisations.
Framework mapping
| Framework | Item | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0021 Establish Accounts (tactic AML.TA0003 Resource Development) | The technique itself |
| MITRE ATLAS mitigations | AML.M0005, AML.M0019, AML.M0043 (mapped); AML.M0014, AML.M0013 (consumer side) | Identity verification before access; artifact verification for consumers |
| MITRE ATT&CK | T1585 Establish Accounts (T1585.001 Social Media Accounts, T1585.002 Email Accounts, T1585.003 Cloud Accounts) | The enterprise parent; general tradecraft |
| OWASP Top 10 for LLM Applications 2025 | LLM03:2025 Supply Chain | Third-party models and repositories, including model and publisher integrity |
Common failure patterns
- Loading by name in production. Unpinned
Author/ModelNamereferences are exactly what namespace reuse targets. - Treating a join request as harmless. In AML.CS0027 the risk ran both ways: staff joined an attacker's organisation and handed over their models.
- Leaving registration open behind a password. AML.CS0006 shows a login page is not access control if anyone can create the login.
- Deleting an organisation without reserving the name. The old path may still be in other people's code.
- New members get write by default. A mistaken approval then becomes a route to replace models.
Practitioner checklist
- Register and verify your organisation names on every model and dataset hub your teams use.
- Bind hub organisation membership to SSO and restrict the organisation email domain to one you control.
- Give new members
readorcontributoronly, and use Resource Groups for sensitive repositories. - Set a token policy that requires fine-grained tokens or administrator approval.
- Export audit logs to your SIEM and alert on membership and repository creation events.
- Pin every production model to a commit or load it from an internal mirror.
- Scan code and notebooks for model identifiers and check their owners on each build.
- Turn off self-registration on any system holding AI code, data or models.
Standards and references
- MITRE ATLAS: Establish Accounts (AML.T0021)
- MITRE ATLAS: Model Namespace Reuse Supply Chain Attack (AML.CS0065)
- MITRE ATT&CK: Establish Accounts (T1585)
- Palo Alto Networks Unit 42: Model Namespace Reuse
- Hugging Face: Access control in organizations
- Hugging Face: Tokens Management
- Hugging Face: Audit Logs
- threlfall_hax: Model Confusion, weaponizing ML models for red teams
Related NHI Mgmt Group resources: MITRE ATLAS AI Reconnaissance and Resource Development · Hugging Face Security Guide · Model Supply Chain Guide · MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull