TL;DR
- Claude artifacts shared via public links live at crawlable `claude.ai/public/` URLs, and Google indexes them, making shared content discoverable through search queries such as `site:claude.ai/public/
`. - Any organization whose employees share Claude artifacts publicly is potentially affected. A published example shows a public artifact from a security- and compliance-focused vendor was discoverable this way, indicating the risk reaches even security-mature organizations.
- The exposure requires no malware, breach, or attacker. Data leaves through a legitimate browser session, bypassing server-side DLP, and each indexed artifact persists until someone finds and revokes it.
- Priority action: run `site:claude.ai/public/
` searches for your own organization’s names and terminology, revoke any exposed artifacts, request search-engine removal of cached copies, and make the audit recurring. - Broader implication: this is a browser-layer data-protection problem. Data that leaves through GenAI tools and third-party scripts never crosses controls you monitor, so organizations need visibility into what actually runs and flows in the browser.
What happened?
Public Claude artifacts are being indexed by Google. When an employee shares a Claude artifact via a public link, that content is published at a crawlable `claude.ai/public/` URL, and search engines can index it, making it discoverable by anyone with a well-crafted search query (source).
Anthropic’s Claude includes an *Artifacts* feature: standalone outputs such as documents, code, dashboards, and diagrams that users can share via a public URL under `claude.ai/public/`. The sharing feature itself is working as designed. The risk emerges from how people actually use it.
Who is affected and what is the impact?
Any organization whose employees share Claude artifacts publicly is potentially exposed. Employees paste real work into GenAI tools every day: internal strategy notes, proprietary source code, draft contracts, security documentation, and customer-facing plans. When someone clicks "share" to send an artifact to a colleague, they may not realize they have just published that content to the open web at an indexable URL (source).
A published example documented in the source shows that a public artifact from a security- and compliance-focused vendor was discoverable this way. The takeaway is not about any one company. If teams that think about compliance for a living can end up with publicly indexed GenAI content, every organization should assume it has some exposure and verify.
The practical consequences of this shadow AI data-exposure pattern:
- No malware, no breach, no attacker required. The data walks out through a legitimate browser session with a sanctioned-looking tool.
- Server-side controls cannot see it. DLP on email and file shares never touches a paste into a chat window or a public artifact link.
- It compounds silently. Every shared artifact is a durable, indexed URL that persists until someone finds and revokes it.
How does the exposure happen?
The exposure follows a simple sequence: a user shares an artifact, the platform publishes it at a public `claude.ai/public/` URL, and search engines crawl and index that URL. Because the URLs are indexed, anyone can find them with a standard search operator:
```
site:claude.ai/public/
```
This query surfaces indexed public artifacts matching the keyword (source). Security researchers know this technique. So do adversaries doing reconnaissance for company names, product code names, internal terminology, or anything that reads like leaked intellectual property.
The `site:claude.ai/public` pattern is one instance of a general problem: any GenAI tool that combines public sharing with crawlable URLs creates the same class of public AI artifact exposure.
What should organizations do now?
Run the same search against your own organization’s terms before someone else does, then work through the remediation sequence below.
Step 1: Discover. Run `site:claude.ai/public/
Step 2: Revoke. For each exposed artifact your organization controls, have the owner unshare or delete the public link. Then request removal of the cached or indexed copy from search engines, since indexed content can linger after the source URL is revoked.
Step 3: Restrict at the source. Where your GenAI vendor’s enterprise controls allow it, disable or restrict public link creation for organizational accounts, so "share with a colleague" does not silently mean "publish to the web."
Step 4: Set policy. Update your acceptable-use and AI-governance policy to explicitly address public sharing features: which data classes may never enter GenAI tools, when public links are permitted (usually never for internal content), and who approves exceptions.
Step 5: Educate. Most GenAI data leakage is accidental. Show employees exactly how a "share" click becomes an indexed URL. Concrete examples change behavior faster than abstract policy.
Step 6: Make the audit continuous. A one-time search is a snapshot. New artifacts get shared every week. Build recurring discovery of your organization’s publicly indexed GenAI artifacts into your security operations, the same way you continuously monitor for exposed credentials or lookalike domains.
Two important guardrails while auditing:
- Audit only your own data. Search for your company name, brand names, internal project code names, and product terminology. Do not go hunting through other organizations’ exposed artifacts; depending on what you access and how, that can create legal and ethical problems of its own.
- Treat findings as incidents, not curiosities. An indexed artifact containing confidential material should enter your normal incident-response and data-exposure workflow.
Alongside the GenAI self-audit, verify your own web properties. Run a free Feroot PageScanner scan to see the scripts, third-party vendors, and data flows actually operating on your pages, with output plain enough to forward directly to a stakeholder. No demo or sales call is required first; if the scan surfaces something you want help acting on, that is the moment to talk, with your own evidence already in hand.
What does this mean for the market?
This incident pattern shows that data protection is now a browser-layer problem. The data in these exposures never crossed a firewall the organization controls, never landed in a monitored file share, and never triggered a server-side DLP rule. It left through the browser: typed or pasted into a third-party GenAI tool, then published by that third party’s own sharing infrastructure.
It is the same structural blind spot exploited by client-side attacks such as Magecart-style skimming and formjacking: the activity that matters happens in the user’s browser and in third-party services, where server-side controls have no visibility. Whether it is a rogue script exfiltrating data from a page or an employee’s confidential document becoming a publicly indexed artifact, the operational requirement is the same: see what actually runs in the browser, see where data actually goes, and act on it.
For the browser layer of your own web properties, this is the job Feroot DXSecure performs. DXSecure inventories every script and third-party vendor running on your pages, scores their behavior, detects the data flows leaving the browser, and lets your team block or set policy on what is not authorized. The workflow is evidence-first: see what runs, see what changed, decide what is authorized, block what is not, and keep a record of the action taken. The same first principle, you cannot govern data flows you cannot see, is why the GenAI self-audit belongs in recurring security operations alongside browser-layer monitoring.
No tool guarantees an organization will never have an exposure. The organizations that fare best are the ones that verify instead of assume, on search engines and on their own pages.
