You were sent a link. What did you actually open?

A teammate shares a Claude artifact, a slick little dashboard, say. You click it. It looks exactly like what was promised: a clean, interactive page. Job done.

But "a page" is doing a lot of hidden work in that sentence. Most people file artifacts mentally next to a Google Doc or a PDF: a document, static, inert, safe to open. That instinct is right for some artifacts and quietly wrong for others, and nothing on screen tells you which one you're looking at.

To use artifacts confidently, you have to know what one actually is under the hood. And there are two answers, depending on where it runs. This guide is the map.

Why artifacts are their own kind of surface

Before the taxonomy, it's worth naming why artifacts deserve their own security thinking rather than being lumped in with "web pages" or "documents."

• It's code you didn't write and never read. An artifact is generated by a model from a prompt. Nobody reviewed it line by line the way you'd review a pull request. You judge it by how it looks, not by what it does.

• It travels by link. Artifacts are made to be shared and imported. The person who opens one is usually not the person who created it, so trust is transitive and mostly implicit.

• It runs live. An artifact isn't a screenshot of an app; it is the app, executing in front of you the moment it renders.

• Its power depends on where it runs. This is the crucial one. The identical artifact is a harmless sandboxed toy in one place and a tool-wielding program in another. Trust is surface-dependent.

That last point is why the rest of this post is organized around the two surfaces.

The two primitives, defined

Chat Artifacts (Claude.ai)

When you ask Claude on the web to "build me a calculator" or "make a dashboard," it produces a Chat artifact: live HTML, CSS, JavaScript, or React that renders in a panel beside the chat.

The important part is how it renders. A Chat artifact runs inside a sandboxed <iframe> in your browser, the same isolation mechanism the whole web relies on. In practical terms that means:

• It runs in its own isolated origin, walled off from Claude.ai itself.

• It cannot read your Claude account credentials, your cookies, or the page hosting it directly.

• It has no bridge to your machine: no local filesystem, no shell, no OS-level access.

• Its network and capabilities are constrained by a restrictive Content Security Policy (CSP).

What it can do has grown, and this is worth being precise about. Through Claude's connector integration (sometimes called interactive connectors or "MCP Apps"), a Chat artifact can now read from and write to remote MCP connectors you enable for that conversation, such as Slack, Google Calendar, Asana, or Figma. The accurate statement is narrower: they can use the cloud connectors you turn on for a conversation, mediated through Claude, but they don't get direct, persistent access to your local machine.

Sharing is explicit: you click Publish, and Claude gives you a public link of the form claude.ai/public/artifacts/…. Anyone with that link, or who finds it, can open the artifact and view its full source.

The mental model that fits a Chat artifact is: a sandboxed mini-website that can call the connectors you've switched on for this chat. It can do what a web page can do, plus reach those cloud connectors, and no more.
Sharing is explicit: you click Publish, and Claude gives you a public link of the form claude.ai/public/artifacts/…. Anyone with that link, or who finds it, can open the artifact and view its full source.

The mental model that fits a Chat artifact is: a sandboxed mini-website that can call the connectors you've switched on for this chat. It can do what a web page can do, plus reach those cloud connectors, and no more.

Cowork Artifacts (Claude Desktop)

Cowork artifacts are more powerful variants that live in Claude Desktop's agentic "Cowork" experience. They look similar on screen, but underneath they are a different animal. Three facts define them:

1. They are real apps, not previews. Claude Desktop writes a complete HTML document, with its own CSS and JavaScript, to disk and run it, the way a browser runs a web page. Any script in that document executes when the artifact opens.

2. They all share one origin. Every Cowork artifact is served from a single internal address:

• cowork-artifact://local

