TL;DR: Two unreserved placeholder domains embedded in hundreds of thousands of GitHub files and hundreds of agent skills can serve macOS-only scam pages that evade static checks because the redirect happens after JavaScript runs, according to Manifold Security. That makes documentation-cited domains a live supply-chain risk, especially when agents consume them without verifying current ownership and behaviour.
At a glance
What this is: Manifold Security shows that placeholder domains used in code and agent skills can silently redirect to scam content after page load, making static checks miss an active abuse path.
Why it matters: IAM and NHI teams should treat cited external domains as mutable dependencies, because both human reviewers and agents can inherit risk when ownership, routing, and content change after publication.
Context
Placeholder domains are stand-in hostnames that people copy into code, documentation, and examples when they do not want to name a real target. The governance gap is that these names are often treated as inert text, even though anyone can later register them and change what they serve. That turns documentation into a live dependency with no lifecycle controls, especially when agents consume the reference material directly.
This article extends the earlier browser and computer-use agent security guide problem into a broader supply-chain issue: the browser is not the only place where a trusted citation can turn into an active lure. When the linked hostname changes hands, the trust boundary moves without any change to the original documentation.
Key questions
Q: What breaks when documentation cites a domain that later changes ownership?
A: The trust model breaks because the citation becomes a live dependency whose meaning can change after publication. A hostname that was harmless when copied can later serve ads, scams, or malicious redirects, and nothing in the original document changes to warn readers. That is why citation governance has to include ownership checks and runtime validation.
Q: Why do static security checks miss malicious redirects on parked domains?
A: Static checks usually inspect the URL, the HTML source, or a single fetch response, but the malicious hop may only appear after the browser executes JavaScript. If the page branches on client-side logic, the dangerous destination never exists in the static view. The right control is executed-behaviour review, not just text inspection.
Q: How should teams handle placeholder domains in AI agent workflows?
A: Treat them as unsafe unless they are reserved or under your control. Agents can follow instructions literally and may not challenge a hostname just because it looks like an example. Put guardrails around documentation, browser actions, and code generation so external examples cannot become live attack paths.
Q: What should security teams do when a parked domain starts showing ads or redirects?
A: Assume the domain is no longer inert and inspect the full redirect chain, including any ad network, tracker, or post-load script involved. If the domain sits inside documentation or automation, remove or replace it before it becomes an active dependency. The risk is not the parking page alone, but the downstream path it can open.
Technical breakdown
Why static checks miss placeholder-domain abuse
Static scanners usually inspect text, DNS records, blocklists, or a non-executing fetch. That misses a class of abuse where the initial page looks benign, but JavaScript on the page computes the real destination only after the browser runs it. A text-only request never sees the final redirect, and a User-Agent swap is not enough when the page branches on runtime behaviour or operating system. The control failure is inspection at the wrong layer: the risk lives in executed client-side code, not in the HTML alone. See the Browser and Computer-Use Agent Security Guide.
Practical implication: Treat browser execution as part of validation whenever a cited domain can change ownership or content after publication.
Why macOS-specific cloaking matters for identity and NHI risk
Cloaking makes the same domain look harmless to most checks while serving scams to a narrower target set such as macOS visitors. That matters to identity and NHI governance because automated agents often inherit the same trust assumptions as humans, yet may browse, install, or execute documentation-linked steps without the same caution. If the environment-specific branch is hidden behind JavaScript and ad routing, neither inventory scans nor generic web checks prove the resource is safe. The issue is not only fraud content, but dynamic trust manipulation at the point of use. See the Agentic AI Identity Guide.
Practical implication: Validate cited domains in the same runtime and operating-system conditions your users and agents will actually use.
How advertising chains turn placeholder names into an attack surface
Placeholder domains can sit inside ad networks or parking services, where the first hop is ordinary and the malicious hop is delegated to an external router. That means the visible domain may only be the entry point, while the actual payload is chosen downstream by query parameters, affiliate IDs, and rotating redirectors. The attacker does not need to own the original documentation or the parking page forever. They only need control of the routing path long enough to serve a malicious branch when the right visitor arrives.
Practical implication: Track the full redirect chain, not just the first registered hostname, before approving any cited external dependency.
Threat narrative
Attacker objective: The attacker wants to monetise trusted citations by sending selected visitors to scam pages that generate affiliate revenue or fraudulent sign-ups.
- Entry begins when a reader or agent follows a trusted placeholder domain embedded in documentation, code, or an agent skill.
- Credential or trust abuse occurs when client-side JavaScript and ad routing steer selected visitors, especially macOS users, to a scam page after the initial fetch looks benign.
- Impact is the delivery of scareware or investment fraud, with the browser handed off to a malicious destination that a static check never observed.
Breaches seen in the wild
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Placeholder-domain trust is a governance problem, not a content problem. The risk is not that a page once contained a bad link, but that the cited hostname can later become an attacker-controlled dependency without the document changing at all. That breaks the assumption that a written example is stable over time. Security teams need to govern external citations as mutable assets, especially where code, runbooks, or agents will execute them.
Dynamic delivery defeats static review at the boundary where humans and agents trust the same text. If the malicious branch appears only after JavaScript runs, then text extraction, simple URL checks, and many policy engines will all report a clean result. That is a control gap in runtime verification, not in list hygiene. The practical conclusion is that citation safety has to include executed behaviour, not just declared destination.
The named concept here is citation drift. A domain that looked safe when it was copied into a repository can drift into a different ownership, advertising, or redirect state later. That creates a governance gap between the moment of publication and the moment of use. Treat cited domains as lifecycle-managed dependencies, not permanent examples.
This pattern widens the identity perimeter around AI systems. When agents consume documentation and follow embedded domains automatically, the trust decision shifts from a human reader to a runtime actor that may not challenge the link. That makes browser-using agents and coding agents part of the same exposure surface. Identity teams should assume an agent will operationalise whatever the document points to unless the citation is constrained or revalidated.
The article is really about trust inheritance across supply chains. Reused examples, placeholder hostnames, and agent-readable documentation become a control plane for downstream execution. Once a domain is externally registerable, the original author no longer controls its meaning. Practitioners should treat this as a documentation governance failure with operational security consequences, not as a niche phishing trick.
What this signals
Citation drift is a useful way to think about this class of exposure: a hostname can remain textually unchanged while its ownership, routing, and page behaviour shift underneath you. For security programmes, the control point is no longer just allowlisting, but continuous revalidation of external references in the same runtime context that users and agents will experience.
When AI agents consume repository text, documentation and examples become execution inputs, not passive references. That means external citations need lifecycle controls, testing gates, and ownership review if they are going to survive in an agentic environment without becoming a hidden trust boundary.
For practitioners
- Inventory every external hostname embedded in documentation and code Classify cited domains by ownership, reservation status, and whether the content can change after publication. Flag any hostname that is public, unreserved, or outside your administrative control as a live dependency rather than a harmless example.
- Revalidate cited domains in a real browser Check the rendered page, redirects, and client-side execution path instead of relying on text fetches or blocklist lookups. Test in the operating systems your users and agents actually run, because cloaking can vary by platform.
- Remove placeholder hostnames from agent-facing instructions Replace generic examples with reserved domains or internally controlled fixtures when documentation may be read by AI agents, copilots, or automation. Treat every external citation as an instruction path that an agent might follow literally.
- Monitor redirectors, not just domains Track the intermediate routing domain, query-string parameters, and post-load destination so you can spot when a benign-looking page hands visitors to a malicious tracker or scam endpoint.
Key takeaways
- Placeholder domains are not harmless filler when they remain reachable and transferable on the public internet.
- The abuse here survives because the malicious redirect happens after page execution, which undermines static validation.
- Security and identity teams should treat cited domains as governed dependencies and verify them in the runtime path agents will actually use.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · Browser and Computer-Use Agent Security Guide · AI Agent Identity Security Buyer's Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The cited placeholder domains become risky when their content and redirects change after publication. |
| NHI-03 — Vulnerable Third-Party NHI | Documentation-linked hostnames act like third-party dependencies once they are consumed by agents or automation. | |
| NHI-10 — Human Use of NHI | The article shows humans and agents both rely on the same citations, extending trust beyond intended use. | |
| Recommendation — Revalidate externally cited hostnames and revoke any that have become mutable dependencies. Treat third-party hostnames in automation as governed dependencies and inventory their owners. Constrain where humans and agents may use external citations in operational workflows. | ||
| MITRE ATT&CK | TA0001;TA0009;TA0010 — Initial Access; Collection; Exfiltration | The abuse path uses trusted citations and post-load redirects to deliver scam content and collect conversion signals. |
| Recommendation — Map citation abuse to initial access and collection paths, then hunt for redirect-driven payload delivery. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Allowing external, uncontrolled hostnames in workflows creates unauthorised access to risky destinations. |
| Recommendation — Restrict which hostnames automation and agents may resolve, fetch, or follow. | ||
Key terms
- Placeholder Domain: A placeholder domain is a stand-in hostname used in examples, documentation, or code when the author does not want to reference a real target. It becomes risky when it is publicly registerable or no longer controlled by the original author, because later ownership changes can turn a harmless example into an active delivery path.
- Citation Drift: Citation drift is the security condition where a referenced hostname, URL, or external resource keeps the same text but changes meaning, ownership, or behaviour over time. In practice, it creates a gap between the moment something was copied into documentation and the moment a human or agent uses it.
- Cloaking Techniques: Cloaking techniques are methods attackers use to hide their real environment or identity from detection systems. In this article, they include creating virtual environments, cloning browser fingerprints, and changing device settings so traffic looks more like a genuine user than a fraudster.
- Redirect chain: A redirect chain is a sequence of intermediate links that forwards the victim from an initial lure to the final malicious page. Attackers use it to hide the destination, defeat static URL analysis, and exploit trusted services that are less likely to be blocked early.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps teams govern machine access paths. It gives practitioners a common language for controlling the identity layer that underpins modern automation and agentic workflows.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org