Verifiable use policies for vehicle surveillance data

1The problem is the query, not the camera

Public debate about plate-reader networks tends to be framed as a debate about cameras — where they are, how many, what they see. That framing misses where the harm actually occurs. A camera records a plate, a timestamp and a location; the record is inert until someone asks for it. The harms that have driven cancellations are harms of asking: an officer who queried a former partner's plate, a department whose data was searched tens of thousands of times by out-of-state agencies without its knowledge [5], a driver stopped at gunpoint on the strength of an alert for a vehicle that had already been recovered [2].

Three properties of current deployments make the query layer the weak point. First, permissions are granted per tool — an authorized user can run any search the interface allows — while consequence lives in the parameters: one plate over 48 hours and every vehicle near an address over 30 days are the same permission. Second, the use policy, where one exists, is a document rather than a control; it is enforced by training, by a text box for a "reason," and by periodic audit. Third, the record of use is held by the vendor, in a form the jurisdiction cannot independently verify, so a council asked "is the policy being followed?" can only relay what it has been told.

The vendor response, announced in August 2026, moves in the right direction: mandatory case codes for searches, an audit tool that flags abnormal activity and suspends users, per-community restrictions on which outside agencies may search and for which offense categories, and a recommended retention of seven days [2]. These are controls, and they matter. But they remain controls that the vendor designs, operates and reports on. A jurisdiction that wants to keep the cameras and regain trust needs something it can point to that does not depend on the vendor's good faith: a rule it wrote, enforced before each request executes, with evidence it can check.

2Threat model

We consider a plate-reader database D accessible through a query interface used by sworn officers, civilian analysts, partner agencies and, increasingly, automated systems (hotlist alerting and natural-language search assistants that compile prompts into queries). The jurisdiction J that owns the cameras has adopted a use policy P — by ordinance, statute or department order — and wants P enforced. We assume the vendor is honest-but-curious: it runs the service as specified but its logs and reports are not independently verifiable. We assume some requesters are malicious or careless, and that the interface itself may be driven by an AI assistant that can be manipulated through its inputs.

The failure classes we want to prevent, each drawn from documented incidents, are:

• Personal-purpose lookup. A single plate queried for reasons unrelated to any case: an ex-partner, a neighbor, a public figure. The signature is repetition without case activity.
• Over-broad scope. A legitimate case used to justify a query far wider than it needs: long windows, area searches returning thousands of non-suspects, bulk exports.
• Unauthorized sharing. Records leaving the jurisdiction's custody to agencies without an agreement, or for purposes the jurisdiction has prohibited (several cities specifically bar immigration enforcement).
• Wrongful automated action. A stop initiated from a low-confidence read, a stale hotlist entry, or a cross-state plate collision.
• Sensitive-location inference. Sightings at clinics, places of worship, schools or protests, which reveal protected activity even when each sighting is individually lawful.
• Assistant manipulation. A natural-language query that carries an instruction to the assistant, or whose compiled form exceeds what the visible prompt asked for.

Out of scope: attacks on the cameras or the network transport, compromise of the vendor's storage, and the policy question of whether a jurisdiction should operate plate readers at all. The gate enforces whatever P says; it does not decide what P should say.

3Design

3.1The request is the unit of governance

Every interaction with D that can cause harm is modelled as a request with explicit parameters: the tool (lookup, history, share, initiate_stop, search), the subject scope (how many plates; a plate or an area), the temporal window, the camera set, the case reference, the requester and their role, the recipient (for shares), and the effect (returns records; copies records out of custody; directs units to a person). A natural-language assistant does not submit its prompt; it submits the compiled request, and the compiled request is what is validated. This single choice defeats a large class of prompt-level manipulation, because an instruction hidden in the prompt can only take effect by producing a compiled request that the policy then sees.

3.2Policy owned by the jurisdiction

The policy P is expressed as versioned rules the jurisdiction controls, keyed to the request parameters. A representative policy, modelled on the strongest state statutes and the Policing Project's model statute [6], includes: a case reference is required for every query; retention is 30 days with proof of purge (Virginia's HB 2724 requires deletion within 30 days absent an active investigation [7]); history queries beyond seven days require judicial authorization; area and bulk queries require a warrant; sharing is limited to agencies with a memorandum of understanding, case-specific, and never for prohibited purpose categories; sightings inside listed sensitive locations are withheld from results; automated stops require a read-confidence floor, hotlist freshness, and human confirmation; and a signed report is delivered to the governing body quarterly. Because the policy is data, a council can change the seven-day window to five, or add a prohibited purpose, and the change takes effect on the next request with a new policy version recorded in every subsequent attestation.

3.3Consequence-proportional validation