• In web-security terms this is the origin, the boundary that decides what a page may touch. Because every artifact you open shares this one origin, they also share the same localStorage. Data one artifact saves is visible to the next artifact you open. (On the regular web, every site gets its own isolated storage; here they don't.)

3. They can use your connected tools. A Cowork artifact isn't limited to its own page. It can reach the tools you've connected, your MCP connectors: Slack, Google Drive, your filesystem, and so on, through a bridge that Claude Desktop injects into every artifact, exposed as window.cowork.

The mental model that fits a Cowork artifact is not "a web page." It's a small program running on your computer, with a phone line to your connected accounts.

The comparison, side by side

Print this and pin it to a wall. Nearly every practical decision about artifacts comes down to which column you're in.

The rows that matter most are "local machine reach" and "consent model." Both kinds of artifact can now touch cloud connectors; the difference is that a Cowork artifact can additionally reach your local machine, under a grant that persists rather than one scoped to a single chat.

Where the code runs

A picture helps. The two surfaces put the same kind of AI-generated code in two very different places.

Both surfaces can reach connectors now. The difference the diagram is meant to show is what else the Cowork side can touch (your local files and shell) and how directly it gets there. That last part is one teaching point that surprises even experienced engineers:

Tool calls don't travel over the network. They travel over IPC. A Cowork artifact talks to your tools through Electron's inter-process channel (ipcRenderer.invoke), not by making an HTTP request. That matters because the page's network policy, even a strict connect-src: none CSP that blocks all outbound web requests, governs the network, not the bridge. The tool bridge sits below the layer a CSP controls.

You don't need to exploit anything to appreciate the implication: the usual "just lock down the CSP" intuition doesn't fully describe what a Cowork artifact can reach.

The manifest and the bridge: how a Cowork artifact asks for power

A Cowork artifact can't silently grab every tool you own. It has to declare what it wants, in a small metadata block at the top of the document:

mcpTools lists the specific tools it intends to call; mcpServerNames names the connectors those tools belong to. When you first open such an artifact, Claude Desktop asks you to approve the connector.

Once approved, the artifact's own JavaScript can reach your tools through the injected bridge. Here is the real, non-obfuscated shape of that bridge, as it's exposed into every Cowork artifact:

In plain terms:

• callMcpTool is how an artifact uses a connected tool, for example fetching the last 20 messages from a Slack channel to display them.

• askClaude / sample let the artifact ask Claude a question mid-run and use the answer.

• runScheduledTask lets it kick off one of your saved scheduled tasks.

This is the genuinely useful heart of Cowork artifacts: a shared dashboard can pull live data from your actual tools instead of showing fake placeholder content.

The consent and trust model

Here is where the mental model most often drifts from reality, so it's worth stating plainly and neutrally.

When you approve a connector for a Cowork artifact, most people read it as: "I'm letting Claude use my Slack while I chat." What you are actually granting is closer to: "I'm letting the code inside this artifact use my Slack." Those are not the same sentence. Claude is a model you're conversing with; the artifact is a program that runs on its own, including code that can execute the moment the page loads.

Two properties are worth holding in your head:

• Approval is one-time and it sticks. The grant is saved alongside the artifact. You approve once, and the capability persists for that artifact from then on.

• Artifacts are not isolated from each other. Because every Cowork artifact shares the cowork-artifact://local origin, they also share storage. Two artifacts on the regular web would be as walled off from each other as two different websites. Two Cowork artifacts are not.

None of this is a flaw you need to fear on its own. It's the design. But it means the trust you extend to a Cowork artifact is broader and longer-lived than the one-click approval makes it feel.

Understanding the risk surface

The two surfaces fail in completely different ways. Knowing which risk applies to which artifact is most of what practical safety looks like.

Chat artifacts: the everyday risk is the data, not the runtime

The browser sandbox around a Chat artifact is meaningful: it's designed so the artifact can't read your account credentials, touch the host page, or reach your local machine. It can use the cloud connectors you enable for the conversation, so it isn't powerless, but its reach is scoped and mediated. No sandbox is a guarantee, and browser isolation has been broken before, yet in day-to-day use the artifact runtime is rarely where things go wrong.

The far more common problem is what people put inside them, and the fact that "publish" means public. A published artifact lives at a stable public URL, its full source is viewable, and because these links are crawlable and indexable, they can be discovered, not just shared. Anything baked into the artifact is therefore world-readable.

When we've looked at large numbers of public artifacts, the recurring theme wasn't malware. It was ordinary people accidentally publishing real information:

• Personal contact details, such as a real portfolio page carrying someone's email, phone number, and date of birth, all now public.

• Live third-party credentials, such as a working, non-expiring embed token for an external service, copied straight into the artifact's source.

• Unsafe patterns, such as user input passed to eval(), or scripts pulled from a CDN without integrity checks.

The published-artifact risk is overwhelmingly accidental data exposure, not malicious payloads. Treat "Publish" like posting to a public forum, and most of this risk evaporates.

Cowork artifacts: capability is the risk

Cowork flips the picture. The data-exposure concern is smaller (these run locally, for you and your team), but the capability is much larger. Three architectural facts combine into the thing to think carefully about:

• The artifact's code is trusted by default and runs on load.

• All artifacts share one origin and one storage, so they aren't isolated from each other.

• The code can reach your real tools through the bridge, using approvals that persist.

You don't need an exploit to see why that raises the stakes. The right questions to ask about a Cowork artifact are simply: Who wrote this code? What connectors did I approve for it? And what could that code do with those connectors if it wanted to? For a static "team dashboard" the honest answer to "what tools does it need" is often "none," and that's a good instinct to trust.

Using artifacts safely: a framework, not a checklist

You don't need a 40-item hardening guide. You need a few durable principles.

1. Know which kind you're using, and what it can reach. A browser tab on Claude.ai is sandboxed and can reach the cloud connectors you've enabled for that chat, but not your local machine. Claude Desktop and Cowork means a real program that can additionally reach your local files and shell. Let that distinction drive how much you scrutinize it, and how freely you enable connectors.

2. Treat a shared or imported artifact as untrusted code, not a trusted document. The friendly UI tells you nothing about what the code does. "Someone sent me this" is the beginning of your risk assessment, not the end of it.

3. Never publish anything to a public artifact you wouldn't post publicly. No client data, no tokens, no personal details, no internal contacts. "Publish" is publication.

4. Be conservative approving connectors for Cowork artifacts, especially anything touching your filesystem, a shell, or write access. A dashboard that only displays information rarely needs more than read access to one connector, if that. If an approval prompt seems disproportionate to what the artifact appears to do, that mismatch is worth pausing on.

5. For organizations: where your MCP tooling supports managed policies, set high-risk servers to ask or blocked rather than allow-by-default, and treat public-artifact publishing as a data-egress channel worth the same attention you give email or file sharing.

Where this leaves us

Artifacts are one of the more genuinely useful things Claude does. A Chat artifact turns a prompt into a working tool in seconds; a Cowork artifact turns it into a working tool wired to your real data. That power is the point, not a mistake.

The durable lesson is just that "artifact" is not one thing. One version is a sandboxed browser app that reaches only the cloud connectors you switch on for a chat. The other is a program on your machine that can act through your local tools as well. They share a name and a look, and much less than you'd think of what matters for trust. Match your caution to the actual runtime, sandboxed browser app versus privileged desktop program, and you're already ahead of most users.