Your own product pages, documentation, support portals and job adverts often tell an attacker which AI you run, how it is wired into your workflows and where untrusted input can reach it. MITRE ATLAS records this as AML.T0003 Search Victim-Owned Websites, a Reconnaissance (AML.TA0002) technique that mirrors MITRE ATT&CK T1594 and is rated Demonstrated. ATT&CK already covers the general technique: departments, staff names, locations and business relationships found on corporate sites. This guide covers only the AI-specific angle: what your websites disclose about AI-enabled products and services, the two ATLAS case studies, the single mitigation ATLAS maps (AML.M0000 Limit Public Release of Information), and how to audit and reduce what your sites give away without breaking transparency obligations. It is for AI product owners, web and content teams, application security and threat intelligence analysts.
Key takeaways
- Your own site is a first-party source. ATLAS notes that victim-owned websites may contain technical details about AI-enabled products or services, which attackers use to tailor adversarial attacks and to decide what to research next.
- Integration announcements map attack paths. In ATLAS case study AML.CS0039, researchers learned from public information how an AI integration worked and where public service portals accepted external input, then demonstrated a prompt injection path through them.
- Feature-level detail helps evasion. In AML.CS0014, public documentation that an antimalware product used ML detectors was enough to make it a target; the researchers then showed feature knowledge alone supported an evasion attack.
- One mitigation is mapped. AML.M0000 Limit Public Release of Information: restrict technical detail on AI-enabled products and organisational detail about the teams behind them.
- Disclose deliberately, not accidentally. Some AI disclosure is required or valuable to customers. The goal is to publish what users need and keep out what only an attacker needs.
What the technique covers in the AI context
The ATLAS entry (release 2026.10) follows the ATT&CK description: victim-owned websites may list departments, locations and key employees with their roles and contact details, and may describe business operations and relationships. ATLAS adds one sentence that defines the AI angle: such sites may contain technical details about the organisation's AI-enabled products or services. ATLAS says this information can help adversaries tailor attacks, naming AML.T0017 Develop Capabilities (sub-technique AML.T0017.000 Adversarial AI Attacks) and AML.T0043.003 Manual Modification, and can point to further reconnaissance such as AML.T0000 Search Open Technical Databases and AML.T0001 Search Open AI Vulnerability Analysis.
The boundary with neighbouring techniques is simple. AML.T0003 is the organisation's own web estate. Third-party sites, search engines and public code repositories fall under AML.T0095 Search Open Websites/Domains. Probing a live AI service is AML.T0006 Active Scanning. Working out a model's ontology from its outputs is AML.T0013 Discover AI Model Ontology.
What attackers look for on your sites
The table lists the AI details that commonly appear on corporate web estates and what each tells an attacker. It is a checklist for your own audit, not a description of any specific incident.
| Where it appears | AI detail disclosed | What it helps an attacker do |
|---|---|---|
| Product and marketing pages | That a product uses ML or an LLM, which model provider or family, what the AI decides (fraud scoring, malware detection, content moderation) | Choose a target and research known weaknesses of that model family (AML.T0001) |
| Integration and release announcements | Which business systems an AI assistant or agent connects to, and what actions it can take (summarise, reply, classify, update records) | Find where untrusted input reaches an agent with internal permissions, as in AML.CS0039 |
| Public support, service and request portals | That external submissions land in a system an AI tool later processes | Identify an indirect prompt injection entry point (AML.T0051.001) |
| Developer documentation and API references | Endpoints, input formats, model versions, rate limits, confidence scores returned | Plan query-based attacks against an AI inference API |
| Technical blogs, white papers and conference pages | Model architecture, features used, training data sources, evaluation results | Build a proxy model or craft evasion inputs, as in AML.CS0014 |
| Careers pages and team pages | ML frameworks, cloud AI services, MLOps tooling, names and roles of AI staff | Infer the stack and pick people for social engineering |
| Page source, scripts and embedded widgets | Chat widget configuration, AI service endpoints, agent identifiers | Locate interfaces to probe directly |
| robots.txt, sitemap.xml and hidden paths | Unlinked documentation, staging AI demos, internal tool paths | ATT&CK notes adversaries use these files to find hidden content |
ATLAS case studies
AML.CS0039 Living Off AI: prompt injection via a service management platform
Cato Networks researchers (June 2025) began with public information: the vendor's announcement of a remote MCP server bringing AI actions such as ticket summarisation, auto-replies and classification into its service management and wiki products, and a search showing that many organisations' public service portals were reachable. ATLAS maps that step to AML.T0003. The demonstrated attack then needed no access to the AI service itself: an external user submits a ticket containing injected instructions, a support engineer processes it with an MCP-connected AI tool, the instructions run with the engineer's permissions, and internal data is written back into the ticket where the submitter can read it. The researchers recommended least privilege for AI-driven actions, rules that block or alert on MCP tool calls that create or edit data, audit logs of MCP activity and treating untrusted input to AI systems as a critical risk. The lesson for AML.T0003 is that the announcement and the public portal together told an outsider exactly where to aim.
AML.CS0014 Confusing antimalware neural networks
Kaspersky's ML research team (Securelist, June 2021) studied a grey-box attack on one of its own ML malware detectors. ATLAS maps the reconnaissance step to AML.T0003 because the company's use of ML-based detectors was publicly documented on its website. The research showed that an attacker who knows how features are built, and can see verdicts, can train proxy models and craft modified files that evade the original model. The article also states that its products do not rely on the ML model alone, combining static and dynamic features, cloud statistics, rules and analyst review. The lesson is about depth of disclosure: saying a product uses ML is low risk; publishing the feature set and scoring behaviour of a security-relevant model is higher risk.
Reduce what your sites disclose: AML.M0000
ATLAS describes AML.M0000 as limiting public release of technical information about the AI stack used in products and services, and considering limits on organisational information (locations, researcher names, department structures) from which AI techniques, architectures or datasets could be inferred. For this technique ATLAS specifically says to restrict technical information on ML-enabled products and organisational information on the teams that support them. A practical programme:
- Inventory the web estate. List every domain and subdomain you own that carries product, documentation, support, careers or investor content, including help centres and portals hosted on SaaS platforms under your name. See the Attack Surface Management Guide.
- Crawl it as an attacker would. Collect pages and files mentioning AI, ML, LLM, model names, agent, copilot, MCP, embeddings and similar terms, plus robots.txt, sitemap.xml and page source for widget configuration and endpoints.
- Classify each disclosure. Use three classes: required (legal or contractual transparency), useful to customers (what the AI does, its limits, how to get a human), and attacker-only (model versions, feature sets, thresholds, internal integration details, endpoint addresses, named staff with AI security roles).
- Remove or generalise attacker-only detail. Describe outcomes rather than architecture. Move integration detail that customers need behind authentication.
- Add an AI review step to publishing. Product launches, engineering blogs, conference talks and job adverts go through a short check against the classes above. Job adverts can list skills without naming internal systems.
- Review public input points that feed AI. Forms, portals and inboxes whose content an assistant or agent later reads are both discoverable and an entry point. Decide whether each needs AI processing, and if so what the agent may do with it.
- Re-audit on change. Repeat after every AI launch and at least each quarter.
Balancing transparency
Do not confuse reducing attacker-only detail with hiding AI use. Some disclosure is required, for example the transparency obligations covered in the EU AI Act Article 50 Transparency Obligations Guide, and clear notices help users judge AI output. A notice can say that a feature uses AI, what it is for and how to reach a person, without naming model versions or internal integrations. The AI Transparency Notice Template is a starting point.
| Disclosure | Keep public | Generalise or restrict |
|---|---|---|
| AI use in a product | That AI is used, for what purpose, its limits | Model provider and exact version, unless contractually or legally required |
| Integrations | Which customer systems a feature works with | Internal connectors, permission scopes, auto-approval settings |
| Security-relevant models (fraud, malware, moderation) | That ML contributes to decisions | Feature sets, thresholds, scoring behaviour, training data sources |
| Teams | Leadership and public spokespeople | Full rosters of AI and ML security staff with contact details |
| Developer documentation | Public API contract for customers | Staging endpoints, internal model routing, unlinked pages exposed via sitemap |
Where identity fits
AML.CS0039 shows why reconnaissance on your own sites becomes an identity problem: the attacker never authenticated, but the AI tool acted with an employee's permissions. When public pages reveal that an agent processes external submissions, the controls that limit harm are on the agent's identity: separate non-human identities for agents, tokens scoped to the minimum tool set, approval for write actions, and logs that tie every tool call to the identity that made it. See the Agent Identity and Access Guide.
Detection and measurement
Browsing public pages looks like normal traffic, so detection here is weak and mainly useful as context once a later-stage attack appears. Worth collecting from web server and CDN logs:
- Unusual crawling of AI-related documentation, release notes and API reference pages, especially by clients that then request unlinked paths listed in robots.txt or sitemap.xml.
- Requests for chat widget configuration or AI endpoint paths from sources that never load the main page.
- Repeated submissions to public forms or portals that feed AI processing, especially long free-text fields with instruction-like content.
| Metric | What it shows |
|---|---|
| Attacker-only AI disclosures found per audit, and time to remove them | Whether AML.M0000 is working |
| Share of AI-related publications that passed the AI review step | Whether the publishing control is followed |
| Public input points feeding AI processing, with documented agent permissions | Exposure of the CS0039 pattern |
| Unlinked AI-related paths exposed via robots.txt or sitemap.xml | Hidden content an attacker can enumerate |
How to test
- Run a passive reconnaissance exercise against your own estate, with a time box, using only what an unauthenticated visitor can see. See the OSINT and Reconnaissance Guide.
- Write the attacker's brief. From the findings alone, list which models, integrations, input points and people an attacker would target. If the brief is specific, the disclosure is too.
- Trace each input point. For every public form or portal that feeds AI, confirm in a test environment what the agent can do with a submission, using a harmless marker instruction rather than a harmful payload.
- Feed results into red teaming. Use the brief to scope AI red team work (see the AI Red Teaming Guide).
Common failure patterns
- Launch posts written for engineers, published to everyone. Integration detail useful to an attacker goes out in a press release because nobody reviewed it for security.
- Public forms feeding privileged agents. A web form becomes a record that an AI agent later reads with broad access. In the ForcedLeak 2025 research, a public web-to-lead form carried hidden instructions that an agent later followed.
- Security model internals in marketing. Detailed feature or threshold descriptions of fraud or malware models support evasion, the concern AML.CS0014 illustrates.
- Forgotten pages. Old demos, staging documentation and unlinked pages stay reachable through sitemaps and robots.txt.
- Careers pages as stack diagrams. Job adverts listing internal AI platforms, versions and team structure.
- Over-correction. Removing required AI notices to reduce exposure, which creates a compliance problem and does little against an attacker who can see the AI feature in use.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0003 Search Victim-Owned Websites (AML.TA0002 Reconnaissance) | This technique |
| MITRE ATLAS | AML.M0000 Limit Public Release of Information | The mapped mitigation |
| MITRE ATLAS | AML.CS0014; AML.CS0039 | Case studies using the technique |
| MITRE ATT&CK v20 | T1594 Search Victim-Owned Websites | The enterprise technique ATLAS mirrors |
| MITRE ATT&CK v20 | T1589 Gather Victim Identity Information; T1591 Gather Victim Org Information | Related reconnaissance on staff and organisation |
Practitioner checklist
- Inventory every web property you own, including SaaS-hosted portals and help centres.
- Crawl it for AI-related disclosures, page source configuration, robots.txt and sitemap.xml entries.
- Classify disclosures as required, customer-useful or attacker-only, and remove or generalise the last.
- Add an AI disclosure check to product launches, engineering blogs, talks and job adverts.
- List every public form, portal and inbox whose content AI processes, and document the agent's permissions for each.
- Scope agent identities that read public input to the minimum tools and require approval for writes.
- Keep required AI transparency notices, written to describe purpose and limits rather than architecture.
- Re-run the audit after each AI launch and at least quarterly.
Standards and references
- MITRE ATLAS: AML.T0003 Search Victim-Owned Websites
- MITRE ATLAS: AML.M0000 Limit Public Release of Information
- MITRE ATLAS: AML.CS0039 Living Off AI, Prompt Injection via Jira Service Management
- MITRE ATLAS: AML.CS0014 Confusing Antimalware Neural Networks
- MITRE ATT&CK: T1594 Search Victim-Owned Websites
- Cato Networks: Cato CTRL PoC Attack Targeting Atlassian's Model Context Protocol
- Kaspersky Securelist: How to confuse antimalware neural networks
Related NHI Mgmt Group resources: AML.T0095 Search Open Websites/Domains · OSINT and Reconnaissance Guide · Attack Surface Management Guide · EU AI Act Article 50 Transparency Obligations Guide