Thorough validation is expensive: checking a request against an officer's behavioural baseline, scanning query text for injected instructions, or reasoning about whether a stated purpose plausibly covers a stated scope can each require a model inference. Applying that depth to every request is what makes governance controls get switched off in practice. We instead compute a blast radius for each request from its own parameters — a scalar that grows with the number of subjects, the length of the window, the breadth of the camera set, whether records leave custody, and whether the effect acts on a person — and map it to a validation tier. A tier-0 request (one plate, 48 hours, in-jurisdiction, case-linked) is validated by rules alone in well under a millisecond. A tier-3 request (an area query, a bulk export, an instruction-carrying prompt) receives full inspection across all four proof dimensions with model-backed checks. Between them, effort scales with what the request could do. In our reference implementation on a synthetic workload, proportional allocation reduced model invocations by 44% against uniform deep inspection while every high-consequence request still received full treatment [8]. The same mechanism appears, in a different domain, in our work on AI tool-call validation, where SELECT … WHERE id = 42 and DELETE FROM users arrive with the same permission and receive very different scrutiny.

3.4Four proof dimensions

Each request is evaluated in parallel along four dimensions, which together determine a disposition of permit, escalate (withhold pending a named human) or block:

• Guardrails — scope limits, window limits, bulk-export limits, the blast-radius tier itself, and the escalation path that applies.
• Explainability — case linkage, stated purpose, read confidence for automated actions, and whether the rationale accounts for the scope requested.
• Resilience — repeat-query patterns on the same subject by the same requester, deviation from the requester's baseline, injected instructions in query text, off-hours or unregistered-device access, and cross-jurisdiction drift.
• Compliance — the ordinance itself, the sharing-agreement registry, the sensitive-location list, hotlist freshness, audit-log completeness, and retention.

The dimensions are not decorative. A personal-purpose lookup typically passes guardrails and compliance (one plate, valid case number) and fails only on resilience, where fourteen queries in thirty days with no case activity match a misuse pattern. An immigration-purpose share fails compliance and explainability while passing everything else. Reporting the dimension, and the specific check within it, is what makes the evidence useful to a reviewer.

3.5Pre-execution, with a human in the loop where it matters

The gate sits in the request path: nothing reaches D, leaves custody, or is dispatched until a disposition is recorded. Escalation is a first-class outcome rather than a failure mode — a 30-day history request is not wrong, it is a request that the policy says a watch commander must approve, and the gate routes it there with the evidence attached. Automated stops are always at least escalated to a dispatcher for visual confirmation of the plate image, so the system never directs units to a person on its own authority.

4A taxonomy of requests and their blast radius

Table 1 lists the request types we have encountered in policy documents, audit reports and vendor interfaces, with an illustrative blast-radius value and tier from the reference implementation's default policy. The values are not universal constants; they are outputs of a scoring function a jurisdiction can tune. What should be stable across jurisdictions is the ordering: a case-linked single-plate lookup is the cheapest thing the system does, and a bulk area query or a full-network export is the most expensive, regardless of who is asking.

Two requests in Table 1 share a tool and a permission — a single-plate lookup with and without a case reference — and differ by one field. A permission system cannot tell them apart. A gate that reads the parameters can, and the difference is the entire policy.

5Evidence and public reporting

5.1Attestations

