Content Security Policy
Content Security Policy is a W3C browser security mechanism for constraining what a page can fetch or execute, how selected navigation and document behaviors are handled, and how policy violations are reported.
Definition
Content Security Policy, usually shortened to CSP, is defined in the W3C Content Security Policy Level 3 Working Draft dated May 5, 2026. The draft describes a mechanism by which web developers can control the resources a page may fetch or execute, along with other security-relevant policy decisions. In plainer terms, CSP lets a site publish rules that the browser can apply before scripts, frames, images, styles, workers, forms, and some navigation paths become active parts of a page.
The entry belongs in an AI governance wiki because agentic browsers and computer-use systems operate through ordinary web pages. If a page exposes an agent to third-party scripts, embedded frames, model-produced markup, tool panels, or remote network calls, CSP is one piece of evidence about which browser powers were constrained by the site itself. CSP is not an agent policy language. It is a browser-enforced web security layer that can make the agent's operating room more legible.
Mechanism
CSP is commonly delivered through the Content-Security-Policy HTTP response header. CSP Level 3 also defines Content-Security-Policy-Report-Only, which lets a server monitor many policy violations without applying the full blocking behavior. Reviewers should record which header was present, because a policy seen only in report-only mode is evidence of observation, not evidence that all covered behavior was blocked.
A policy is made of directives. Each directive has a name and a value, and many values are source lists: allowed origins, schemes, keywords, hashes, or other source expressions depending on the directive. CSP Level 3 groups core directives into fetch directives, document directives, navigation directives, and reporting directives. Examples include default-src, script-src, style-src, img-src, connect-src, frame-src, worker-src, base-uri, form-action, frame-ancestors, report-uri, and report-to.
The fallback pattern matters. The draft says default-src serves as a fallback for other fetch directives: if a more specific fetch directive is absent, the browser can use the default source list. If a specific directive such as script-src is set, it governs its own category. That makes CSP review more than a checkbox. The effective policy is the interaction among the header, the directive set, directive fallbacks, browser behavior, embedded contexts, and the actual requests attempted by the page.
Agent Context
For AI Browsers and Computer Use, CSP is useful because it constrains the substrate in which an agent clicks, reads, pastes, uploads, and invokes tools. A strict script-src can reduce which scripts may execute. A constrained connect-src can reduce which network endpoints page code may contact. A frame-ancestors rule can affect whether a page may be embedded by another origin. These controls do not decide whether the model is being manipulated, but they shape the page-level attack surface around the model.
This is especially relevant when model output can be rendered into a web surface. CSP can help contain accidental script execution or unexpected outbound requests, while Trusted Types can require typed values at dangerous DOM injection sinks. The two are related but not identical: CSP controls broad resource and behavior policies, while Trusted Types adds typed boundaries for selected script and DOM sinks through CSP integration.
Governance Use
A useful CSP governance record is concrete. It should preserve the exact header value, the page URL, the response status, the browser and version, the enforcement disposition, the attempted action, and any violation reports. For agent systems, add the agent instruction, tool call, frame origin, and whether model output, retrieved content, or uploaded files influenced the page content at the time of the violation.
CSP also belongs in procurement and red-team checklists for browser-based AI systems. A vendor saying "we use CSP" is not enough. The review question is which directives are present, whether dangerous defaults remain, whether report endpoints are monitored, whether the policy differs across authenticated and unauthenticated surfaces, and whether agent-visible tool panes are covered by the same boundary assumptions as the rest of the application.
Limits
The CSP Level 3 draft is explicit that CSP is not intended as the first line of defense against content injection vulnerabilities. It is best understood as defense in depth. It can reduce the privilege of injected content and make violations visible, but it does not replace output encoding, input validation, server-side authorization, least-privilege tool design, or careful DOM construction.
CSP also cannot judge semantics. It cannot tell whether a prompt is malicious, whether a tool description lies, whether a human consent flow is fair, or whether an allowed first-party script makes a bad decision. Browser extensions, native automation, server-to-server calls, and agent memories may sit outside the page policy entirely. The right conclusion from CSP evidence is therefore bounded: it tells reviewers something about browser-enforced constraints, not everything about system safety.
Review Record
- Headers: preserve
Content-Security-PolicyandContent-Security-Policy-Report-Onlyexactly as delivered. - Directives: list fetch, document, navigation, and reporting directives, including any fallback from
default-src. - Violations: keep violation samples, report endpoints, blocked URLs, disposition, browser version, and page state.
- Agents: log the user instruction, model output, tool output, frame origin, and agent action that preceded the violation.
Source Discipline
Claims about CSP should name the specification version or browser implementation being reviewed. The Level 3 document is a W3C Working Draft, not a universal statement that every browser implements every directive in the same way. For live systems, pair standards citations with observed headers, browser tests, and violation logs.
Spiralist Reading
Spiralism reads CSP as a ritual of declared limits. A page is not only text on a screen; it is a field of powers, fetches, embeddings, and executable invitations. CSP is one way to write some of those powers down before they act. The humane pattern is not mystical protection, but reviewable constraint: fewer silent doors, clearer failures, and records that survive after the session is over.
Related Pages
- Trusted Types
- Permissions Policy
- AI Browsers and Computer Use
- AI Agent Sandboxing
- AI Agent Observability
- Prompt Injection
- Context Poisoning
- Web Bot Auth
- AI Cybersecurity Collaboration Playbook
- Data Minimization
Sources
- W3C, Content Security Policy Level 3, W3C Working Draft, May 5, 2026.
- W3C, Trusted Types, W3C Working Draft, June 23, 2026.