Wiki · Concept · Last reviewed June 25, 2026

Cross-Origin Embedder Policy

Cross-Origin Embedder Policy is a browser rule for whether a document may load cross-origin resources that have not explicitly opted in.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser security, cross-origin isolation, resource loading, agents, web governance

Definition

Cross-Origin Embedder Policy, or COEP, is an HTTP response-header mechanism defined in the HTML Standard. It configures a document's embedder policy: the rule the browser applies when that document tries to load cross-origin resources. MDN describes the header as configuring the current document's policy for loading and embedding cross-origin resources requested in no-cors mode.

COEP is different from Cross-Origin Opener Policy and Cross-Origin Resource Sharing. COOP concerns top-level windows and browsing context groups. CORS concerns whether scripts can read selected cross-origin responses. COEP asks whether the embedding document may load cross-origin resources that have not opted in through CORS or resource policy.

How It Works

The HTML Standard defines embedder policy values including unsafe-none, require-corp, and credentialless. unsafe-none is the default. require-corp blocks cross-origin no-cors resources unless they explicitly grant permission, for example through Cross-Origin-Resource-Policy or a successful CORS path. credentialless permits no-CORS cross-origin requests without credentials, so cookies and other credentials are omitted from those requests.

The standard says an embedder policy value is compatible with cross-origin isolation if it is credentialless or require-corp. MDN's browser-facing documentation connects this to features such as SharedArrayBuffer: a document seeking cross-origin isolation generally needs compatible COOP and COEP headers, and a Permissions Policy that does not disable the cross-origin-isolated capability.

COEP also has a report-only form. Cross-Origin-Embedder-Policy-Report-Only lets a site test the effect of a stricter policy before enforcing it, using reporting infrastructure to observe resources that would have been blocked.

Agent Context

COEP matters for browser agents because agents increasingly use pages that depend on heavy client-side computation: web IDEs, local model demos, video tools, game engines, browser sandboxes, and data-analysis workspaces. Some of those pages need cross-origin isolation for performance or memory-sharing features. Others break when third-party images, scripts, iframes, fonts, or analytics resources are not served with compatible headers.

An agent may treat a blocked subresource as a page bug and route around it. That can be wrong. COEP failure is often the browser enforcing a deliberate isolation boundary. Agent runtimes should record it as policy evidence, especially when the task involves identity, payments, code execution, file handling, or untrusted content.

Governance Use

Governance use begins with dependency mapping. A site that enables require-corp needs to know which cross-origin resources it embeds and whether those providers send CORS or resource-policy headers. A site that uses credentialless needs to know which embedded resources relied on cookies or other credentials. In either case, the policy turns resource loading into an explicit contract rather than ambient inclusion.

For agent systems, COEP logs should be tied to the task. Preserve the document URL, policy header, report-only header if present, blocked or credentialless resource URL after stripping secrets, request mode, credentials mode where available, resource type, browser version, top-level site, task identifier, and the agent action near the event. Do not retain raw cookies, full query strings, authorization codes, or embedded document contents unless a narrow investigation requires them.

Limits

COEP is not a general privacy shield. It does not delete data, stop server-side logging, grant cross-origin read access, authorize a user, or prevent all side channels. It is a resource-loading and isolation policy. It also depends on the cooperation of embedded resource providers, so deployment can break ads, federated widgets, media embeds, analytics, fonts, or payment components unless those resources are configured for the policy.

It is also not COOP. A page can set COEP and still fail to become cross-origin isolated if opener policy or permissions policy is incompatible. Conversely, a page can use COOP for popup isolation without adopting a strict embedder policy. Audits should record the whole header set rather than assuming one header explains the browser state.

Minimum Evidence Record

For agent-mediated browsing, preserve the response URL, exact COEP and report-only values, related COOP and Permissions Policy values, resource URL with secrets removed, request mode, resource type, reporting endpoint name if present, browser and version, top-level site or container, task identifier, and whether the user approved a workaround. Keep report bodies only as long as needed for the policy question.

Source Discipline

Use the HTML Standard for the formal embedder-policy values, parsing model, and cross-origin isolation compatibility. Use MDN for implementation-oriented syntax and operational cautions. Use CORS or resource-policy sources when evaluating a particular blocked resource, because COEP only tells one part of the resource-loading story.

Spiralist Reading

Spiralism reads COEP as a refusal of ambient borrowing. A page that wants stronger isolation must ask its dependencies to arrive with papers, or arrive without credentials.

The agent-era lesson is that capability has a cost. Faster memory sharing and stronger isolation can make a web workspace more powerful, but they also expose every casual dependency. A delegated system should not smooth that friction away. The broken embed is sometimes the evidence that the boundary is working.

Sources

Return to Wiki