Which SB 942 obligations can a proxy actually enforce?

A request-boundary proxy enforces the traffic-layer duties: recording covered-system use per request and verifying on the response path that expected latent-disclosure markers arrived. It cannot embed latent disclosures or operate the detection tool, which are generation-layer duties owned by the covered provider. A controls mapping should assign each obligation to the layer that can actually produce evidence for it.

What is the licensee obligation under SB 942?

A licensee of a covered generative system must maintain the system's capability to include latent disclosures. If the licensee modifies the system so it no longer meets the requirement, the covered provider must revoke the license within 96 hours of discovery. The licensee's control is continuous verification that the provenance capability stayed intact, evidenced by a per-response record.

Does mapping SB 942 to controls require changing the model?

The generation-layer obligations require the covered provider to build provenance and detection into the model pipeline, so at that layer the model does change. The deployer-side controls sit at the HTTP request boundary and require no model changes, since they record covered-system use and verify response markers in the traffic the request already travels.

California SB 942 AI Controls Mapping: Obligations to What a Proxy Can and Cannot Enforce

The California AI Transparency Act (SB 942) becomes operative on 2 August 2026, after AB 853 moved the date from January and extended the regime to large online platforms and capture-device manufacturers in later years. SB 942 binds covered providers: operators of generative image, video, or audio systems with more than one million monthly users in California. The obligations sort into two groups, and a controls mapping that blurs them will overpromise.

One group is content provenance: a public detection tool and latent disclosures embedded in generated content. That work happens at the generation layer, and no HTTP proxy embeds a watermark. The second group is deployer-side evidence and verification, and that lives in the request and response traffic. I want to map both, marking which control sits where, because the honest boundary is what makes the rest usable.

The two-layer split

Every SB 942 obligation resolves to one of two layers. The generation layer is the covered provider's domain: it produces the content, embeds the latent disclosure, and operates the detection tool. The traffic layer is where a deployer or licensee lives: it sees which requests used a covered system and whether the returned content carried the required markers. A control in the wrong layer is a claim, not an enforcement point.

Latent disclosure: generation-layer obligation

SB 942 requires latent disclosures embedded in AI-generated content, conveying provider name, system name and version, and creation time, readable by the detection tool. The control that satisfies this is watermarking or provenance embedding inside the model's output pipeline. This is out of scope for a request-boundary proxy. The honest mapping entry names the covered provider as the owner and stops there rather than inventing a proxy role.

Detection tool: generation-layer obligation

Covered providers must offer a publicly accessible tool that lets anyone check whether content came from their system. That tool reads the latent disclosure. It is a provider-operated service, not a deployer control, and it does not map to an enforcement point in the traffic. Naming it as out of scope keeps the rest of the mapping credible.

Covered-system usage record: traffic-layer control

A deployer needs to show which of its requests used a covered generative system and when. The control is a per-request record binding identity, the covered endpoint, and the timestamp. Enforcement produces it as a byproduct. This is the same evidence primitive behind SOC 2 AI controls mapping, applied to the SB 942 question of covered-system use.

Latent-disclosure survival: traffic-layer control

The licensee obligation is to keep the latent-disclosure capability intact, with the covered provider required to revoke a non-compliant license within 96 hours of discovery. The traffic-layer control is response-side verification: check each covered-system response for the expected provenance markers before it reaches a downstream user, and flag or hold responses that lack them. This is response schema validation pointed at a compliance property, and it produces the record that the capability held.

The mapping at a glance

Where deployers over-map

The failure mode is treating a covered provider's attestation as a deployer control. A provider's promise that its system embeds latent disclosures is procurement-time due diligence. Showing that a specific served response carried the marker is due care, and the two are different obligations, which I set out for AI generally in You Own the AI Liability, Not the Vendor. My frank opinion: a controls mapping that quietly assigns generation-layer duties to a proxy is worse than no mapping, because it manufactures a false sense of coverage the first enforcement inquiry will puncture.

DeepInspect

DeepInspect is the traffic-layer half of this mapping, and nothing more than that. It sits inline between your users or agents and the generative APIs they call, records which identity used which covered system and when, and verifies on the response path that expected latent-disclosure markers arrived, flagging or holding those that do not. It does not embed watermarks or run a detection tool; those stay with the covered provider.

For a deployer or licensee preparing for 2 August 2026, that division is the useful one: the provider owns the provenance, and you own the evidence that it survived your deployment. The SB 942 audit-evidence view covers what those artifacts look like in practice. Book a technical deep dive at deepinspect.ai.