Your CSP Is a Confession: How One Header Reveals Your Entire AI Stack

The header you forgot was public

Content-Security-Policy is a defensive control. It tells browsers which origins a page is permitted to load resources from — a mechanism designed to reduce the impact of cross-site scripting attacks. Most security teams think of CSP as something they send outward, a policy aimed at browsers. Fewer think about what it reveals to anyone who reads it.

The CSP header is delivered with every HTTP response, unauthenticated, to any client that requests the page. It is readable from any network. Security researchers and OSINT practitioners have used it for years as a passive signal for mapping third-party dependencies. In 2026, with AI providers appearing in connect-src directives across hundreds of enterprise domains, the same technique has a new application: mapping an organisation's AI vendor relationships from the outside, without touching any of its systems.

What the header typically reveals

AInforce PromptShield's passive scanner fetches the CSP header from a target domain and parses the connect-src, script-src, and default-src directives for known AI provider domains. Across scans of enterprise domains in 2026, several patterns appear regularly:

• connect-src includes api.openai.com or api.anthropic.com — the browser is permitted to make direct fetch/XHR calls to the provider's API endpoint; this warrants follow-up to determine whether a server-side proxy exists or whether the frontend calls the provider directly
• script-src includes a CDN path for an in-browser ML inference library — indicates that model inference may be running client-side, which has different privacy and IP implications than server-side inference
• connect-src includes both an AI provider and a third-party analytics domain — AI interaction metadata may be flowing to an analytics platform; worth reviewing what that platform receives and retains
• No CSP header present — the organisation has not implemented content security policy; this is a gap in its own right, and means no CSP-based AI vendor mapping is possible from outside (but also that no browser-side controls are enforced)

The most actionable pattern is a direct AI provider domain in connect-src. In most production deployments, this indicates the frontend is configured to call the provider from the browser rather than routing calls through a server-side gateway. That's worth verifying — and, if confirmed, worth understanding the architectural implications of.

What a direct-call architecture actually means

When a frontend application calls an AI provider directly — verified through source inspection, network interception, or endpoint probing, not from the CSP alone — the consequences depend on implementation specifics. But the pattern that concerns security teams most is one where the API key is accessible to the browser: embedded in a JavaScript bundle, returned by an unauthenticated endpoint, or stored in a client-accessible location.

Where this pattern is confirmed, the implications are concrete. The API key is accessible to anyone who can read the page source or intercept the request. Data entered into the AI interface — form fields, support queries, chat messages — travels to the provider without passing through the organisation's own infrastructure, which means no server-side logging, no egress DLP, and no audit record of what was sent. The specific provider relationship is publicly visible, which tells a potential attacker which framework-specific payloads to try.

The point of the CSP check isn't to draw conclusions from the header alone. It's to identify which organisations have a surface worth examining more carefully — and to do so passively, from publicly available information, before any direct probing of systems. For the organisation running the check on itself, it's the first step in understanding whether its AI architecture matches what its security team thinks it is.

Where the major tools have a gap

The enterprise AI security market has produced capable tools over the past eighteen months. Wiz launched AI Security Posture Management in 2026, giving cloud security teams visibility into AI provider connections and model endpoint configurations from within their cloud environment. Microsoft Defender for AI added telemetry for Azure OpenAI API calls. Palo Alto Networks added LLM traffic inspection to its Prisma AI platform within Strata Cloud Manager.

Each of these tools is genuinely useful. They also share a dependency that the CSP finding can surface: they instrument traffic that flows through a layer they control — the cloud account, the Azure endpoint, the network proxy. Traffic that originates in the browser and goes directly to a provider's API, without passing through the organisation's own infrastructure, may not be visible to tools that instrument at the server or cloud layer. This isn't a product limitation so much as an architectural one: if there's no centralised routing layer, there's nothing for centralised monitoring to attach to.

PromptShield's passive scan operates from the other side: it reads what's already public. Where internal tooling gives you depth on known infrastructure, the passive scan surfaces what's inadvertently visible from the outside — including AI vendor relationships that haven't been catalogued internally.

Regulatory and compliance context

