AML.T0095 Search Open Websites/Domains: Shrink the AI Footprint Attackers Can Find

Before an attacker sends a single prompt to your AI systems, they can usually learn which models, agent frameworks, endpoints and keys you use from public websites and code repositories. MITRE ATLAS records this as AML.T0095 Search Open Websites/Domains, a Reconnaissance (AML.TA0002) technique with one sub-technique, AML.T0095.000 Code Repositories. ATLAS rates it as realised and links it to seven case studies, from search queries that found exposed service portals to agents that searched GitHub on their own. This guide explains what attackers look for in the AI context, how to measure and reduce your public AI footprint, how to get early warning, and what to do when you find an exposure. It is for AI platform owners, application security teams and threat intelligence analysts. Finding and triaging leaked LLM keys is covered step by step in How to find LLM API keys in code and CI; this page covers the reconnaissance view around it.

Key takeaways

• Reconnaissance happens out of your sight. MITRE ATT&CK notes that searches of public repositories happen at high volume, often outside the target's visibility, so detection must focus on what you publish and on the later stages it enables.
• AI adds new things worth finding. ATLAS lists frameworks, models, datasets, agents, agent tools and leaked credentials in agent configuration as targets of repository searches.
• Search results reveal agent entry points. ATLAS describes attackers using search results and backlink analysis to locate embedded agent interfaces and to infer environment IDs and naming conventions.
• ATLAS maps two mitigations. AML.M0000 Limit Public Release of Information and AML.M0039 AI Honeypots; everything else on this page supports those two.
• Treat anything public as compromised. GitHub tells secret scanning partners to consider every reported secret public and compromised; your own response should start with revocation, not deletion.

What the technique covers

ATLAS describes AML.T0095 as searching public websites and domains, such as social media, news sites and the victim's own domains, for information that helps target the victim and its AI systems. Precise search queries identify the platforms a victim uses, which can then be followed by AML.T0049 Exploit Public-Facing Application (see MITRE ATLAS AML.T0049 Exploit Public-Facing Application) or AML.T0093 Prompt Infiltration via Public-Facing Application (see MITRE ATLAS AML.T0093 Prompt Infiltration via Public-Facing Application). The technique mirrors ATT&CK T1593 Search Open Websites/Domains, and ATLAS links the sub-technique to ATT&CK T1593.003 Code Repositories.

AML.T0095.000 Code Repositories covers searches of GitHub, GitLab, SourceForge, Bitbucket and similar sites, including repositories of AI tools and agent frameworks the victim uses but does not own. ATLAS says these searches can feed further reconnaissance (AML.T0064 Gather RAG-Indexed Targets), resource development, discovery (AML.T0084 Discover AI Agent Configuration) and initial access (AML.T0012 Valid Accounts), and that leaked keys are an example of AML.T0083 Credentials from AI Agent Configuration.

How attackers use it: ATLAS cases

• Finding service portals by search (AML.CS0039): in the Cato Networks Jira Service Management research, the researchers used a search engine query to list organisations running Atlassian service portals, then targeted the AI agents that processed tickets from those portals.
• Reading agent repositories (AML.CS0051): HiddenLayer researchers used the public OpenClaw GitHub repository as a source of agent configuration files before showing how a webpage could turn the agent into a command and control implant.
• Stale model references (AML.CS0065): Unit 42 reviewed public model catalogues, Hugging Face author pages and open source code to find references to models whose author namespace had been deleted and could be re-registered. See the Hugging Face Security Guide for pinning and namespace hygiene.
• Studying the code that runs the agent (AML.CS0067): Microsoft researchers analysed the Claude Code GitHub Action code to understand how agent tools ran and where security boundaries sat, before showing how injected GitHub content could expose CI secrets.
• Agents doing the searching (AML.CS0070): in an attempt against Langflow and n8n, an agent driven by a DeepSeek model searched GitHub for trending proof-of-concept repositories for 2026 CVEs. Reconnaissance is increasingly automated, so the time between exposure and use keeps shrinking.

Public exposure of AI secrets is common. In November 2026 Apiiro reported 2,539 secrets in 1,994 public repositories that had been written into Claude Code settings files and related history (see Claude Code Settings Leak 2026). In the Moltbook exposure, Wiz found a database key in the site's client-side JavaScript within minutes (see Moltbook Database Exposure 2026).

Measure your public AI footprint

Run the same searches an attacker would, on a schedule, and record the results as an exposure register. Do this only against your own organisation's assets.

1. Repositories you own: list public repositories in every organisation and personal account linked to staff, including forks and archived repositories. Scan their full history, not only the current branch.
2. Agent configuration folders: search your public code for committed agent settings directories, MCP client configuration files and saved transcripts. The Claude Code case shows these can hold credentials typed into approved commands.
3. Other public developer surfaces: GitHub secret scanning for partners also covers issues, gists, pull requests, discussions, wikis, npm packages and workflow logs in public repositories, which shows how many places outside code hold secrets.
4. Client-side code: inspect the JavaScript of public web applications for model endpoint URLs, provider keys and database keys.
5. Search engine results: search for your domains together with the names of the chat and agent platforms you use, and for indexed URLs that reveal environment or tenant identifiers.
6. Model and dataset references: list every external model and dataset your code loads by name, and check that each author namespace still exists and that you pin a revision.
7. People and talks: review public talks, blog posts and job adverts for architecture detail that adds little value for readers but helps targeting.

