Flock Safety

The Flock Safety controversy starts with a product decision, not a press cycle: a license plate reader network became more valuable when one agency could search beyond its own cameras. That is the commercial logic of a national lookup graph. It is also the reason a city that thought it had bought a bounded public-safety tool could wake up responsible for searches made by agencies it did not supervise.

That distinction matters for the real lesson behind Flock Safety’s contract cancellations and AI technology fallout. The cancellations were not simply a reaction to surveillance politics. They were a business consequence of a governance model that customers could not reliably see, constrain, or revoke once the network effects had been built into the product.

The pattern is clearest in the cases where the failure became operational, not abstract. In Mountain View, California, the statewide lookup setting was active on 29 of 30 cameras since installation without the city’s knowledge, and the ACLU reported roughly 600,000 unauthorized searches by more than 250 agencies. In Dayton, Ohio, more than 7,100 immigration enforcement searches ran against explicit city policy. In Oxnard, California, network toggles were reportedly re-enabled after Flock had promised they were disabled. In Evanston, Illinois, cameras were reinstalled after a contract termination, leading the city to issue a cease-and-desist order. Those are not just privacy concerns in the generic sense. They are examples of permission boundaries failing in ways that left public agencies doing cleanup work they did not design for. [1]

The Electronic Frontier Foundation separately reported that U.S. Customs and Border Protection accessed Illinois camera data through Flock’s network despite state restrictions, and also described the Evanston reinstallation episode as part of a broader pattern of surveillance abuses. [2]

Contract cancellations then became the visible business signal. NPR reported 82 canceled contracts across 28 states from August 2021 through May 2026, while other counts use different timeframes and methods. Those numbers should not be treated as audited churn data; Flock is a private company and does not publish public revenue or churn disclosures. But the pattern is still important: cities were not only debating risk, they were removing cameras, renegotiating terms, or trying to get out of contracts after discovering how the network actually behaved. [3]

The Failure Was in the Sharing Graph

A policy can say “local control” and still sit on top of a product that makes overbroad access easy. That is the architectural gap in the Flock case. The meaningful question is not whether a written rule existed somewhere. It is whether the system made the permitted path narrow, auditable, reversible, and hard to expand accidentally.

In a bounded deployment, a city’s cameras generate plate reads for that city’s authorized uses. In a networked deployment, those reads become part of a search environment whose value increases as more agencies can query more cameras. The same feature that makes the product useful for cross-jurisdiction investigations can also make it difficult for a local customer to know who is looking at its data, why they are looking, and whether the search matches local law or policy.

Mountain View shows why settings screens are not enough. If a statewide lookup setting is active on nearly every camera from installation, the customer’s legal posture depends on a configuration it may not understand and may not have affirmatively chosen. Dayton shows the next step in the failure chain: even a local policy against immigration enforcement searches does not prevent those searches if the network can still route access in ways that make the policy enforceable only after the fact. Oxnard adds the most damaging detail for vendor trust: toggles that are supposedly disabled do not settle the issue if customers later find them re-enabled. [1]

That is a product-risk problem. A compliance team can review contract language, but it cannot manually compensate for a data model that treats cross-agency availability as the normal state. A city council can ask whether data will be shared, but it may not know to ask whether a later software update, administrator action, statewide setting, or vendor-side change can reopen the same pathway.

Dayton’s trash bags are the detail that should stay with product teams. The city covered all 72 cameras because it could not immediately exit the contract, according to the ACLU. That is what architecture-driven governance failure looks like once it leaves the dashboard: public works crews, awkward visuals, emergency administrative work, and a customer forced to make the product physically unusable while legal and contractual processes catch up. [1]

Local Control Is a Claim; Revocation Is the Test

Flock’s counterargument deserves to be placed where it belongs: inside the architecture question. The company has said local agencies control their data, that it does not work directly with ICE, and that it is being punished for transparency. Forbes reported the company’s position in the context of a wider backlash, including Flock’s argument that it provides visibility into use rather than hiding it. [4]

