Who Is Flock Safety?
An investigation into the private company behind a rapidly expanding network of roadside cameras, cloud-hosted vehicle records, police search tools, agency sharing, APIs, investigative software, and connected surveillance systems. This page follows the system from the roadside camera through the larger technical and institutional network behind it.
CEO, Flock Safety · LinkedIn
This investigation documents the larger system behind those cameras: capture, storage, search, analytics, sharing, investigative tools, APIs, external integrations, contractors, cloud infrastructure, security research, public contracts, and local oversight.
|
93
“Surveillance”
Times in Flock’s own patent (vs. “safety”: 0)
|
1,000+
Agencies
Networked — your data searchable by all
|
|
↑ Rising
Contract Terminations
Unauthorized installs, price hikes, data-sharing disputes, trust breakdowns
|
ZERO
Public Rules
No written Maryville policy on retention, sharing, or audits
|
💰 How and Where Flock Sells Your Data
Flock markets itself as a “public safety” tool, but the system operates as a paid data platform: cameras capture images + metadata, data is uploaded to a private cloud dashboard, and access to that database (and its analytics) is sold through subscriptions.
What’s documented in Maryville / Alcoa (local focus)
- Public infrastructure siting: cameras are installed on poles and roadside locations that exist because taxpayers fund and maintain public infrastructure.
- Law enforcement access: the city pays for platform access that includes searching, alerts, and travel-history-style lookups (as reflected in portal screenshots, dashboards, and training materials published on this site).
- Analytics about the driving population: dashboards can show aggregate breakdowns across the city, not just “suspect vehicles.”
What we’re actively investigating
- Private network expansion: community observations indicate cameras operating in private retail lots and HOA settings, creating a public/private surveillance web.
- Access requests to private cameras: publishing records showing when/how local agencies request access to private lot systems.
- “Not personal data” language: reviewing contracts/terms for how “anonymized/aggregated” is defined and what rights the vendor keeps.
TPRA record screenshot: example platform view showing camera label, timestamp, vehicle image, and map panel. (Click to view larger)
|
Camera location photo: Flock camera at US 129 Bypass & Foch St (Maryville, TN). (Click to view larger)
|
Note: This section documents system workflow and siting transparency. It is not an allegation about any individual driver. Purpose: illustrate how the system works (capture → record → map → alert) and why policy on retention, access, and audits matters.
|
|
- Which private contractors have been authorized to physically access Maryville’s Flock camera hardware?
- What data access, if any, do service contractors have during maintenance visits?
- Is contractor access logged and auditable alongside officer search logs?
- Was this contractor arrangement disclosed in the original contract or any public document?
Transparency note: photographs were taken in public space to document contractor activity at a city surveillance infrastructure site. No individuals are identified. Purpose: accountability documentation of who has physical access to publicly funded surveillance hardware.
A Flock camera does not operate as a stand-alone device. Each capture can become part of a much larger vendor-operated system involving cloud storage, account authentication, search tools, alerts, maps, vehicle analytics, agency sharing, investigative software, APIs, device-management systems, and third-party infrastructure.
Camera + vehicle image + time/location
Upload + storage + device infrastructure
Plate, vehicle traits, location + history
Alerts, maps + investigative tools
Other agencies + approved networks
APIs, Nova, video, external data + other systems
The sections below map these additional layers using Flock’s own materials, public records, technical infrastructure, investigative reporting, and independent security research.
🧠 Flock’s patent: surveillance capabilities, not “public safety” slogans
Flock’s branding centers “public safety,” but the patent record is blunt about what the system is designed to do: collect information from cameras in public space, extract identifying attributes, store those results with time/location context, and make them searchable across a wide area. That is the definition of a surveillance platform.
The most important takeaway is not “AI” — it’s scope. A license plate reader implies “targeted” use. A patent describing distributed cameras + a cloud database implies something else: routine capture of everyday Americans going about normal life (school pickup, commuting, grocery runs), because the system must capture everyone in order to work as advertised.
Literal occurrences in patent text
|
||
Literal occurrences in patent text
|
“Public safety” is a goal, but surveillance is a capability. The patent describes capability. Residents are left to demand what should have been published from day one: written policy, public reporting, and auditable accountability.
Camera hardware in public space (example image).
|
Diagram-style illustration of analytics / system concepts (context image).
|
Transparency note: this section cites the patent record to describe capability and scope. It does not accuse any individual resident of wrongdoing.
🧠 From searching for a suspect to generating investigative leads
On August 19, 2026, WIRED published a reconstruction of a Flock artificial-intelligence investigation tool called OS Investigate, originally known as Nightshift.
According to WIRED, more than 450 code files associated with the product were being delivered through Flock login infrastructure. Reporters used those publicly served files to reconstruct portions of the interface, Flock-authored investigative prompts, search parameters, available tools, and client-side controls.
Maryville Privacy then compared those findings with Flock’s own public product pages, technical documentation, Trust Center statements, and engineering descriptions. Together, those sources reveal more than a new search box. They describe an expanding investigative architecture built around natural-language search, multiple data sources, vehicle association, cross-camera analysis, and AI-assisted lead generation.
This reconstruction uses WIRED’s analysis of publicly served Flock application files, independent security research published by Nexanet, and Flock’s own publicly accessible product pages, documentation, Trust Center material, and public engineering descriptions.
Where a conclusion goes beyond what a source directly states, it is identified below as an assessment rather than an observed fact.
OS Investigate introduces another possibility: begin with a place, timeframe, behavior, travel pattern, association, or description; search a much larger dataset; and allow software to identify the vehicles or people that should receive additional investigative attention.
|
Traditional Search
Suspicion → Search
|
| ↓ |
|
Pattern-Based Investigation
Search → Candidate List → Suspicion
|
🔎 Reconstructed investigative workflow
🎛️ What could investigators search?
WIRED’s reconstruction exposed unusually specific search parameters, thresholds, filters, and Flock-authored investigative workflows.
🚗 Finding 01 · Vehicle proximity can become an investigative association
That resembles the general type of vehicle-association analysis found by WIRED inside OS Investigate. However, the available public evidence does not establish that Convoy Search and the OS Investigate association tool use the same algorithm or thresholds.
🎯 Finding 02 · Software can narrow a population into people for deeper investigation
🧩 Finding 03 · Identity “workup”
🧠 Finding 04 · Flock’s own engineering material reveals the architecture behind Nightshift
Public Flock engineering descriptions provide another window into the system. They describe Nightshift as a conversational investigative agent built around LLM tool use, multi-step reasoning, connections to Flock’s existing data platform, and infrastructure for monitoring agent behavior.
Important limitation: engineering requirements and job descriptions can include systems under development. They do not establish that every listed architecture or capability is currently active for every Flock customer.
🌐 Finding 05 · OS Investigate is emerging inside a much larger search ecosystem
Flock’s current public product pages independently document an expanding set of investigative capabilities around the same underlying categories: vehicle movement, natural-language search, video, LPR, public records, police data, and cross-jurisdiction analysis.
FreeForm, Enhanced LPR, Nova, and OS Investigate/Nightshift have distinct product identities and documented functions. Their appearance here together does not establish that they share the same algorithms or backend.
What it does establish is that Flock itself now publicly markets a broader investigative ecosystem capable of searching and connecting multiple categories of sensor, vehicle, video, police, and public-record data.
🕸️ Finding 05A · Flock Nova code exposes a documented “Dark Data” pipeline
In December 2025, security researcher Joshua Michael of Nexanet published an analysis of publicly accessible client-side code associated with Flock Nova. Rather than relying only on product descriptions, the research identified specific code objects, permission flags, API routes, result containers, interface elements, and search selectors associated with a data source explicitly named Dark Data.
decoded.hasDarkDataAccess
before building a Dark Data request.
When that permission was enabled, the code reportedly called:
darkDocs
stored alongside other application data and mapped to the user-facing label
“Dark Documents.”
The researcher reports that these records could appear alongside RMS persons, signals, and other case-linked information, with code supporting addition and removal of Dark Documents from investigations.
Flock Said It Does Not Use Dark Web Data. Analysis of Their Code Tells a Different Story →
Correcting the Record: Flock Nova Will Not Supply Dark Web Data →
However, the names of those functions do not by themselves prove the provenance of every underlying record.
Established by the published code analysis: Nova contained software structures designed to request, display, retain, and incorporate a category identified internally as Dark Data.
Still unresolved: who supplied the underlying information, whether every dataset was breach-derived, which customers received access, whether the capability remained enabled in production, and whether Maryville has access.
🔍 Finding 06 · Flock now publicly documents natural-language visual search
Flock’s current FreeForm documentation says authorized users can search video and vehicle evidence using ordinary language rather than relying solely on predefined database fields.
vehicle color
vehicle type
visible vehicle damage
clothing
visible accessories
camera zones
natural-language descriptions
shared camera networks where authorized
configurable alerts for potentially relevant matches
Flock states that people-related FreeForm searches operate on enabled video feeds rather than its LPR cameras and says the feature does not use facial recognition or biometric person identification.
🛡️ Finding 07 · Flock is adding automated search controls
Flock publicly documents an automated search-filter system intended to block certain prohibited LPR searches based on law or agency policy.
Flock says some search filters can automatically prevent searches related to restricted purposes such as immigration enforcement or reproductive healthcare where applicable.
WIRED’s reconstruction of OS Investigate, however, describes a broader investigative product with person-description fields, behavioral-pattern prompts, association analysis, and workflows capable of identifying candidate subjects.
These statements are not necessarily mutually exclusive. Flock may be drawing a technical and policy boundary between its core ALPR system and separate investigative products that can operate across additional datasets.
That boundary is exactly what public agencies should require Flock to explain.
❓ What we still cannot see
The publicly served files did not reveal:
• the hidden system instructions supplied to the AI model
• complete server-side processing logic
• every server-side validation rule
• precisely what every tool returns
• complete refusal / moderation logic
• agency-specific permissions
• the complete ranking logic behind generated candidates
• whether every reconstructed capability is currently active
Maryville Privacy has also not independently recovered the original 450-plus application files described by WIRED. The code-specific findings on this page therefore remain attributed to WIRED unless independently corroborated by Flock’s own current public material.
📍 Why this matters in Maryville
Flock’s own marketing for its Investigate bundle emphasizes that agencies can receive newer investigative tools through software rather than necessarily purchasing new roadside hardware.
That means oversight cannot stop with asking what a camera could do on the day the contract was signed.
Residents should also know what new software can operate on the data, what additional datasets can be connected, which capabilities Maryville has enabled, and what written limits govern their use.
🔗 Primary sources and technical references
Flock Has a Powerful New AI Tool for Police. We Got Its Code
Big City AI Tools on a Budget
Flock FreeForm
Natural-Language Video and License Plate Reader Evidence
Enhanced LPR — Multi-Geo and Convoy Search
LPR Pro — Freeform, Multi-GEO, Convoy and Visual Search
FlockOne — Sensors, Software and Investigative Data
Porterville PD and Flock Nova OSINT
Search Safeguards: How Flock’s Search Filters Work
Understanding Flock’s Testing and Development Program
Flock Trust Center — Law Enforcement Access
Flock Trust Center — Civil Liberties & Rights Safeguards
Flock Trust Center — Compliance Tools
Technical analysis of Flock Nova “Dark Data” code →
Flock’s public statement: Nova Will Not Supply Dark Web Data →
Research status · September 2026: OS Investigate remains an evolving product. The code-specific findings above are attributed to WIRED’s August 2026 reconstruction unless Flock’s own public documentation independently supports them. Maryville Privacy has not independently recovered the original 450-plus publicly served application files described by WIRED and has not independently reproduced Nexanet’s Nova code analysis. The Nova-specific technical findings above therefore remain attributed to Nexanet and are linked to the researcher’s published evidence. Flock’s public product pages and engineering descriptions provide additional evidence about its broader investigative architecture, but product marketing, engineering plans, and job requirements do not by themselves establish that every described capability is currently deployed to every customer. Nothing in this section establishes that Maryville currently has access to OS Investigate/Nightshift, that every described function is enabled in Maryville, or that any particular resident has been searched through the product. Nothing in the Nova “Dark Data” findings establishes that Maryville has access to that capability or establishes the provenance of the underlying data.
🕸️ The camera is only the bottom of the system
A Flock camera may be installed by one police department, but the information it collects does not necessarily remain inside that department. Flock supports cross-agency sharing and software integrations, while regional intelligence organizations can provide another layer above individual police departments.
One unusually well-documented example is the Northern California Regional Intelligence Center (NCRIC). Public records independently establish that NCRIC has used Flock Safety, has Flock-related network and sharing records, and participates in a regional law-enforcement information-sharing environment.
Separately, an August 2026 investigation by Patrick Quirk / Ringmast4r and ek0ms savi0r reported finding a contractor-associated GitHub repository containing technical material for an NCRIC ALPR system. Those repository-derived details are useful for understanding what a regional architecture may look like, but Maryville Privacy has not independently recovered and authenticated the original repository. Those specific findings remain labeled reported below.
[DOCUMENTED] Described in published vendor or government documentation.
[REPORTED] Reported by an outside researcher or publication where Maryville Privacy has not independently authenticated the underlying artifact.
[ASSESSMENT] An inference drawn from the documented pieces.
[NOT ESTABLISHED] A possible connection for which Maryville Privacy has not found evidence.
✅ What can be independently established
[CONFIRMED] Public-records productions concerning NCRIC include Flock Safety contracting material and records concerning Flock network auditing, shared networks, and agencies sharing Flock ALPR information with NCRIC.
[CONFIRMED] Public reporting based on agency audit records has documented NCRIC personnel conducting searches across large numbers of Flock networks.
[CONFIRMED] NCRIC access to another jurisdiction’s Flock information became a public controversy in San Francisco after audit records showed searches involving outside agencies, demonstrating that a locally collected ALPR record can become relevant beyond the agency that originally collected it.
🗺️ The documented information-sharing model
🔎 The reported GitHub repository goes one layer deeper
The Ringmast4r investigation describes something different from an ordinary Flock audit report. It says a contractor-associated repository exposed portions of the technical plumbing used to move Flock ALPR information into a separate regional system.
Maryville Privacy has not independently authenticated the contractor repository described by Ringmast4r. The exact camera count, software names, database contents, cloud architecture, and repository file contents below therefore remain reported findings.
The reported repository matters because it may provide a rare view of the software and cloud infrastructure underneath one such regional system.
It does not establish that every Flock customer uses the same architecture, that every fusion center receives Flock data, or that Maryville participates in the NCRIC system.
But meaningful oversight has to continue upward through the account, cloud platform, sharing permissions, APIs, integrations, regional systems, and outside users that may have access to the resulting information.
The question is therefore not simply:
“Who owns this camera?”
It is:
“What is the complete path this camera’s information can travel?”
📍 Tennessee has its own statewide fusion center
The California case is not evidence about Maryville, but it raises a directly relevant Tennessee question because Tennessee already has a statewide law-enforcement information-sharing structure.
TBI describes the Fusion Center as an information-sharing operation involving local, state, and federal law enforcement and says it receives, analyzes, and disseminates information concerning criminal activity.
[CONFIRMED] TBI also maintains a regional office in Knoxville.
Knoxville-area law-enforcement intelligence operations and the Tennessee Fusion Center should not automatically be treated as the same system. A fusion center, regional TBI office, police intelligence unit, task force, and real-time crime center can perform different functions and have different access.
🏠 Mapping Maryville from the camera upward
Maryville Privacy is attempting to map the entire publicly identifiable infrastructure surrounding Maryville’s ALPR system — from the roadside collection device to every documented sharing, integration, and intelligence layer above it.
The relevant question is whether information can move through Flock sharing, APIs, exports, integrations, investigative referrals, task forces, or other authorized law-enforcement systems.
A meaningful surveillance map therefore has to show the entire information path — not just dots representing cameras.
🔗 Evidence and source trail
A Fusion Center’s Flock Stack Landed on GitHub
Source for repository-derived technical claims. Those details are labeled reported on this page.
02 · Reported contractor repository
erhhung/ncric-alprs
Canonical repository location identified by Ringmast4r. Repository availability may change.
03 · NCRIC Flock public-records request
NCRIC Flock Safety ALPR records — MuckRock
04 · NCRIC Flock contract and audit records
Flock ALPR contract and audits — NCRIC
05 · Northern California Regional Intelligence Center
NCRIC official website
06 · Tennessee Bureau of Investigation — Tennessee Fusion Center
Tennessee Fusion Center
07 · Tennessee Bureau of Investigation — Fusion Center FAQs
Tennessee Fusion Center FAQs
08 · Flock Safety — Developer Hub
Flock Safety REST API documentation
The broader NCRIC/Flock relationship and regional information-sharing context are supported by public records and official sources.
The contractor-repository architecture, exact camera count, named ingestion components, and related technical details remain attributed to Ringmast4r’s published analysis because Maryville Privacy has not independently authenticated the original repository.
Maryville Privacy has not found public evidence establishing that Maryville’s Flock ALPR records currently feed the Tennessee Fusion Center, NCRIC, or another specific fusion-center database.
This is an ongoing public-infrastructure mapping project. Findings are separated by evidence level so that documented connections are not confused with reported architecture, technical assessment, or unanswered local questions.
🌐 Mapping Flock’s publicly visible infrastructure
A roadside Flock camera is only the visible edge of a much larger system. Public DNS records, TLS certificates, HTTP metadata, cloud-hosting observations, vendor documentation, API documentation, and other ordinary internet records expose pieces of the architecture behind the platform.
Taken together, those records allow portions of the Flock Safety ecosystem to be reconstructed from the outside: customer authentication, development environments, device services, ALPR APIs, video infrastructure, cloud hosting, and drone-related systems.
Individual findings are separated into observed evidence, documented context, and assessment so that inference is not presented as direct observation.
Not every Flock customer necessarily uses every layer shown here.
The final Maryville branch separates what is already documented locally from questions that remain unanswered and should be resolved through public records.
🚁 Finding 01 · Fly and drone infrastructure
fly, staging-fly, and
dronetest-fly services have appeared in Amazon’s
us-gov-west-1 region. AWS identifies that region as
AWS GovCloud (US-West), an isolated U.S. cloud environment intended for
government and regulated workloads.
That infrastructure association does not establish what information Flock places in those systems.
References: Flock DFR / Flock Alpha · Flock Product Hub · AWS GovCloud (US)
🖥️ Finding 02 · Authentication, accounts, and device services
References: Flock Safety FAQ · Flock User Management · Microsoft Entra / Flock Safety SSO · Flock Security Center
🔌 Finding 03 · Documented API and integration layer
Flock’s Developer Hub documents machine-to-machine interfaces that allow other software systems to query, ingest, or exchange information with the Flock platform.
Official API references: Flock Safety Developer Hub / REST API Overview · Flock API & Integration Terms · Flock: No-Cost Core APIs for Law Enforcement · Flock Partners & Integrations
🎥 Finding 04 · Video API and ONVIF-related infrastructure
Technical references: ONVIF · Kong Gateway · Flock Safety Product Hub
☁️ Finding 05 · Additional cloud and development environments
The hostname, namespace, certificate identity, service naming, hosting provider, region, and response metadata are generally more durable architectural indicators.
Understanding that broader architecture is part of understanding what taxpayers are funding, how information can move between systems, and what residents are being asked to trust.
Last reviewed: September 2026. Cloud infrastructure changes frequently. Hostnames, namespaces, hosting observations, and service descriptions are presented as publicly observed or publicly documented technical indicators. This is not a complete inventory of Flock Safety infrastructure and should not be interpreted as evidence of unauthorized access or vulnerability.
🔐 What security research reveals about the infrastructure behind Flock
Public security research provides another way to understand Flock Safety’s architecture. Instead of describing what the platform is supposed to do, responsible-disclosure reports can expose actual application objects, credentials, permissions, map layers, JavaScript bundles, service names, and access-control structures used by the system.
The findings below focus primarily on research published by Joshua Michael / Nexanet. Flock disputes broader claims that its cloud platform has been hacked or that customer information has been leaked. Both the technical findings and Flock’s responses are linked below.
[RESEARCHER-DOCUMENTED] Published by an identified security researcher with technical artifacts and responsible-disclosure history.
[ASSESSMENT] Interpretation drawn from those artifacts.
[NOT ESTABLISHED] A conclusion the available evidence does not prove.
🗺️ Finding 01 · A Flock ArcGIS credential was embedded in public-facing code
On January 9, 2026, Nexanet published a responsible-disclosure report concerning a Flock Safety ArcGIS API credential embedded in publicly accessible JavaScript bundles.
esriMapsApiKey: "AAPK_EXAMPLE_REDACTED_7f3a••••••••••••••••"
Synthetic example only. This value cannot authenticate to any real service.
This synthetic example illustrates the type of client-side credential researchers reported finding. The documented identifiers and metadata above are real research artifacts; the credential value shown here is intentionally fabricated.
🔑 Finding 02 · The published metadata referenced access to private ArcGIS items
🧩 Finding 03 · FlockOS code shows a unified mapping-layer architecture
Nexanet published a FlockOS map-component signature showing the Esri key passed into the same application component as multiple map-layer types.
It demonstrates that FlockOS is designed around a multi-layer geographic interface rather than a single standalone license-plate display.
🎛️ Finding 04 · Public FlockOS code exposes product permission names
Permission names establish that corresponding capability controls existed in the analyzed application code. They do not establish that every customer had those permissions enabled.
🛰️ Finding 05 · Reported FlockOS / ArcGIS layer categories
The existence of 50 private-item privileges does not by itself prove that every category listed above existed inside every one of those 50 private items.
☎️ Finding 06 · Flock911 objects appeared in the same mapping architecture
🚁 Finding 07 · Drone and device state values were visible in application code
📦 Finding 08 · Example public JavaScript bundle names
Nexanet reports finding the same ArcGIS credential across dozens of publicly served front-end bundles. Hostnames and the credential itself were redacted in the disclosure, but numerous bundle filenames were published.
🔄 Finding 09 · Nexanet reported a separate production-token path
The ArcGIS API-key finding was not the only credential issue described in the disclosure. Nexanet separately reported an unauthenticated token-minting path in a development environment that could issue ArcGIS tokens associated with Flock’s production mapping environment.
⚖️ Flock’s public security position and the researcher findings
Flock says vulnerabilities are handled through security testing, responsible disclosure, monitoring, and remediation.
Responsible security research that discovers an exposure is not automatically equivalent to a malicious attacker compromising the platform.
👤 Finding 10 · Separate congressional concern: stolen Flock customer credentials
Separate from Nexanet’s ArcGIS research, Senator Ron Wyden and Representative Raja Krishnamoorthi asked the Federal Trade Commission in November 2025 to investigate Flock’s cybersecurity practices.
This is a separate issue from the ArcGIS credential disclosure. A stolen customer password concerns account authentication; the Nexanet findings concern exposed infrastructure credentials and application architecture.
• A Flock ArcGIS credential was reportedly embedded in public-facing code.
• Nexanet classified the exposure as CWE-798.
• The researcher documented 53 public-facing occurrences.
• Credential metadata reportedly listed 50 private-item privileges.
• Published FlockOS code contains multiple geographic layer classes.
• Published code exposes permissions for FlockOS911, CAD, drone dispatch, and integration management.
• Nexanet reports the Default API Key exposure was remediated.
• Congress separately documented reports of stolen passwords associated with at least 35 Flock customer accounts.
• that all 50 private items contained every data category described above
• that all Flock customers shared data into the same ArcGIS layers
• that every Flock product used the same credential
• that every Flock customer account was vulnerable or compromised
• that Maryville’s Flock account was accessed
• that Maryville ALPR records were exposed through these findings
• that a foreign government or criminal organization used these pathways
🌐 The architecture visible through the security research
🔗 Technical evidence and responses
53 Times Flock Safety Hardcoded the Password for America’s Surveillance Infrastructure →
Flock Safety Cybersecurity: How We Protect Customer & Community Data →
Flock’s direct response to public security and breach claims →
Wyden, Krishnamoorthi Urge FTC to Investigate Flock Safety →
Wyden / Krishnamoorthi Letter to FTC — Flock Cybersecurity →
The code identifiers, permission names, bundle filenames, ArcGIS privilege structure, and exposure counts in this section are attributed to Nexanet’s published responsible-disclosure research unless independently supported by another cited source.
Maryville Privacy has not attempted to use the exposed credentials, reproduce access to restricted Flock infrastructure, or query the private ArcGIS items described in the research.
The exposed API key itself, token values, private item identifiers, and unpublished exploitation details are intentionally not reproduced here. Any credential example shown above is synthetic and non-functional.
Nothing in this section establishes that Maryville’s ALPR records or accounts were accessed through these vulnerabilities.
🧾 Staunton, Virginia: CEO email + police chief response
Staunton published a document showing an unsolicited email from Flock’s CEO framing criticism and records requests as a “coordinated attack,” and a police chief response explaining that citizen concerns and questions are “democracy in action.”
- It frames critics as activist groups who want to “defund the police,” and characterizes public-records activity as a “weapon.”
- It positions Flock and police as a single team (“fighting this fight for you”).
- It uses emotional language (“tough every day waking up to stories online…”) rather than sticking strictly to verifiable facts and contract terms.
The chief describes citizen concerns about surveillance and data use as democracy in action, not an “attack.” That distinction matters: asking questions about a private mass-surveillance vendor is not anti-police.
🏗️ A startup scaling into public infrastructure
Flock scaled quickly from a startup model into public infrastructure deployments (public right-of-way, utility/pole siting, and roadside installations).
When a private company’s hardware ends up on taxpayer-maintained infrastructure, residents can reasonably ask to see permits, right-of-way agreements, liability coverage, and data-use limits — in writing.
📌 Reported examples: permitting / approval disputes (non-exhaustive)
- Fort Worth, Texas (public right-of-way / permits): Investigation reporting described cameras placed on public property without approvals/permits and the city’s response. Source (KERA)
- Florida (state right-of-way / DOT permitting): Investigation reporting described installations in state right-of-way without required permits and related enforcement actions. Source (Action News Jax I-Team)
- Cambridge, Massachusetts (unauthorized installs): The City’s own statement described a trust/material breach involving additional cameras installed without the City’s awareness. Source (City of Cambridge)
- Cambridge, Massachusetts (local reporting context): Local reporting discussed unapproved camera issues and city response. Source (Cambridge Day)
- Evanston, Illinois (policy / legal controversy context): Local reporting described public controversy and legal/policy questions around access and compliance. Source (Evanston RoundTable)
- Virginia (Fourth Amendment — court ruling, June 2024): A Norfolk Circuit Court judge ruled that collecting location data from 172 Flock ALPR cameras constitutes a Fourth Amendment search and cannot be used as evidence without a warrant. This ruling directly implicates mass collection and travel-history tools. Commonwealth v. Moore
✅ Minimum baseline residents can demand
- Proof of permission to occupy public space: permits + right-of-way agreements (PDF copies).
- Liability clarity: insurance, indemnification, who pays if equipment is moved/damaged or interferes with public utilities/maintenance.
- Written rules: retention limits, sharing rules, search justification standards, audit logs, misuse penalties.
- Procurement transparency: contract, renewals, add-ons, analytics modules, and any private-camera partnership terms.
- Vendor contact transparency: who met with the vendor, when, and what expansions were discussed (ALPR → drones → radar, etc.).
📉 The pushback is no longer isolated
Communities across the country are ending, defunding, or refusing to renew automated license plate reader programs. And some of the strongest recent pushback is happening right here in Tennessee.
The Institute for Justice now maintains a nationwide database tracking governments that have canceled, terminated, defunded, or declined to renew ALPR contracts since 2025.
IJ does not count jurisdictions that merely pause their systems, making the database a conservative measure of communities actually walking away from ALPR programs.
TO DEFEND OUR CONSTITUTION?
Communities are pushing back over privacy, cost, oversight, and effectiveness. One thing is clear: ALPR surveillance is a policy choice, not an inevitability.
“Who’s watching the watchers?” — InvestigateTV (Gray TV) national report on Flock Safety
Published May 18, 2026. Reporting and video by national investigative reporter Brendan Keefe (Peabody Award, two National Emmys, DuPont‑Columbia Silver Baton). Carried locally on WVLT-8 Knoxville. The report documents Flock employees accessing private cameras inside a Jewish Community Center, family members of Flock employees speaking in favor of Flock contracts at city council meetings without disclosing the relationship, an innocent driver wrongly charged based on Flock images, and audit-log costs that residents call transparency theater.
Video sources: WVLT-8 Knoxville broadcast page · YouTube · Atlanta News First full text
🔑 Five findings residents should know
📍 Why this matters locally
- Has any Flock employee accessed Maryville cameras for sales demonstrations, training, R&D, or any non-investigative purpose? If yes, with what authorization?
- Will the City and MPD release Maryville’s external-sharing list and external-search counts?
- Will the City adopt a disclosure rule requiring vendor-affiliated speakers (employees, family, paid consultants) to disclose the relationship at council meetings on surveillance items?
- What is the actual cost, in writing, to release one month and one year of Maryville’s Flock audit logs?
Sources: InvestigateTV / Gray TV reporting by Brendan Keefe (May 18, 2026); Atlanta News First; Axios Atlanta; Appen Media; Rough Draft Atlanta; AtlPress Collective; public records obtained by Dunwoody, GA resident Jason Hunyar. This section summarizes published reporting and primary-source records and does not allege any specific conduct by any individual not named in those public sources.
🧾 Who brought Flock to Maryville, TN? (Officials recorded in the July 2, 2024 approval)
According to the official July 2, 2024 City of Maryville Council minutes and meeting packet, the City Council unanimously adopted a resolution titled “A RESOLUTION APPROVING THE INSTALLATION OF LPR/CAMERAS IN MARYVILLE, TN FOR THE PURPOSE OF PUBLIC SAFETY.”
The officials below are listed in the public record in connection with that vote and related implementation. Where an official is publicly associated with a business or professional firm, links are included so residents can evaluate potential incentives and demand written safeguards (without assuming wrongdoing).
- Andy White — Mayor. Presided over the July 2, 2024 meeting and declared the LPR/camera resolution adopted after a unanimous roll call vote.
Questions residents can ask: Were privacy safeguards and oversight requirements made public before adoption? What written limits exist on retention, sharing, and vendor access?
- Fred Metz — Councilmember / Vice Mayor. Made the motion to adopt the LPR/camera resolution.
Links: City profile · Dunn & Metz Appraisal GroupQuestions residents can ask: Did the motion include enforceable guardrails (audit logs, retention limits, sharing restrictions), or was it a blanket approval? Were cost/renewal and data-use terms fully disclosed to the public prior to the vote?
- Tommy Hunt — Councilmember. Seconded the motion to adopt the LPR/camera resolution.
Questions residents can ask: Do officials whose businesses rely on distributed retail locations support surveillance expansion that may also benefit their industry? Were community privacy impacts evaluated in writing before approval?
- Drew Miles — Councilmember. Present at the July 2, 2024 meeting and part of the City Council that voted unanimously.
Links: City profile · Miles Insurance AgencyQuestions residents can ask: Could any private-sector industry (including insurance or risk analytics) benefit from expanded surveillance or ALPR-derived analytics? What written limits prevent sharing or repurposing beyond public safety?
- Sarah Herron — Councilmember. Listed in the minutes as absent from the July 2, 2024 meeting and therefore did not participate in the vote.
Links: City profile · Public pageQuestions residents can ask: Were later decisions (budget, renewals, policy changes) made with clear public notice and published safeguards?
- Greg McClain — City Manager. Listed as present at the July 2, 2024 Council meeting.
- Sherri Phillips — City Recorder. Listed as present; resolution text identifies the Recorder’s role transmitting certified copies to TDOT.
- Melanie Davis — City Attorney. Listed as present; resolution form includes “Approved as to form” signature line.
Links: Professional bio · Law firmQuestions residents can ask: Were enforceable privacy safeguards and data-use limits written into policy/contract (not just informal practice)? Are those safeguards publicly accessible and auditable?
- Tony Jay Crisp — Chief of Police / Director of Public Safety. Public records/agenda background state the department has “for numerous years operated LPR/Cameras,” and Flock-related correspondence is addressed to or from his office regarding meetings and implementation details.
Links: Police department · AdministrationVendor influence / relationship transparency issue (documented)A vendor email to Chief Crisp includes: “Thank you for the hospitality last week. It was a blast!” That matters because the same vendor is soliciting public funding for expanded surveillance (here: a regional drone proposal listing stated costs of $300k (year 1) and $450k (year 2)).Document summary: Vendor-to-chief sales email proposing a regional “Flock Drones” rollout (launch stations + radar), including pricing and vendor-provided FAA waiver/pilot support.Questions residents can ask: What is the department’s written policy on vendor meals/hospitality/gifts? Were vendor meetings logged and disclosed? Was there an RFP or competitive process for expansions (including drones), and are all quotes/contracts published?
- Lt. Rod M. Fernandez — Maryville Police Department. Email correspondence shows he served as a primary point of contact with Flock Safety, including arranging a March 20, 2024 meeting with a Flock representative and drafting a May 31, 2024 letter to the Electric Department to secure permission needed for camera installation. Public records also show Lt. Fernandez approved plates on the Flock Safe List with no written policy governing the decision.
- Published written policy: who can search, required justification, retention limits, sharing rules, and audit logging.
- Independent oversight: periodic audits + public reporting (search counts, reasons, hits, sharing, misuse findings).
- Strict limits: retention caps, purpose limitation, and bans on repurposing beyond stated uses.
- Procurement transparency: full contract, total costs, renewals, and add-on analytics products.
- Vendor influence safeguards: written gift/hospitality rules + disclosure of vendor meetings/communications (especially for expansions like drones).
Source: City of Maryville City Council Meeting Minutes, July 2, 2024, agenda background materials, and TPRA-released email records. Business/professional links and “questions residents can ask” are included for accountability and do not allege wrongdoing.
🛡️ Oversight is pro-community — and pro-constitutional policing
MaryvillePrivacy.org is not “anti-police.” It is pro-accountability. Our core position is simple: if a private company is selling a mass-surveillance platform to government, residents have the right to ask how it works, how it’s governed, and how it can be misused.
Why vendors blur the line
A vendor benefits when it can equate criticism of the company with criticism of law enforcement. But a private company is not “the police.” A taxpayer has every right to question a private vendor’s claims, contract language, auditability, and business incentives.
✅ What residents should demand before/after any ALPR rollout
- Written policy published publicly: who can search, what justification is required, retention limits, sharing rules, and audit logging.
- Independent oversight: periodic audits + public reporting (counts, reasons, hits, sharing, misuse findings).
- Strict limits: retention caps, purpose limitation, and clear bans on repurposing beyond stated uses.
- Procurement transparency: full contract, total costs, renewals, and any add-on analytics products.
- Vendor influence safeguards: clear gift/hospitality rules + disclosure of vendor meetings and communications (especially for expansions like drones).
- Community consent: hearings before expansion, not after equipment is already in the field.
🎥 Video explainers + primary source
If you’re new to Flock, start with these short explainers — then review the primary source email below.
Video link: youtu.be/vU1-uiUlHTo
Video link: youtu.be/hwbE5ks7dFg
❓ Common questions
Did Flock employees view cameras inside a Jewish Community Center?
Is questioning Flock “anti-law enforcement”?
What does “Flock sells your data” mean?
Why do permits and right-of-way approvals matter?
What should my city publish before any ALPR rollout?
Where can I read the Staunton CEO email exchange?
Has any court ruled ALPR mass collection violates the Fourth Amendment?
|
|||
|
|||
|
|||
|
Sources / primary documents: Staunton email exchange PDF: https://www.ci.staunton.va.us/home/showpublisheddocument/13448 · Staunton termination: https://www.ci.staunton.va.us/Home/Components/News/News/2564/71 · Cambridge termination: https://www.cambridgema.gov/news/2025/12/statementontheflocksafetyalprcontracttermination · CEO LinkedIn: https://www.linkedin.com/in/glangley/ · Patent: https://patents.google.com/patent/US11416545B1/en · Permitting dispute reporting: KERA / Action News Jax / Cambridge Day / Evanston RoundTable (see Section 4 links)
MaryvillePrivacy.org informational page about Flock Safety, an automatic license plate reader (ALPR) and surveillance camera vendor providing cloud-based search, alerts, and analytics. This page discusses public oversight, public records, data retention and sharing, audit logs, right-of-way permitting, and examples of city contract terminations (Staunton, Virginia; Cambridge, Massachusetts). It also provides local accountability context for Maryville, Tennessee including the July 2, 2024 LPR/camera approval vote and questions residents can ask about governance, procurement transparency, and vendor influence safeguards.This page also documents publicly visible Flock Safety internet infrastructure associated with Flock Fly, Flock drone testing, AWS GovCloud, Safe List administration, account authentication, development systems, and cloud-hosted surveillance services.
🔐 PGP Public Key (click to reveal)
Fingerprint:
2646 AEFF CB70 577D E964 08AC A4E7 3145 48A3 54F6
-----BEGIN PGP PUBLIC KEY BLOCK-----
xsFNBGkh1AIBEADTOnwUJuvRJDMV9+eXdaEUN2SQKj9Ro15G8eaNVBW5pDEPAMuG
SCm62Jsllobj5f5HAn1eu3wXkpIXqJRqCJ0Qg+OX92FAyB5TAIdPf5eqQKzhgS1J
XsoGBULbA1z1uz9NMCZNcJ8EBToGIJpA4NlJG4h+T4tcXmgscX5wAeJX1A+Mq8fb
lISV4kn8kRNmjKOs9pTSMkvkrQZc5ZW9h383yILhV7etc60xksDq+4Fqkr9K51s9
TB1vLru0sKlpwH+ToortntBClPK8SK6fzvj6vWjDe0o1JZ0sJkW3wmYygK1XkXf3
I4d7HHj7fg8pJtoQJI4zwUvQmB4k1ePM3yk5P02+huW1Pt9ToqFk7hFt8G/6JhsC
HKJs6p1HSBDE6FxQMcBUwB/74A/nKQ0OEg+89pHmp2y17dKuiiOvJ100+xruCqMJ
LEXEaKyie05QH4jW9e3ackzPrjwYCxU5blIv94w3Bs2/w6teeYy5VSv0FbKVvK+k
uKMMf6Hbqyflk8Ln7K6sQE1BXbj9+sgJUSZi4KEGtZsxn5ej2poNTsMqYWaJ0yvH
CZP5zVzEVx9XpEN/Lk1kOGw8RsDdiegqHAGWx++lmou9/4QXz+Miq4gT5/iiEN7Z
LhPKTNf1gkTJyd4/9DSuBKpZp8+VGaieuOdVjvqXZihpuUh59/UiesVTkQARAQAB
zRwgPGluZm9AbWFyeXZpbGxlcHJpdmFjeS5vcmc+wsGNBBMBCAA3FiEEJkau/8tw
V33pZAispOcxRUijVPYFAmkh1AMFCQWjmoACGwMECwkIBwUVCAkKCwUWAgMBAAAK
CRCk5zFFSKNU9tVGD/9c31LhK3bRKX24adq8e3uE97BVRzehtZR4Kwb7jy2QIQRu
cdMEBe4NHrmD1l6BQSRaeGhJIRbzXiNlVAqw7rFKhyuFcea7CuJ6f//EKUXyVSBV
71TA3UBf0Pzul6DMRjZgBnl8RhrjW/41cjf+OCJ2JbQmokR4td6C+7c4XcXgBXEa
2FUwEqVsqjQrYJ0UhLwXCBRzA6PR6jYn7Fjt+e7+JwaT5qNQPvvf6U+8XbErTzmJ
0gYfJ+IXIomCUMxuiCI/B9zYOgzFlO1Z1LDsj42EtDK69ITuHVnx4aeMYLuDPFSG
twSm0TxvUPCMcWoULq3pW1Tax2QvXwd3oBoJxkRKz4sWdiEO55QUPG/0NHwLcSoN
5JVImYZr81l4GBhZCqpnkzxRHiNbpmpwJhwFeEy/w3DdUWTuP4sy7RJfDbWlriII
nvGOGaS8eQBjjWEceLZhQwCItOrddmOwnWpRQ09C32HqhT0sKWRD9sNXk152oM/R
GiTM64zGmCFR3C8QEAkq+4GFTfNk/P2Q1yYlMW7YqlMFaP1EkjyANOOyqX9Tsa8s
vgc1eggw8+yE6GdC48gNheexBFbnZ5yAkgTtAnAHvEXn3nxo6XeoqKaGrKuxXqA/
y6trtYmr5UFAUeXjcmeVzUx4nM2h7BLxX6/r7rCnLV3SqLamUdNYmWXmBohrqs7B
TQRpIdQDARAAxtgmivuRMKH5LP93d1hl1vXmohWMVdLRnEjJY0yUi/0tz9SOjbOj
jRu4AwkqNn+wvLv6AVqY4rdcTHlX1+gRc1ZgtzYKIkfTucIXMFmVH1i7dA4rPxzp
m0uOtTHL7zDsS+NCx1kLDq59Uy3ZXduusn/4b3WEXouVTcTbFJXHPDTNAk7HxiLn
cPjIOojwwNJUCElY7suC46kvEaxTRHQOjQd105YFSpIcIpOsqp85mWx16P96zYcB
3jbwibkkr9Q7JNm9GMVPS8BTRrjBtkSxseTcRE1KErgITtTOKibauuiQnSk1wln6
XSfYh+ZHs3C8kkEikLM6uFP1bEX6WN+R+DpwY07KdD5TVkF8fUEnC4Slux74Nk6U
ae58awlJMoxHRE6ekOOTIKaKOGttclb2WG8axAAE0aob2m0/9fJNnkl+XnsREnLz
5XnIHkzOWaGOhjoLgCDSVzdDYJOOVBYwLLxrT7TGk9Bq5yIpT/QdBakmq5MEmZFv
/NgaiFulCK3UAOumRKTqb5WuSsoyT+zl8IJBasZmtchUxH3TAiZpQonPYugHkSTH
CHH5jQMkN3mmvNYEVhdlqRcM8Df07HwyZlSs6xPy8J13t2OZSwYJ3glCkvP+IS3N
RYhsVovqJfnS8ivPdOAE3zL2IgyNIOImIKtJV2PnjPz4axMfsrrIrnkAEQEAAcLB
fAQYAQgAJhYhBCZGrv/LcFd96WQIrKTnMUVIo1T2BQJpIdQEBQkFo5qAAhsMAAoJ
EKTnMUVIo1T2sHgQAIbBaYZyFQ/adAq983iD04+NVP30DvrATTQrdNZm8NlP106E
1K+pqpOiWzwGQ65LNpY0ZW4wf7KhSQVZqtn2D+kRRTQbsyhYXnzS3MoEE7Xhx+pz
8XoiGfkIxcyqC+AfNJEFQ4gCbyJK+GaUSMmTpwM/PaAvI5SCMf7V6W1WYIsmF11A
vvikPU/dtvaRs+UPDYsRt3hbtyGlheq+g9vvheXbyhEIhq3UsHQVkI/oRDsCIq1d
BUIzMPrkzepWf9TNcwlHPHABQIWwRU+jYb1FCHwB2OqB6S6aM29736QTXMSX6NCP
Br5ha++mMjgqaFver0iqW5gnafDUcKf9v/rkhzecPfxaJ9AVXQ4F4UL1Vvtniv7H
MDQ0drYsB9yN8vOXPRO6wbe7A5Ji3+Pc9ntFUOmJ86cQU6FCERc6M96P63WcXVaz
32cMs9RqE1S8Msusd5XEWd3tpvlVoO5IRsh9gQQ+lzxk5Fd3OK/lBW8pzv4ATKn0
P0GqpMHcIw748MKKwZ9MRZFMZaYbmKfEq/EfQ3b478rIuw1BCHSsdZV2tX65MrJY
bDzZ/VvAm6G4wOS/DrhsupuldtaSgrOZiHSC2xNtKAtxbyHVF7rzObqKRdawnmJq
YF2yUbM9NzbBn7Y5zlCkKrPAPspC8r36JgzN1E/uynh3hN/yUb4SZP9vItPI
=M2Hg
-----END PGP PUBLIC KEY BLOCK-----
📨 How to Send an Encrypted Email
- Import the PGP key above into your email program (Thunderbird, Mailvelope, ProtonMail, etc.).
- Select info@maryvilleprivacy.org as the recipient.
- Your mail client will automatically encrypt the message.
- Send your email normally — only we will be able to decrypt it.
For best results, we recommend Thunderbird (desktop) or ProtonMail (web or mobile).
This archive provides publicly obtained records for academic, journalistic, and public-interest research.
© MaryvillePrivacy.org — Community Open Records Initiative