A municipality might tell residents:
We only have a few cameras.
That is useful information.
It is not necessarily the whole surveillance picture.
With networked ALPR systems, there are several different questions:
Who owns the camera?
Who controls the data it creates?
Who inside the agency can search it?
Which outside agencies can search local data?
What outside data can local users search?
How long are observations kept?
What happens when information is exported or preserved for an investigation?
Those questions can matter more than the number of cameras installed inside one city.
Always separate four layers.
Vendor capability ≠ local configuration ≠ written policy ≠ actual use.
Ask four different questions:
- What does the vendor say the system can do?
- What products, settings and sharing permissions has this agency actually enabled?
- What does the written policy require or prohibit?
- What do audit logs, searches, incidents, disciplinary records and configuration history show actually happened?
A seven-day vendor default does not prove a particular agency uses seven days. A policy restriction does not prove the technical setting enforces it. An available sharing feature does not prove it is enabled locally. One documented misuse elsewhere does not prove local misconduct.
The layers should agree. Residents need records to determine whether they do.
Camera ownership and database access are different things.
Imagine a township owns ten ALPR cameras.
It would be easy to assume township police can search those ten cameras.
But connected ALPR systems can support data sharing between authorized participating organizations. Flock describes its platform as allowing customers to control how their information is shared and accessed.
So the better questions are:
What can our ten cameras see?
and:
What larger collection of camera data can our users search?
Those are different questions.
Flock Safety: Law Enforcement Access
Follow one hypothetical trip.
At 7:45 a.m., one camera records a vehicle leaving its neighborhood.
At 8:20, a camera in another county records the same plate near a workplace.
That evening, a third participating system records it near a meeting, clinic, house of worship or friend’s home.
No single sighting explains the trip. Searchable observations from multiple places can reveal a route, routine or association that none of the cameras could show alone.
This is a hypothetical illustration, not a claim that every agency can see every camera. The point is what changes when separately ordinary observations become searchable together.
The privacy issue grows through combination. The public therefore needs to know the real sharing configuration—not merely how many poles its own city pays for.
There are two directions of sharing.
Other agencies accessing our data
A municipality may choose to share information generated by its cameras with neighboring police departments, county agencies, state agencies or other approved partners.
Our agency accessing other data
Local investigators may also be given access to information generated by participating cameras outside the municipality.
That means a city with a relatively small physical deployment could potentially have investigative access far beyond its borders, depending on permissions and agreements.
Flock says sharing is agency-controlled rather than automatic.
That makes the local sharing configuration an important public record.
“Our city owns only nine cameras” does not answer the question.
Suppose Redford has nine Flock vehicle cameras.
That tells us something about Redford’s physical infrastructure.
It does not automatically tell us how many outside cameras Redford personnel can search, how many agencies can search Redford observations, whether broader networks are available or whether separate video feeds are connected into the same investigative workflow.
Those require evidence.
Sharing can reach beyond traditional LPR results.
Flock’s FreeForm materials describe searching enabled shared video and vehicle evidence where access has been granted.
That does not prove a particular Metro Detroit agency has FreeForm.
It demonstrates why public oversight should look at the platform and permissions, not just roadside hardware.
A network can also add device-signal observations.
Leonardo/ELSAG’s SignalTrace product illustrates why a data inventory cannot stop at plates and photographs. Leonardo says the system detects supported broadcast Wi-Fi, Bluetooth and RFID signals, records date/time/location observations, groups devices that repeatedly travel together and can correlate the resulting electronic signature with an LPR observation.
The access questions then expand:
- Who can search a device signature?
- Can a device group be placed on an alert list?
- Can a signature be linked to a plate, person, address or case record?
- Can outside agencies query it?
- What raw signals, derived correlations and confidence scores are retained?
- What happens when a signature is exported or preserved?
- Can a new signal type or integration be enabled without a public vote?
We have not verified SignalTrace operating in Metro Detroit. Its documented capability shows why contracts and policies should name every data source and identifier—not use “LPR data” as a catch-all.
How SignalTrace turns wireless devices into a movement signature →
Private systems can become relevant to government access.
A private business, campus, neighborhood or other organization may use an LPR system independently.
Depending on the product and permissions, relevant vehicle evidence can potentially be shared with authorized law enforcement.
That does not make every private security camera part of a police surveillance network.
It does mean the public/private boundary can become less simple once systems are networked.
This is different from handing police one relevant video.
Suppose a store is robbed and police ask the business next door for video from a specific hour.
That is one model.
A connected surveillance network can create a different model in which authorized investigators already have searchable access to participating feeds or vehicle data across a broader network.
That difference deserves public attention.
Who inside the department can search?
Flock describes role-based access, individual authentication, required investigative purposes and automatic logging of searches.
Those are meaningful controls.
Residents should still ask locally:
- Which job roles have access?
- How many accounts exist?
- Who approves access?
- Can dispatchers search?
- Can patrol officers search?
- Are investigators given different capabilities?
- When is access removed?
- How often are permissions reviewed?
The vendor tells us how access can be managed.
Local records tell us how it is managed.
A required search reason is a safeguard.
It is not necessarily the same thing as prior approval.
There is an important difference between a search requiring the user to enter a reason and a search requiring independent authorization before it occurs.
Residents should understand which model their department uses.
Audit logs matter.
They are among the most useful accountability records available where these systems exist.
A good audit trail may help show who searched, when, what kind of search occurred and what stated purpose was given.
That can help departments detect abuse, investigate questionable activity, enforce policy and answer public questions.
But an audit log is fundamentally an accountability mechanism after access exists.
It does not remove the underlying surveillance capability.
The sharing settings themselves should be auditable.
Ventura, California publicly disclosed in 2026 that an audit identified a vendor-enabled nationwide-query configuration that had allowed two out-of-state agencies to query Ventura data despite the department believing its access was restricted more narrowly.
The city described the issue as a vendor configuration error and changed procedures afterward.
This example matters because it does not require assuming bad intent by local police.
The intended setting and actual technical access did not align.
Put the records next to each other:
Flock says sharing is optional and locally controlled.
Flock also describes National Lookup, which can search one known full plate across cameras whose agencies opted into the national network.
Ventura reported that its intended restriction and actual out-of-state access did not match.
Associated Press reporting has documented cross-jurisdictional searches that triggered investigations, policy changes and community concern.
Each statement answers a different question. Together they show why residents should ask for settings and audits rather than accepting either “everything is shared” or “nothing leaves our city” without evidence.
Flock’s description of National Lookup ↗
Associated Press reporting on cross-state access and federal cooperation ↗
Policy, configuration and reality can diverge.
That is one of our core research rules.
A policy might say one thing.
An agency interface might appear to show the same thing.
The underlying technical configuration or audit history may still tell a different story.
That is why we distinguish:
written policy → intended configuration → actual technical access → real use
They should agree.
We should verify rather than assume they do.
Illinois found another serious access problem.
In 2025, the Illinois Secretary of State announced that an official audit found U.S. Customs and Border Protection access to Illinois Flock camera data that state officials said violated Illinois restrictions. The state ordered access shut off and Flock paused the federal pilot involved.
Illinois Secretary of State announcement
That does not prove the same thing is happening in Michigan.
It demonstrates why Who can access the network? is not a theoretical question.
Sharing rules can change without moving a camera.
An agency may change partners, policies, permissions, subscriptions or vendor configuration without physically moving a single roadside device.
The poles can look exactly the same while the searchable network behind them changes substantially.
Retention is another moving part.
Flock announced in 2026 that its recommended/default routine retention for new customers had changed to seven days, while existing customers could retain previously approved periods unless changed locally. Flock also describes an Evidence Mode that can preserve selected records connected to active investigations.
This is exactly why we should never hard-code a universal statement that “Flock keeps everything for 30 days” or “Flock keeps everything for seven days.”
The correct question is:
What is the current retention period for this municipality, for this product, right now?
Seven days is less than 30.
That matters.
If a surveillance database exists, deleting routine observations after seven days reduces the amount of historical information available compared with keeping them for 30 days.
We should acknowledge that.
Our policy objection remains.
Seven days of indiscriminate collection is still indiscriminate collection.
Retention and preservation are different things.
Routine retention
How long ordinary observations remain searchable before automatic deletion.
Evidence preservation
Whether a particular observation can be selected and retained because it is connected to an investigation.
A city may honestly say routine data deletes after seven days without that meaning no Flock-derived information ever exists longer than seven days.
Exported information can leave the original system.
Once information becomes part of an investigative report, screenshot, download, case file, court filing, intelligence bulletin or another government record, the vendor’s original deletion period may no longer control that copy.
That is not unique to Flock.
It is a basic consequence of information being used.
Flock’s current evidence policy describes customer downloads and exports, preservation connected to an active matter and approved extended retention. It also explains that downloaded files can be validated after the original item has passed its normal retention period.
So “seven-day routine retention” and “no Flock-derived information can exist after seven days” are not equivalent claims. Ask separately about downloads, screenshots, case preservation, extended retention, evidence-system copies and transfers to other agencies.
Alerts are another form of access.
Search is not the only way an agency may use ALPR information.
Systems can generate alerts when a vehicle matches configured criteria.
Residents should ask:
- Who can create alerts?
- What lists can be used?
- Who reviews them?
- How are erroneous alerts handled?
- How long do alerts remain active?
A pattern is a lead, not necessarily a conclusion.
Two vehicles repeatedly appearing near one another may be important.
It may also mean coworkers, neighbors, family, people sharing a commute, delivery vehicles or coincidence.
Analytical tools can make patterns easier to spot.
They cannot automatically explain those patterns correctly.
More searchable data means more responsibility.
As systems gain access to more cameras, jurisdictions, private feeds, video, natural-language search, vehicle descriptions and pattern analysis, the consequences of poor permissions, weak policy, mistakes or misuse increase too.
Greater capability deserves greater scrutiny.
“Sharing is optional” deserves a follow-up question.
If sharing is optional, ask:
What did our municipality choose?
Useful records may include sharing configurations, partner lists, sharing agreements, user-role lists, audit logs, current policies and configuration-change records.
Beverly Hills shows why entitlement and configuration must stay separate.
A signed Beverly Hills order includes statewide and nationwide plate-lookup features. A later July 31, 2026 sharing snapshot showed a more specific local configuration: 141 in-state sharing relationships, the Michigan statewide network enabled, and the nationwide network disabled.
The order proves what the subscription included. The snapshot shows how two network settings stood on one date. Neither proves that every search feature was used, and neither guarantees the configuration stayed unchanged afterward.
The same record set contains a retention conflict: the signed order says 90 days, while the August 2026 department policy says Flock purges hosted data after 30 days. The correct response is not to choose the preferred number. It is to obtain the current settings record and any amendment that reconciles them.
Read the Beverly Hills records summary →
St. Clair Shores shows why access and use need different records.
A six-page community briefing dated September 16, 2026 says it was compiled from a St. Clair Shores Police Department FOIA response. Its roster identifies 147 Michigan organizations authorized to search data from St. Clair Shores’ 12 Flock cameras. The list includes nearby departments, distant sheriffs, university police, four tribal departments and five state agencies. Eastpointe appears on the roster.
The briefing is careful about the limit of that evidence: appearing on the roster establishes access, not that an organization actually searched St. Clair Shores data. The roster also reflects network settings, not 147 individually negotiated agreements. Search-audit logs are needed to establish who searched, when, for what stated reason and with what result.
The city’s official September 21 council packet independently confirms that authorized personnel in other Flock-using jurisdictions may search for plates or vehicle characteristics connected to crimes. It says this is not “unrestricted access,” but it does not enumerate the 147 organizations in the packet. The city also reports monthly local audits and weekly review of searches Flock flags as suspicious.
Eastpointe’s inclusion matters because Eastpointe’s police chief separately disclosed two employee-misuse findings before that city voted to terminate Flock. We have not found evidence that either misuse incident involved St. Clair Shores data. The correct question is whether St. Clair Shores audit logs show any Eastpointe search of its cameras—not an assumption that they do.
Read the St. Clair Shores evidence and meeting questions →
Livonia residents presented large outside-search totals in October.
At Livonia’s October 12 council meeting, residents said July and August FOIA exports showed more than one million outside-agency searches of Livonia-origin data. One speaker gave counts for search reasons containing “immigration” and references to ICE, 287(g), the DEA and U.S. Marshals Service; a council member cited 15,374 searches attributed to the Texas Department of Public Safety.
Those numbers were presented publicly and reported from records, but we have not independently reviewed the underlying exports. A “search” may not equal a unique plate, person, match or investigative action. Publishing the privacy-minimized logs and field definitions would let the public distinguish authorized access, actual queries, reasons and results.
Read the current Livonia evidence and caveats →
A regional report shows why case-by-case audit trails matter.
FOX 2 reported October 7 on ALPR-linked matters involving the Oakland County Sheriff’s Office and police in Brownstown, Southfield, Taylor and Troy. The station reported different circumstances in each case, including a former Oakland County employee’s alleged access, a stated Taylor partnership with ICE, and investigations in Southfield and Troy in which ICE became involved.
This reporting does not establish that every search was unlawful or that each department has the same policy. It does show that a broad statement such as “we do not give ICE direct access” cannot answer every route by which information may reach a federal investigation. The useful record is the audit trail: who searched, whose data were queried, the stated reason, what was exported and which agency received it.
FOX 2: Metro Detroit ALPR cases and ICE concerns ↗
Useful public-record questions
Depending on what we already know, a focused request might seek:
Current sharing relationships
Records sufficient to identify agencies or organizations authorized to access locally generated ALPR information.
Outside search access
Records sufficient to identify networks, agencies or datasets available to local authorized users.
Current retention settings
Records sufficient to show the configured routine retention period.
Users and roles
Records sufficient to show the number and categories of authorized accounts without unnecessarily requesting personal information.
Search audits
Audit records showing use during a reasonable period.
Sharing changes
Records showing changes to data-sharing permissions or configuration.
Policies
Current policies governing searches, alerts, sharing, auditing and misuse.
Request the records that answer the question.
Do not ask for everything merely because everything sounds interesting.
For Redford, these remain open questions.
We have evidence supporting Redford’s continued Flock relationship.
We do not yet have enough evidence to publish definitive answers about current routine retention, current outside sharing, which outside networks Redford personnel may search, which advanced products are enabled or the current user-access structure.
Those remain still researching until records establish them.
What should officials know before renewal?
Before renewing a networked ALPR system, an elected official should be able to answer:
- How many cameras do we operate?
- How many external cameras or records can our personnel search?
- Who can search our locally generated data?
- What is our current retention period?
- What information can be preserved longer?
- How many authorized users do we have?
- What search capabilities are enabled?
- What audit records exist?
- Have our sharing settings ever changed?
- Has unauthorized access ever occurred?
- Who reviews the audit logs?
If the people voting on renewal cannot answer those questions, that is itself useful information.
The network is the issue.
A roadside camera is hardware.
The larger surveillance capability comes from what happens after the observation enters the system:
Capture → Store → Search → Share → Connect → Analyze
The more broadly those functions operate, the less useful it becomes to talk about the system as if each camera were an isolated device watching one intersection.
Our position
We support accurate policies, strong access controls, meaningful audit trails, shorter retention rather than longer retention and careful permissions while a system exists.
Those are better than weak controls.
But our conclusion remains the same.
The strongest way to prevent unauthorized searches, unexpected sharing, configuration mistakes, future expansion and misuse of a mass vehicle-location database is not to maintain the database.
Good safeguards reduce risk. Removal eliminates the surveillance system itself.