Reduce what is published

ATLAS frames AML.M0000 as limiting public release of technical information about the AI stack and organisational details such as researcher names and department structures. ATT&CK adds M1013 Application Developer Guidance (do not publish credentials) and M1047 Audit (scan before committing and remove leaked credentials from history).

Get early warning

You will rarely see the searches. You can see what happens next.

• Decoys (AML.M0039): ATLAS describes monitored decoy AI services, agents and credentials that serve no business purpose, so any interaction is a high-confidence signal. Plant a canary AI provider key or agent endpoint in a place an attacker would search and alert on any use. See AI Agent Honeytokens and Canaries.
• Provider notifications: GitHub's partner program sends matched tokens from public repositories to participating providers, who are told to revoke them and notify users. Make sure provider security emails reach a monitored mailbox, not a former employee.
• Key usage anomalies: monitor AI provider usage per key for new source networks, new models and sudden spend. A spend limit caps the damage; see How to set spend limits on LLM API keys.
• Probing of public AI apps: log and review requests to public chat and agent endpoints for enumeration patterns and unusual prompts that follow a public disclosure.

Respond to an exposure

1. Revoke first: rotate the exposed credential at the provider before cleaning the repository. In the CISA contractor leak, AWS keys stayed valid for about 48 hours after the repository was taken down (see CISA Private-CISA GitHub Leak 2026).
2. Check use: review provider and downstream logs for the whole period the secret was public.
3. Clean up: remove the secret from history and forks where you can, and ask the host to clear cached views if needed.
4. Report others' tokens: if you find someone else's Hugging Face token, Hugging Face provides a revocation endpoint that needs no rights over the owning account and notifies the owner.
5. Fix the cause: find why the secret reached a public place (disabled push protection, synced personal folders, agent settings) and add the control.

The full alert workflow is in How to respond to a GitHub secret scanning alert.

Where identity fits

Most of what AML.T0095.000 finds that is directly usable is a non-human identity: a provider API key, a model hub token, an agent tool credential. Each should have an owner, a narrow scope and an expiry, so that a found key is short-lived and limited. Agent credentials stored in configuration files are covered in the MITRE ATLAS AML.T0083 Credentials from AI Agent Configuration guide.

Measuring it

• Public exposure count: open findings in the exposure register, by type (keys, endpoints, configuration, architecture detail).
• Time to revoke: median hours from detection of a public AI secret to revocation at the provider.
• Push protection coverage: share of repositories with push protection enforced and bypasses reviewed.
• Canary hits: number of decoy key or endpoint interactions, each investigated.
• Pinned references: share of external model and dataset loads pinned to a revision.

How to test

• Self-reconnaissance exercise: give a red team only your organisation name and a time box, and ask for a report of AI assets and secrets found from public sources.
• Canary drill: confirm that a planted decoy key in a test public repository produces an alert and a ticket within your target time.
• Scanner coverage: test that your scanners catch agent settings files and passwords inside command strings, which the Apiiro research found many scanners missed.

Common failure patterns

• Deleting instead of revoking: the secret remains in clones, forks and caches.
• Scanning only company organisations: staff and contractor personal repositories are where many leaks occur, as in the CISA contractor case.
• Ignoring agent folders: agent settings and transcripts are new places for secrets that older ignore files do not cover.
• Keys in the browser: calling a model provider directly from front-end code publishes the key.
• Security by obscure URL: internal agent interfaces left unauthenticated because their paths seemed unguessable.

Framework mapping

Practitioner checklist

• Keep an exposure register of public AI assets, endpoints, configuration and secrets.
• Enforce push protection and scan full history, including staff and contractor public repositories.
• Exclude agent settings folders and transcripts from repositories, packages and images.
• Keep AI provider keys out of client-side code.
• Use per-application, scoped and short-lived AI credentials with spend limits.
• Review public talks, docs and examples for AI architecture detail.
• Plant monitored canary AI keys and endpoints.
• Revoke before cleanup, then review logs for the exposure window.

Standards and references

• MITRE ATLAS: Search Open Websites/Domains
• MITRE ATLAS: Code Repositories
• MITRE ATLAS: AI Honeypots
• MITRE ATT&CK: Search Open Websites/Domains: Code Repositories
• GitHub Docs: Secret scanning partner program
• GitHub Docs: Supported secret scanning patterns
• Hugging Face: User access tokens

Related NHI Mgmt Group resources: MITRE ATLAS Guide · Git Secret Scanning Guide · How to find LLM API keys in code and CI · MITRE ATLAS Mitigations Guide