Data protection obligations — GDPR, CCPA, sector-specific frameworks like HIPAA — generally require organisations to maintain records of what personal data is processed, by whom, and on what basis. Where personal data flows to an AI provider without passing through a server-side layer, reconstructing those records after the fact is difficult. Whether a specific deployment creates a compliance gap depends on what data is processed, which jurisdiction's rules apply, and the organisation's role as controller or processor. The CSP signal is a starting point for that analysis, not a conclusion.

The EU AI Act, which entered its enforcement phase in 2026, establishes transparency and documentation requirements for high-risk AI systems — a category defined in Annex III of the regulation with specific criteria. Most customer-facing AI assistants are not automatically classified as high-risk, and legal classification requires review of the specific deployment context. Organisations subject to the regulation's documentation requirements do need to maintain records of AI system behaviour; a direct browser-to-API architecture with no server-side logging makes that harder to satisfy. Legal counsel familiar with the specific deployment is the right source for classification guidance.

What the three-pillar model reveals here

The CSP finding is a useful lens for the "AI for staff, spend, and security" framing, because closing the gap it points to unlocks all three layers simultaneously.

The security layer is obvious: the passive scan identifies the surface before an attacker does. The spend layer is less intuitive: where AI calls flow from the browser directly to a provider, the organisation has no server-side record of token consumption per user or per team — PromptShield's finops module requires a centralised routing point to measure. And the staff layer follows: once a server-side gateway exists, IT can enforce which models employees are routed to, apply per-team policies, and instrument which approved tools are actually being used versus which are being bypassed.

The CSP check surfaces the gap. The proxy closes it. The proxy is also the prerequisite for the cost visibility and staff-routing controls that make AI governance operationally tractable rather than theoretical.

MITRE mapping

The passive CSP reconnaissance step maps to a single ATT&CK technique directly. The remaining techniques apply only where follow-up investigation confirms the underlying condition — they cannot be inferred from the CSP entry alone.

• T1590.002 — Gather Victim Network Information: DNS / Network Topology: reading the CSP header to passively enumerate third-party AI provider relationships — this mapping applies directly from the header read
• T1592.002 — Gather Victim Host Information: Software: identifying AI frameworks and inference libraries from script-src entries (e.g. transformers.js CDN paths) — applies where such entries are present in the header
• T1552.001 — Unsecured Credentials: Credentials in Files: API key accessible in a client-side bundle or unprotected endpoint — requires source inspection or network tracing to confirm; not inferable from the CSP entry alone
• AML.T0057 — LLM Data Leakage: sensitive inputs reaching a third-party model without server-side logging or egress monitoring — applies where direct browser-to-API calls are confirmed and no proxy layer exists; not inferable from CSP alone
• AML.T0040 — ML Model Inference API Access: direct access to a model endpoint via a confirmed exposed API key — requires credential exposure to be verified; not inferable from CSP alone

What to do about it

The CSP check is a starting point. The investigation it triggers matters more than the header itself.

First, verify the signal. A connect-src entry for an AI provider warrants a follow-up check: does the frontend actually call the provider directly, or does it route through a server-side gateway that also happens to need the browser to allowlist the origin? Inspect the JavaScript bundle, trace a network request, or review the codebase. If the call is confirmed direct, move to the next step.

Then audit credential exposure. If a direct call is confirmed, determine where the API key lives. If it's accessible to the browser — in the bundle, in a public environment variable, returned by an unauthenticated endpoint — rotate it. Do not rotate based solely on the CSP finding; rotate if and when credential exposure is confirmed, to avoid an outage without demonstrating actual compromise.

Then address the architecture. A server-side AI gateway — LiteLLM, Azure API Management, a lightweight Express or Fastify proxy — is the standard remediation. The backend holds the API key; the browser calls the proxy; the proxy calls the provider. Every AI call is now logged server-side, inspectable, rate-limitable, and auditable. The CSP entry changes from the provider's domain to 'self'.

Ongoing: Add a quarterly CSP audit to the security calendar — not just for AI providers, but for all third-party origins. Any AI provider domain in production CSP that isn't documented in an AI API inventory is a finding worth understanding. The inventory itself — every provider, every key, every team that has one — is the long-term artefact that makes AI governance auditable.