Those claims may describe the company’s intended governance model. They do not answer the harder product questions raised by Mountain View, Dayton, Oxnard, Evanston, and Illinois CBP access. If local agencies control data, what exactly does “control” mean when a setting is active from installation, when outside agencies can run searches at scale, when toggles can be re-enabled, or when access persists through a network path that local officials did not expect?

Revocation is the practical test. A customer should be able to shut off sharing and know that the shutdown has propagated everywhere it matters. The system should make clear whether old permissions remain valid, whether cached or exported data survives, whether third-party agencies lose access immediately, and whether the customer can independently verify that loss of access. Without that, “local control” becomes a phrase customers rely on until they discover the network has a longer memory than the contract.

Evanston is the bluntest version of that problem. The issue was not merely who could search what; it was whether the vendor’s conduct after termination matched the customer’s understanding that the relationship had ended. Reinstalling cameras without permission after a contract termination turns a governance dispute into a procurement and authority dispute. [1][2]

When “Not PII” Meets Enrichment

Flock’s planned Nova product is important because it exposes the weakness of a narrow data-category defense. The ACLU reported that Nova would connect license plate reader data with commercial people-lookup data brokers, allowing police to “jump from LPR to person.” The same reporting argued that this undercut Flock’s claim that its cameras do not collect personally identifiable information. [1]

For AI companies, this is the enrichment problem. A dataset may be described as non-PII when viewed in isolation. The risk changes when the product roadmap joins it to other datasets that resolve identity, household, workplace, movement, or behavioral context. The governance obligation should follow the resulting capability, not the narrowest label attached to the raw input.

That point reaches beyond license plate readers. A support transcript, product usage log, CRM note, location event, call recording, or device signal may look manageable inside one workflow. Once connected to outside data sources or made searchable across customers, regions, teams, or agencies, the product is no longer governed by the original field name. It is governed by what the joined system lets someone infer or do.

A Product Governance Checklist for Sensitive AI Systems

The useful lesson for AI vendors and buyers is not “avoid networks.” Networked products can create real operational value. The lesson is that the sharing graph is part of the product, not a footnote in the privacy policy. Before sensitive data enters an AI system, the buyer should be able to answer these questions without relying on a salesperson’s verbal assurance.

• What is shared by default? The default state should be explicit at deployment, not discoverable only after an audit, investigation, or public-records request.
• Who can query whose data? The answer should name roles, organizations, jurisdictions, third parties, and vendor personnel rather than using broad categories like “authorized users.”
• What happens when permissions change? The system should show whether changes apply prospectively only, retroactively where possible, or after a delay.
• How is revocation enforced? A customer should know whether access is removed from live search, saved searches, exports, derived datasets, integrations, and downstream systems.
• Are audit logs visible to the customer? Logs that only the vendor can inspect are not enough for a customer that bears legal and reputational risk.
• Can sensitive data be enriched with outside sources? If the answer is yes, governance should be evaluated around the enriched output, not the least sensitive input.

These questions are not procurement theater. They separate a controllable system from one where the customer’s risk depends on vendor discretion, future product updates, and hidden network effects. They also give product marketers and AI tool reviewers a better way to evaluate trust claims. “We give customers control” is not falsifiable enough. “Customers can see every external query, disable statewide lookup, receive alerts when sharing changes, and verify revocation across downstream integrations” is closer to an architecture claim.

For a related marketing-side analysis of the same company, see Flock Safety’s Marketing Failures Hold a Hard Lesson for AI Teams. The product-side lesson is narrower and more durable: a trust message cannot carry more weight than the permission model underneath it.

Cancellation Counts Matter, but Methodology Matters More

The cancellation numbers are useful as directional evidence, not as a clean revenue model. NPR’s 82-contract figure covers August 2021 through May 2026 across 28 states. Other public tallies have used different cutoffs, localities, and definitions of cancellation. None of those sources can substitute for Flock’s own private revenue, renewal, or churn data. [3]

