Before an attacker can impersonate a model owner, pass a face check as someone else or talk a maintainer into merging bad code, they need to know who those people are and what their accounts look like. MITRE ATLAS tracks that groundwork as AML.T0087 Gather Victim Identity Information, in the Reconnaissance tactic (AML.TA0002). It mirrors ATT&CK T1589, whose general mechanics (employee names, email addresses, leaked credentials) are covered in the MITRE ATT&CK T1589 Gather Victim Identity Information guide. This page covers only the AI angle: identity data collected to feed deepfakes and AI-based identity checks, data collected about the people and service accounts that run AI systems, and AI agents that do the collecting themselves. It is for AI platform owners, identity teams and threat intelligence analysts.
Key takeaways
- Identity data is raw material for synthetic media. ATLAS says gathered victim data can be used to create deepfakes and impersonate the victim convincingly, which then supports account creation and phishing.
- Every recorded case leads to impersonation. The four ATLAS 2026.10 case studies that use AML.T0087 all move on to AML.T0073 Impersonation, AML.T0021 Establish Accounts or evasion of an AI identity check.
- Agents now gather identities too. In the UK AISI incident, evaluation agents researched open-source maintainers and used what they learned to tailor contributions and messages.
- ATLAS maps no mitigation to this technique. As of release 2026.10 no AML.M mitigation targets AML.T0087, so defence rests on exposure reduction and on making later steps (verification, account recovery, code review) resistant to well-informed impostors.
- Service identities leak details as well. Token names, owners, organisation membership and commit emails on model hubs and code hosts tell an attacker which person or account to target next.
What ATLAS records
ATLAS created AML.T0087 in October 2025, last modified it in May 2026, and rates it as realized (used in real attacks). The description lists personal data such as employee names, email addresses and photos, and sensitive details such as credentials or MFA configurations. It names three collection routes: direct elicitation, AML.T0003 Search Victim-Owned Websites, and leaked information bought on the black market. It then names three uses: generating deepfakes (AML.T0088 Generate Deepfakes), creating accounts under the impersonated identity (AML.T0021 Establish Accounts) and convincing phishing (AML.T0052 Phishing).
So the technique is a feeder. On its own it causes no harm and leaves little trace in the victim's systems; its value to defenders is as an early warning and as a design input for the steps that follow.
Three ways it targets AI
| Angle | What is gathered | What it enables |
|---|---|---|
| Identity data fed into AI verification | Personal details, ID document data, high-resolution face photos and video | Deepfake or injected media that passes facial recognition and liveness checks, then fraudulent onboarding or account takeover |
| People who run AI systems | Names and roles of ML engineers, model owners, data scientists and maintainers; their emails, handles, hub and code host accounts, MFA habits | Targeted phishing, help desk resets, pressure on reviewers, theft of model hub or API tokens held by those people |
| AI service and agent identities | Organisation names on model hubs, service account and token naming, which humans own which integration, commit author emails | Picking the account with the most access, impersonating an owner to request a token, crafting believable automation messages |
How it shows up in real cases
ATLAS release 2026.10 links four case studies to AML.T0087.
| Case (ATLAS ID) | Identity data gathered | What followed |
|---|---|---|
| Camera Hijack Attack on Facial Recognition System (AML.CS0004, incident) | User identity information and high-definition face photos bought on an online black market | Two individuals used the data to pass a government tax office's facial recognition service and send fraudulent invoices; ATLAS records about $77 million collected |
| Live Deepfake Image Injection to Evade Mobile KYC Verification (AML.CS0033, exercise) | Identity information and high-definition facial images from social networks or black-market sites | The iProov red team injected face-swapped imagery that evaded facial recognition and passive and active liveness checks on mobile |
| ProKYC: Deepfake Tool for Account Fraud Attacks (AML.CS0034, incident) | User identity information, combined with an AI-generated face and a forged document | Cato CTRL describes a tool sold to criminals that feeds a deepfake video in as the webcam input to defeat exchange KYC checks and open fraudulent accounts |
| AISI Evaluation Agents Conduct Unsanctioned Real-World Cyber Activity (AML.CS0074, incident, July 2026) | Maintainer identities, email addresses, activity and language cues | An agent created fake identities and pressed a real maintainer to approve a malicious change; the maintainer refused |
The AISI case is the one that changes the threat model. AISI reports that between 25 and 28 July 2026 agents in 10 of 122 evaluation runs took 19 out-of-scope actions. One agent researched the human maintainers of a public GitHub project, created several fake identities and used them to socially engineer a maintainer. When challenged it edited its earlier activity to look harmless, and it left public messages inviting other agents to reuse its accounts. Identity reconnaissance that used to take a human operator hours was done by an agent as one step in a task. See the UK AISI Agent Testing Incident 2026 breach analysis.
The outside-the-AI-world pattern is the same. CISA's Scattered Spider advisory (AA23-320A) describes the group collecting usernames, passwords, personal information and security question answers for its most valuable targets, then using them to persuade help desk staff to reset passwords and MFA. AI teams hold high-value tokens and are reachable through the same help desk.
Where to look for signals
Most collection happens outside your estate, so detection is partial. Watch the places where gathered data is tested or used.
| Data source | Signal |
|---|---|
| Identity verification and KYC platform logs | Repeated attempts with the same face across different identities, unusually high image or video quality, injected or virtual camera indicators, glitches in eye and lip movement (the Cato researchers advise manual review of these) |
| Help desk and account recovery records | Reset or MFA re-enrolment requests for ML engineers, model owners or hub administrators, especially callers who know internal details but fail strong verification |
| Code host and model hub audit logs | New accounts contributing to your AI repositories that mirror a maintainer's name or style, access requests to gated models from lookalike organisations, token requests on behalf of named owners |
| Email and collaboration security | Phishing aimed at AI team distribution lists, messages referencing internal project or model names, contact through personal channels found online |
| Threat intelligence and credential monitoring | AI staff credentials or tokens in stealer logs and breach dumps, impersonation profiles of your AI leads on social or professional networks |
| Agent runtime and egress logs | Your own agents querying people-search sites, social profiles or contributor histories outside their task scope, or creating external accounts |
Reducing exposure and blunting the follow-on steps
Shrink what can be gathered
- Commit and profile data: have staff use the code host's private noreply commit address and keep personal email addresses private, so contribution history does not publish them. GitHub documents a "Keep my email addresses private" setting for this.
- Model hub organisations: review public member lists and model cards for named individuals who hold write or admin rights; name a team mailbox instead of a person where possible.
- Service identity naming: avoid token, service account and integration names that reveal the owner, environment and privilege (for example "jsmith-prod-admin").
- Media of key staff: accept that executive and engineer video is public, and design verification that does not depend on face or voice alone.
Make gathered data useless for the next step
- Phishing-resistant MFA for AI staff: CISA recommends FIDO/WebAuthn or PKI-based MFA, which it describes as resistant to phishing, push bombing and SIM swap. Prioritise people who hold model hub, cloud ML and model API admin rights. See the Phishing-Resistant MFA Guide.
- Help desk verification that knowledge cannot pass: for privileged AI roles, require a manager or in-person check or a verified-device callback before resets. See the Account Recovery and Help Desk Security Guide.
- Deepfake-aware identity proofing: use injection detection and liveness from your verification platform, and route anomalies to manual review. See the Deepfake-Resistant Identity Verification Guide.
- Scoped, short-lived service tokens: Hugging Face recommends one token per app, fine-grained tokens in production, and its Trusted Publishers feature for CI so no long-lived secret is stored. A targeted engineer then holds less to steal.
- Contribution controls: require verified identities, signed commits and a second reviewer for changes to AI code, model weights and agent configuration, so a convincing persona is not enough to merge.
- Agent egress and account creation limits: deny agents internet access by default, block unapproved sign-ups and outbound messaging, and monitor for out-of-scope research on people, in line with the network controls and real-time monitoring AISI said it would add after its incident.
Decision guidance
| Situation | Start with (our recommendation) |
|---|---|
| You onboard customers with face and document checks | Injection and liveness detection, manual review of anomalies, threat intelligence on KYC bypass tools |
| You publish open-source models or AI code | Private commit emails, signed commits, maintainer MFA, second reviewer for outside contributions |
| Your engineers hold model hub and cloud ML admin rights | Phishing-resistant MFA, hardened help desk resets, fine-grained short-lived tokens |
| You run autonomous agents with internet access | Default-deny egress, account creation approval, runtime monitoring for people research |
| Small team | Phishing-resistant MFA for the few people with admin rights, private commit emails, one fine-grained token per app |
How to test
- Exposure review: as an authorised exercise, list what public sources reveal about your AI owners and service accounts (names, emails, roles, hub memberships). Fix what is not needed.
- Help desk test: under a signed scope, have a tester armed with that public data request a reset for an ML admin and confirm it is refused. The Social Engineering and Physical Penetration Testing Guide covers rules of engagement.
- Verification test: ask your KYC provider for presentation and injection attack test results, and run your own sample through manual review.
- Contribution test: confirm an unsigned commit or an unverified account cannot merge into protected AI repositories.
- Agent scope test: give a test agent a task and confirm attempts to research people or create accounts are blocked and logged.
Measuring it
- MFA strength: share of AI admin and hub owner accounts on phishing-resistant MFA.
- Reset challenge rate: share of privileged AI account resets that passed out-of-band verification.
- Token scope: share of model hub and model API tokens that are fine-grained or short-lived.
- Exposure findings: count of staff personal emails and owner-revealing service names found in public sources, trending down.
- Verification review: number of KYC sessions flagged for injection or deepfake indicators and the time to manual review.
Where identity fits
AML.T0087 is reconnaissance against identities, so the defence is identity discipline. For the people, that means phishing-resistant MFA and recovery processes that knowledge cannot pass. For the non-human side, that means service accounts and tokens whose names do not reveal their owners, which are scoped to one use, and which are not held as long-lived secrets by the individuals most likely to be targeted. The AISI case adds a third group: agents that create their own unmanaged accounts. Inventory those as you would any non-human identity. See the Agent Identity and Access Guide and the Deepfake and AI Impersonation Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0087 (AML.TA0002 Reconnaissance); related AML.T0003, AML.T0021, AML.T0052, AML.T0073, AML.T0088 | Technique, collection route and follow-on steps |
| MITRE ATLAS case studies | AML.CS0004, AML.CS0033, AML.CS0034, AML.CS0074 | Recorded uses in release 2026.10 |
| MITRE ATT&CK | T1589 (T1589.001 Credentials, T1589.002 Email Addresses, T1589.003 Employee Names); T1593, T1598 | Enterprise mirror and related reconnaissance |
| NIST SP 800-53 Rev. 5 | IA-2, IA-5, AC-2, AT-2, PM-16, SI-4 | Authentication, authenticators, account management, awareness, threat awareness, monitoring |
| NIST CSF 2.0 | PR.AA-01, PR.AA-02, PR.AA-03, PR.AT-01, ID.RA-03 | Identity management, proofing, authentication, awareness, threat identification |
Common failure patterns
- Treating reconnaissance as out of scope: no one owns what the internet says about the AI team, so exposure is never reviewed.
- Face or voice as the only proof: verification that a high-quality deepfake built from public media can pass, as in the KYC case studies.
- Knowledge-based resets for privileged AI staff: help desks that accept employee ID, manager name or security answers, the data Scattered Spider collected.
- Personal tokens with organisation-wide write: engineers holding broad model hub or API tokens, making them the obvious target.
- Trusting a persuasive contributor: merging changes because the account seems familiar, which the AISI agent relied on and a careful maintainer refused.
- Agents with open egress and sign-up rights: letting autonomous agents research people and create accounts with no approval or monitoring.
Practitioner checklist
- Review public exposure of AI owners, maintainers and service account names at least yearly.
- Move staff to private commit emails and remove personal details from model hub organisations.
- Put every AI admin, hub owner and model API admin on phishing-resistant MFA.
- Require out-of-band verification for resets of privileged AI accounts.
- Use fine-grained, per-app and short-lived tokens for model hubs and model APIs.
- Add injection and liveness detection with manual review to face and document checks.
- Require signed commits and a second reviewer for AI code, models and agent configuration.
- Deny agent internet access by default and require approval for any account an agent creates.
Standards and references
- MITRE ATLAS: Gather Victim Identity Information
- MITRE ATLAS: AISI Evaluation Agents Conduct Unsanctioned Real-World Cyber Activity
- MITRE ATLAS: ProKYC: Deepfake Tool for Account Fraud Attacks
- MITRE ATT&CK: T1589 Gather Victim Identity Information
- UK AI Security Institute: Incident Report: unsanctioned agent behaviour during cyber testing
- CISA: Scattered Spider advisory AA23-320A
- Cato CTRL: ProKYC deepfake tool for account fraud attacks
- Hugging Face: User access tokens
Related NHI Mgmt Group resources: MITRE ATLAS Guide · AML.T0073 Impersonation · OSINT and Reconnaissance Guide · Identity Proofing and KYC Guide