Every disposition, including permits, produces an attestation: a structured record naming the jurisdiction, the policy version, the request category and parameters (with the plate and the requester's identity redacted to stable pseudonyms), the blast radius and tier, the outcome of each check that ran, the disposition, the routing (executed; escalated to a named role; withheld with a reason category), and the measured latency. The record is hashed, the hash is chained to the previous record, and the chain head is signed by a key the jurisdiction controls. Two properties follow. A single record cannot be altered after the fact without breaking the chain; and the absence of a record is itself detectable, because the sequence has no gaps. This is the difference between "the vendor's audit log shows no misuse" and "here is a log in which misuse could not have been hidden."

5.2The public report

Most jurisdictions that publish plate-reader statistics publish counts supplied by the vendor. A transparency report built from attestations is different in kind: each figure — requests by category, dispositions, escalations by reviewer role, blocks by violation category, shares by recipient class, hotlist stops confirmed versus declined — is an aggregate over records whose digests are published alongside it. An auditor, a journalist or a resident with the verifier can confirm that the published totals are consistent with the signed log, and can do so without access to any plate, name or location. What the report does not contain is as important: it does not reveal who was searched or by whom, and it is designed so that the counts cannot be used to re-identify an individual query. This is the mechanism Virginia's annual-report requirement reaches for [7] and that the Policing Project's scorecard rewards [6], with the addition that the numbers are checkable.

5.3Proof of purge

Retention limits are only as good as the evidence that deletion happened. The gate records, at each purge, a Merkle root over the identifiers of the deleted records and signs it. A later query that returns a record older than the retention window is then not merely a policy violation but a contradiction of a signed statement, which is the standard a council should be able to hold a vendor to.

6Deployment

The gate is deployed as a proxy in front of the vendor's query interface — the same pattern our tool-call gateway uses in front of an MCP server — so the vendor's system is not modified and the jurisdiction's policy is applied to every path, including partner-agency searches and the vendor's own assistant. Three deployment properties matter in practice.

Monitor mode first. The gate ships in a mode where every request is assessed, validated and attested but none is withheld. A department runs it inline for a reporting period, then reads the shadow report: what would have been escalated, what would have been blocked, and why. This is how a policy gets calibrated against real workload before it has teeth, and it is how a council sees, in numbers, what its ordinance would change. Only then is enforcement enabled, tier by tier if preferred.

The policy belongs to the jurisdiction. Policy files and signing keys are held by the city, not the vendor and not us. A change in vendor does not change the policy or the evidence format; a change in policy is a versioned event that every subsequent attestation records.

Human roles are explicit. Escalation routes name roles — watch commander, dispatcher, records supervisor — and the reviewer's decision is itself attested. Reviewer response time and override rates become part of the public report, which makes the human step accountable rather than a rubber stamp.

7Evaluation plan

The reference implementation runs on synthetic workloads, and we are careful not to report catch rates from synthetic data as if they were field results. The evaluation we propose, and would conduct with a pilot jurisdiction, has three parts.

Replay. Run the gate in monitor mode over a department's historical query log (with plates and identities pseudonymized at ingest) and compare its dispositions against the department's own audit findings for the same period. The questions are precision and recall against known misuse, and the false-escalation rate on legitimate work.

Cost. Measure model invocations and latency per request under proportional allocation versus uniform deep inspection on the same log, reporting the invocation count as the primary figure because it is independent of the model backend.

Adversarial. Have a red team attempt each failure class in Section 2 through the interfaces a real requester has, including the natural-language assistant, and report which attempts reached the database. The plate-reader setting is unusually well suited to this because the harmful behaviors are concrete and enumerable.

We will publish the protocol before the results, and the results whatever they are.

8Limitations

A gate enforces a policy; it cannot make a bad policy good. A jurisdiction that permits 90-day retention and unrestricted sharing will have those choices faithfully enforced and faithfully reported. The transparency report will at least make the choices visible.

Behavioural checks — repeat-query patterns, baselines, off-hours access — produce false positives, and a false positive here is an officer whose legitimate search is delayed pending a supervisor. Monitor mode and per-tier enforcement exist to keep that cost visible and tunable, but it is a real cost and we do not want to minimize it.

The gate sees requests, not intentions. An officer with a valid case number who queries one plate once for a bad reason is indistinguishable from one doing their job, and the gate will permit both. What the gate changes is that the request is attested, so the later discovery that the case was a pretext has a record to attach to, and the repetition that usually accompanies personal-purpose surveillance is caught early.

Finally, this is a working paper describing a design and a reference implementation, not a field study. Section 7 is a plan, not a result.

9Related work

Purpose-based access control formalizes the idea that access should depend on the stated purpose of a request rather than the identity of the requester alone [9]; our case-linkage and purpose checks are an instance of it with the purpose bound to a case record rather than a free-text field. Tamper-evident logging via hash chains and Merkle trees is well established, most visibly in Certificate Transparency [10], and our attestation chain and proof-of-purge borrow directly from that design; the novelty here is applying it to the disposition of individual surveillance queries and publishing verifiable aggregates. Consequence-proportional validation — spending inspection effort according to the potential impact of an action rather than uniformly — is the organizing idea of our own work on AI tool-call gateways [8]; this report transfers it to human and semi-automated requesters. The Policing Project's model statute and state scorecard [6] define the policy targets we enforce, and the Institute for Justice's databases of misuse and cancellations [1, 3] are the closest thing to a public ground truth for the failure classes in Section 2.

—References

1. [1] Institute for Justice, "Institute for Justice Unveils New Database Tracking Cancelations of License Plate Reader Contracts," 26 Aug 2026. 145 local governments, June 2025 – August 2026. ij.org
2. [2] Stateline, "Flock Safety tightens safeguards as states, cities question surveillance network," 14 Aug 2026. stateline.org
3. [3] California Globe, "Chandler, AZ Ends Flock License Plate Reader Program After Audit Flags Potential Police Misuse," 12 Aug 2026. californiaglobe.com
4. [4] Palo Alto Online, "Menlo Park overhauls license plate reader sharing after discovering more improper searches," 27 Aug 2026. paloaltoonline.com
5. [5] San José Spotlight, "Palo Alto license plate data searched by hundreds of out-of-state agencies," 27 Apr 2026. sanjosespotlight.com
6. [6] Policing Project at NYU School of Law, ALPR state scorecard and model statute, Aug 2026; reported in Tech Times, "States With License Plate Reader Laws Still Fail Privacy Tests, NYU Finds," 19 Aug 2026. techtimes.com
7. [7] Virginia HB 2724 (2025), automated license plate recognition systems; reported in Independent Institute, "Virginia Passes Plate Reader Oversight Bill," 5 Jun 2025. independent.org
8. [8] Sentinel Labs, pot-gateway: blast-radius-proportional validation for AI tool invocations with signed, chained attestations. Reference implementation and benchmark, 2026. Verifier released under BSD-3.
9. [9] J.-W. Byun and N. Li, "Purpose based access control for privacy protection in relational database systems," The VLDB Journal 17(4), 2008.
10. [10] B. Laurie, A. Langley and E. Kasper, "Certificate Transparency," RFC 6962, IETF, 2013; superseded by RFC 9162 (2021).