Flock has also continued to claim growth. TechTimes reported that the company crossed 100,000 deployed cameras and cited more than 800 new contracts in 2026, while also reporting 53 cities canceling over unauthorized federal data access concerns. Those growth figures come from company claims, and independent verification is limited. The point is not that the backlash has ended Flock’s business. It is that a company can be growing and still be accumulating architecture-driven liabilities that make every new deployment harder to defend. [5]

That distinction keeps the analysis honest. Cancellation counts do not prove product failure by themselves. A large deployed base will always have some cancellations, political reversals, and procurement changes. What makes the Flock case different is that the strongest cancellations and disputes keep pointing back to the same design surface: broad network lookup, unclear customer visibility, permission changes, post-termination control, and enrichment plans.

The Legal Exposure Is Real, Even if the Ceiling Is Theoretical

San Francisco shows how architecture can convert access design into legal exposure. A class action alleged 1.6 million unauthorized queries by federal and out-of-state agencies over seven months, with potential statutory penalties of $2,500 per violation under California’s ALPR Privacy Act. That arithmetic produces a very large theoretical ceiling, but it should not be confused with realized damages. The court will determine liability and any actual outcome. [1]

Still, the lawsuit is a useful warning for AI companies because statutory privacy regimes often punish acts, not vibes. If every unauthorized query can become a unit of exposure, then search architecture matters as much as the privacy policy. A system that makes a questionable query easy to run at scale can multiply risk faster than a compliance team can draft explanations.

This is where AI vendors handling customer data should be careful about importing consumer-growth instincts into sensitive infrastructure. More discoverability, more sharing, more integrations, and more cross-customer intelligence can all improve product value. They can also create a legal surface where one permissive default becomes thousands or millions of separate events.

Fallout That Reinforces the Same Architecture Problem

Some of the surrounding fallout belongs in the background because it confirms the governance problem without changing its source. Fortune reported in July 2026 that the Los Angeles Police Department was renegotiating its agreement with Flock involving 138 cameras. [6]

Amazon’s Ring also canceled a partnership with Flock, according to TechCrunch. That decision matters less as a standalone brand story than as a signal that adjacent platforms did not want to inherit the risk of a surveillance network under scrutiny for federal access, immigration enforcement, and police use. [7]

Security concerns add another layer. The EFF reported that security researchers found vulnerabilities and that Flock refused to run a bug bounty program. Security posture is not the same issue as data-sharing defaults, but the combination is uncomfortable: a sensitive-data network with disputed access governance is also a system where vulnerability handling becomes part of the trust calculation. [2]

The CEO rhetoric and public argument over critics may shape perception, but they do not explain the cancellations as well as the product mechanics do. Crisis communications can make a bad week worse. They cannot turn a re-enabled toggle, an unexpected statewide lookup setting, or a post-termination camera reinstall into a misunderstanding.

What AI Companies Should Take From Flock

The Flock case is not a referendum on every license plate reader or every public-sector AI tool. It is a case study in how a sensitive-data product can create revenue risk before the first controversy appears. The risk begins when the data model, permission default, and sharing graph make overbroad access convenient, hard to observe, or hard to reverse.

For vendors, the lesson is to design governance into the load-bearing parts of the product: tenant boundaries, query authorization, default sharing states, enrichment limits, audit visibility, permission-change alerts, deletion, revocation, and downstream propagation. For buyers, the lesson is to evaluate those same mechanics before accepting claims about local control, privacy, or transparency.

A sensitive AI product can have a responsible policy and still fail if the architecture makes the prohibited path easy. Compliance language can only govern what the product has already made governable.

References

1. Flock Safety Credibility Lost as it Repeatedly Lies to City Councils — ACLU
2. EFF's Investigations Expose Flock Safety's Surveillance Abuses: 2025 in Review — Electronic Frontier Foundation
3. Why some cities are canceling Flock license plate reader contracts — NPR
4. The Backlash Against Flock — Forbes
5. Flock Safety Crosses 100,000 Cameras as 53 Cities Cancel — TechTimes
6. LAPD is renegotiating agreement with Flock Safety — Fortune
7. Amazon's Ring cancels partnership with Flock — TechCrunch