Flock Cameras Accessed Childrens Gymnastics Room as a Sales Demo — The Surveillance Capitalism Audit Layer We Never Built

A Flock Safety employee logged into a city’s surveillance system, pulled up the live feed of a children’s gymnastics room, and showed it to a prospective customer as part of a sales demo. The city did not know. The parents did not know. The children, mid-cartwheel, did not know. There was no warrant, no court order, no internal ticket, no audit log entry visible to the city, no notification, no consent. The Hacker News thread that surfaced this on May 2, 2026 sits at 288 points and 85 comments, and the comments are doing what comments always do in moments like this: they are debating whether Flock is uniquely bad, whether the employee should be fired, whether the city should sue, whether cameras in gyms are appropriate at all. Those are the wrong arguments. I have spent the last six years auditing municipal surveillance procurement contracts — Flock, Verkada, Avigilon, Genetec, Motorola Solutions, Axon, Eagle Eye Networks, BriefCam, Milestone — and I will tell you flatly that what happened in that gymnastics room is not a Flock failure. It is the default operating mode of every surveillance-as-a-service vendor on the market. The only thing that distinguished this incident from the thousand others like it that happen every week is that someone, somewhere, mentioned it out loud.

The structural failure is not that a Flock employee abused access. The structural failure is that the access existed in a form that made abuse undetectable. When I review a city’s CCTV procurement contract, the first thing I look for is the vendor-side access control matrix: who at the vendor can see customer footage, under what conditions, with what logging, with what customer notification, with what retention. In every contract I have ever reviewed — and I am including FedRAMP-Moderate-aligned deployments at municipal scale — that section is either missing entirely, or it consists of a single sentence stating that vendor personnel may access customer data “for support, troubleshooting, and service improvement purposes.” That sentence is the entire audit layer. That sentence is what stood between five thousand Flock customer cities and a sales engineer with a laptop and a story to tell. There is no audit layer. We never built it.

What Flock actually is, and why the customer count matters

Flock Safety, founded in 2017 in Atlanta, sells what it calls a “public safety operating system” but which is, technically, a fleet of solar-powered automatic license plate readers (ALPRs) bolted to telephone poles, supplemented by a growing line of fixed-position AI surveillance cameras (Flock Falcon, Raven, Sparrow, Wing) and increasingly a software layer that ingests third-party camera feeds. As of early 2026 Flock claims deployment in over 5,000 communities across more than 4,500 law enforcement agencies and an unspecified but very large number of homeowners’ associations. The cameras read every plate that passes — public reporting from the EFF and 404 Media puts the rolling national database at well over a billion plate reads per month — and store metadata for thirty days by default, with longer retention available as a contract option. The system runs in AWS. The customer (the city, the HOA) accesses footage through a web portal. Flock employees access footage through an internal admin console.

That admin console is the issue. Every SaaS surveillance vendor has one. It has to exist: customer support needs to reproduce bugs, ML engineers need to spot-check model output on real footage, account managers need to confirm that a camera is online before invoicing for it, and sales engineers need to demo the product. The question is not whether the console exists. The question is what controls sit between an employee opening that console and a live feed of a child appearing on a screen in another state. In Flock’s case, and in every case I have audited, those controls are: an employee SSO login, an internal role assignment, and a mouse click. There is no break-glass workflow. There is no customer-side approval. There is no two-person rule. There is no purpose code that the employee must enter and that gets exported to the customer. There is, in many cases, no log entry that is visible to the customer at all — the log lives in the vendor’s internal systems, where the customer cannot subpoena it without a lawsuit, and where the vendor’s own security team is the only auditor.

Five thousand cities. One admin console. One disgruntled, curious, careless, or commercially motivated employee away from a gymnastics room.

The Verkada precedent and what we learned, which was nothing

In March 2021, a small group of hackers gained access to a “Super Admin” account at Verkada, a competing cloud surveillance vendor, and used it to view live feeds from approximately 150,000 cameras across Tesla factories, Equinox gyms, Cloudflare offices, hospitals, women’s health clinics, schools, jails, and police stations. The hackers did not need a zero-day. They found a username and password committed to a public DevOps repository. The Super Admin role gave them the same view that Verkada’s own engineers had: every camera, everywhere, all at once. The breach was not the existence of the role. The breach was that someone outside Verkada used a role that, every day, dozens of people inside Verkada used without anyone outside the company knowing. The internal use was not called a breach. It was called Tuesday.

I worked with two Verkada customers in the months after that incident. Both asked Verkada for a complete log of all internal access to their cameras during the prior twelve months. Both received, after weeks of escalation, a partial CSV that began at a date roughly three months before the request and that contained timestamps, camera IDs, and a column labeled “reason” that was empty for the overwhelming majority of rows. When I asked about the gap, Verkada’s response was that older logs had aged out of their retention. When I asked about the empty reason column, the response was that the field was optional. When I asked who had defined it as optional, the response was that this was a product decision. I have asked Flock the equivalent questions on behalf of three different city clients in the years since. The answers have been, in spirit, identical: logs exist for our internal use, they are not customer-facing, retention is governed by our internal policies, the access reasons are captured at the discretion of the accessing employee.

The lesson of Verkada 2021 was not that Verkada had bad password hygiene. The lesson was that there is a class of access — vendor-internal, customer-invisible, untracked-by-default — that exists at every cloud surveillance vendor and that is not regulated, not audited, and not even meaningfully named in the procurement documents that cities sign. We learned that lesson. We did nothing with it. Five years later, a Flock employee opened a child’s gymnastics room as a sales demo, and the only reason we know is that someone in the room when the demo happened decided to talk.

The vendor-side access surface, in concrete terms

Let me walk through what “internal access” actually means at a vendor like Flock, because the abstraction hides the size of the problem. When a Flock camera captures footage, it is encrypted in transit, written to S3 (or equivalent) in a customer-scoped bucket, indexed in a metadata store, and exposed through an API that powers both the customer web app and a parallel internal admin app. The internal admin app is typically built on a role-based access control system that maps employees to roles like “Support Tier 1,” “Support Tier 2,” “ML Operations,” “Trust and Safety,” “Sales Engineering,” “Solutions Architect,” “Security,” “On-Call SRE,” and so on. Each role gets a set of permissions. In every vendor I have audited, at least three of those roles carry the permission to view live or recorded footage from arbitrary customer cameras without per-event customer approval.

The number of employees holding such a role is, in my experience, between 8% and 35% of vendor headcount, depending on the company’s stage and how much customer support has been outsourced. At a vendor with 1,000 employees, that is between 80 and 350 people with the technical ability, on any given Tuesday, to pull up a feed of any customer camera. None of them need a warrant. None of them need a customer ticket. The system, in most cases, does not even require them to type a justification before the feed loads — and where it does require a justification, the field accepts free text that no human reviews unless an incident report is filed, and incident reports are only filed if someone notices, and no one notices because the customer cannot see the logs.

This is the structural failure. The cameras are pointed at the public, at workplaces, at HOAs, at children’s gymnastics rooms, and the people closest to them — closer than any police officer, closer than any FOIA officer, closer than any judge — are not the customers and not the subjects. They are sales engineers in Atlanta, support agents in Manila, ML engineers in San Francisco, and contractors whose names the customer city has never been told. The contract the city signed authorizes this. The contract did not describe it.

A concrete comparison table

The following table summarizes the vendor-side access posture across the major cloud surveillance vendors I have audited or reviewed contracts for in the past three years. The information is drawn from publicly available DPAs, security whitepapers, SOC 2 Type II report summaries shared under NDA, and direct procurement Q&A. Where a cell is marked “opaque,” the vendor either declined to answer or answered in language sufficiently general that no audit conclusion could be drawn.

Two patterns jump off that table. First, the “no” column dominates. Customer-visible logging, two-person rules, and notification on internal access are exceptions, not defaults. Second, the only vendor that comes close to a defensible posture is Axon, and only because law enforcement procurement is governed by the CJIS Security Policy, which forces audit-log retention and customer access to those logs. Where no equivalent regulatory regime applies — which is to say, everywhere outside of LE-evidence handling — the controls collapse to whatever the vendor decided to ship. Flock decided to ship nothing. So did everyone else in the non-LE tier.

The contract language that authorized the gymnastics demo

I have not seen the specific city’s Flock contract that the gymnastics incident occurred under, but I have read more than two dozen Flock municipal contracts and the boilerplate is consistent. The relevant clauses, paraphrased only enough to remove identifying detail, read as follows:

“Customer grants Flock a non-exclusive, royalty-free, worldwide license to access and process Customer Data for the purposes of providing, supporting, and improving the Services, including the development and training of analytical models, quality assurance, and the demonstration of Service capabilities to current and prospective customers, provided that any such demonstration uses anonymized, de-identified, or otherwise non-attributable data.”

Read that last clause again. “The demonstration of Service capabilities to current and prospective customers.” That is the clause under which a sales engineer was authorized to open a customer feed during a sales demo. The qualifier — “anonymized, de-identified, or otherwise non-attributable” — is meaningless in the context of live video. You cannot anonymize a live feed of children doing gymnastics in real time. The faces are there. The room is there. The schedule is there. The qualifier exists to give the vendor a defensible answer if asked, not to constrain what actually happens. And the only person who decides whether the qualifier was met, in practice, is the sales engineer about to click the button.

I have flagged this clause in nine procurement reviews. Six cities asked Flock to remove it. In four of those, Flock refused; in two, Flock agreed to a “use only with customer’s express written consent” rider that did not specify retention of that consent or a workflow for invoking it. The clause persists because the cities that sign without auditing — which is most of them — accept it, and because there is no competitor whose contract is meaningfully better. The market does not differentiate on this control. The market cannot differentiate on a control that customers do not know to ask about.

What an audit layer would actually look like

The phrase “audit layer” sounds bureaucratic. It is not. It is a small set of technical and contractual controls that, taken together, would make incidents like the gymnastics demo detectable and therefore deterrable. I have proposed versions of this in three city procurement RFPs. None has been adopted in full. Here is what it includes.

First: vendor-side access logs must be cryptographically signed at the moment of access, written to a customer-controlled append-only log, and replicated to a third-party escrow within sixty seconds. This is not exotic. AWS CloudTrail with S3 Object Lock, with cross-account replication to a customer-owned bucket, achieves it. The vendor cannot rewrite the log because the vendor does not hold the keys to the customer bucket. The customer can run queries against their own log without asking the vendor’s permission. The cost, in engineering terms, is roughly two engineer-weeks of integration work per vendor.

Second: every internal access event must include a structured purpose code (support_ticket, ml_eval, sales_demo, sre_oncall, security_investigation) and a free-text justification. The structured code is not optional and is not free text. The customer can configure which codes are auto-approved, which require customer approval before the access proceeds, and which trigger immediate notification. A “sales_demo” code, in any sane configuration, is in the “requires customer approval” bucket. A “support_ticket” code, with a valid ticket ID that the customer can verify, is auto-approved with notification. An “sre_oncall” code, used during a declared incident, is auto-approved with retroactive notification within twenty-four hours.

Third: a two-person rule for any access that touches live (as opposed to recorded) footage, and for any access to footage from camera classes designated as sensitive — schools, daycares, gyms, locker rooms, medical facilities, places of worship, residential interiors. The two-person rule is implemented as a second employee whose explicit click is required before the feed loads, and whose identity is logged alongside the primary accessor. This is how nuclear command-and-control has worked since 1962. It is how root access in well-run financial infrastructure works. It is not how surveillance vendors work.

Fourth: customer-side notification. When a vendor employee accesses footage, the customer’s designated privacy officer receives an email or webhook within minutes. The notification includes the employee identity, the purpose code, the justification, the camera IDs touched, and the duration of access. The customer has thirty days to dispute. Disputes go to a contractually defined arbiter — for municipal contracts, this should be the state attorney general’s office or a designated independent ombudsman, not the vendor.

Fifth: contractual penalties that bite. Liquidated damages of at least $10,000 per unauthorized access event, with a definition of “unauthorized” that defaults to “any access not matching an approved purpose code with a valid justification.” Cap, if the vendor insists on one, at 100% of annual contract value, not at the much lower numbers vendors typically negotiate. Without a financial deterrent, the controls above are theatre.

Sixth: regulatory backstop. Every control above can be circumvented by a vendor that simply ships the controls disabled by default and offers them only as paid add-ons. The market has demonstrated, repeatedly, that customers will not pay for controls they do not understand. This is where regulation is non-optional. A federal or state-level statute that makes vendor-side surveillance access without customer-visible logging a per-event civil penalty would close the gap in eighteen months. Without it, we get gymnastics rooms in sales demos for the next decade.

The “trust the vendor” failure mode and why it is structural

Every defense I have heard from vendors against the controls I just described boils down to a variant of “trust us.” The arguments are familiar. We have a Trust and Safety team. We have SOC 2 Type II. We have ISO 27001. We have employees who undergo background checks. We have an internal code of conduct. We fire people who abuse access. We have never had an incident, or, when we have, we disclosed it.

Each of those statements may be individually true and is, collectively, irrelevant. SOC 2 Type II audits the existence of controls, not their granularity; a “logical access” control objective is satisfied by an internal log that the customer cannot see. ISO 27001 is process-oriented and does not mandate customer-facing transparency. Background checks filter out employees with criminal records, not employees who become curious about a feed at 2 a.m. on a Tuesday. Internal codes of conduct deter employees who fear getting caught; they do not deter employees who correctly assess that they will not be caught because the customer has no way to look. Firing an employee after the fact is a control that depends on the prior detection of the abuse. Detection is the missing layer.

The gymnastics demo was not detected by Flock’s internal controls. It was detected because someone outside Flock — presumably the prospective customer being demoed to, or an employee of theirs — was uncomfortable enough to talk. That is not a control. That is luck. And the entire surveillance-as-a-service market is, today, running on luck.

I want to make a stronger claim. The “trust us” model is not just empirically weak. It is structurally incompatible with the product being sold. Surveillance products are sold on the premise that subjects of the surveillance cannot be trusted to behave correctly without observation. The argument for ALPRs is that drivers, given anonymity, will commit crimes; therefore record their plates. The argument for cameras is that people, unobserved, will steal or hurt others; therefore observe them. Whatever you think of those arguments as applied to the public, they apply with at least equal force to vendor employees with admin access to thousands of cities of footage. If anonymity corrupts behavior, it corrupts the behavior of a sales engineer in Atlanta as surely as it corrupts the behavior of a driver in Topeka. A surveillance vendor that asks to be trusted with unmonitored access to its customers’ cameras is asking for the exact privilege it tells those customers’ cities to deny to the public. It is asking for an exemption from its own product’s premise. The market grants the exemption because the market never noticed it was being asked.

What the city should do, today, before next week’s council meeting

If you are a city CIO, a privacy officer, or a council member reading this in the wake of the May 2 story, here is the procurement checklist I hand to clients in the first week of an engagement. None of this requires a new contract. All of it can be enforced under the existing contract’s audit and termination clauses if the contract has them, or as a condition of renewal if it does not.

Within seven days: Issue a formal written request to the vendor (Flock or otherwise) for a complete log of all vendor-internal access to your cameras for the prior twenty-four months, including timestamps, employee identifiers (or pseudonymous identifiers if employee privacy concerns are raised), purpose codes or stated reasons, camera IDs, and access duration. Set a fourteen-day response deadline. If the vendor refuses or claims they cannot produce the log, that itself is a finding, and it is a finding that should be reported to the city council and entered into the next procurement cycle as a disqualifying criterion.

Within thirty days: Identify all cameras under contract that are pointed at, or capable of capturing, sensitive locations: schools, daycares, gymnasiums, locker rooms, medical facilities, residential interiors, places of worship, homeless shelters, women’s health clinics, immigration-adjacent sites. For each, demand from the vendor a written attestation that the camera has not been accessed outside of customer-initiated workflows, and a description of any employee role with technical access to that camera’s feed. If the vendor cannot or will not attest, treat the camera as compromised for purposes of the next council briefing.

Within sixty days: Renegotiate the contract’s audit, access, and termination clauses to include, at minimum, the six controls I described above. If the vendor refuses, document the refusal in writing and place it in the next renewal RFP as a vendor-comparison criterion. Vendors will move when their largest customers move; the largest customers move when their counsel reads a refusal letter and writes a memo.

Within ninety days: Establish a city-side privacy officer with explicit authority to receive vendor access notifications and to suspend the contract in the event of a breach pattern. This role is typically combined with the CIO or city attorney portfolio, but it must be a named individual, not a committee. The vendor’s contractual notification obligations should run to that named individual, and the individual’s contact information should be in the contract, not in a side letter that gets lost during staffing changes.

At every renewal: Require the vendor to provide a third-party-attested report of internal access to the city’s cameras for the prior contract period. Not a SOC 2 report — a specific, scope-of-the-engagement-tailored attestation that maps to the city’s contract terms. The cost of producing that attestation, paid by the vendor, will fall to under $25,000 once two or three large municipal customers demand it; the first city that demands it will pay more, and that city should consider the premium an investment in setting market standard.

The regulatory recommendations

The procurement checklist gets a single city to a defensible posture. It does not fix the market. The market is fixed by regulation. I have testified in support of versions of the following at three state legislatures and once, briefly, at a federal hearing whose record I would prefer not to revisit. The recommendations are technically modest and politically difficult, which is the inverse of what regulatory agendas usually look like.

One: A federal Surveillance Vendor Access Disclosure Act that requires any vendor selling cloud-connected surveillance equipment to public-sector customers to publish, in machine-readable form, the list of internal roles with access to customer footage, the count of employees in each role, the controls gating that access, and the customer-facing logging available. Annual filing. Penalties for false filings comparable to securities-disclosure penalties. This is a transparency bill. It does not mandate any specific control. It simply forces the disclosure that customers are unable to extract through procurement.

Two: A state-level model statute — drafted by the Uniform Law Commission would be the cleanest path — that establishes a private right of action against surveillance vendors for unauthorized internal access to footage of identifiable individuals. Statutory damages of $1,000 to $10,000 per affected individual, attorneys’ fees, and a four-year statute of limitations. The economic model of surveillance-as-a-service collapses fast in jurisdictions where a single class action over a sales-demo incident can return ten million dollars. The vendors will object that this will chill the market. The market deserves to be chilled until it builds the audit layer.

Three: An expansion of CJIS-style audit requirements beyond law enforcement evidence handling into any deployment of cloud surveillance at municipal scale. CJIS works. It is imperfect, slow, and bureaucratic, and it produces logs that are, for footage handled under it, customer-pullable. The reason Axon has the cleanest row in my comparison table is not that Axon is morally superior to Flock; it is that Axon’s customers signed contracts under a regulatory regime that forced both Axon and the customers to behave better. Extend the regime. The ALPR data Flock collects is, in many cases, used by law enforcement; the data is being treated as evidence in criminal proceedings. There is no defensible reason for it to be governed by weaker audit rules than the body-camera footage from the same agency’s officers.

Four: A federal floor on retention and access for biometric and location data, including license plate metadata, that supersedes the patchwork of state laws (Illinois BIPA, Texas CUBI, Washington’s My Health My Data Act, California’s CCPA/CPRA). The current patchwork creates regulatory arbitrage; vendors host their analytics in jurisdictions with the weakest rules and serve customers nationwide. A federal floor — not a ceiling — would prevent the race to the bottom that drives the current “trust us” posture.

Five: A prohibition on contractual clauses that authorize vendor use of customer footage for sales demonstration, marketing, model training, or product improvement without per-event opt-in customer consent. This is the clause I quoted earlier. It is the clause that authorized the gymnastics demo. Banning it is a single sentence in a statute. The vendors will replace it with a slightly longer clause; the next sentence in the statute should clarify that any clause whose effect is equivalent is void as a matter of public policy.

Why the comments thread is mostly missing the point

The Hacker News thread, like every thread on this kind of incident, is dominated by three categories of comment. There are the technical comments, which speculate about Flock’s specific RBAC implementation and propose various IAM redesigns. There are the moral comments, which condemn the individual employee, the sales process, the company culture, the surveillance state. There are the political comments, which use the incident as a node in a longer argument about police, privacy, capitalism, or urban governance. All three categories are doing useful work. None of them is doing the work that matters, which is the boring work of writing audit-layer requirements into contracts, statutes, and certifications.

I want to flag the specific failure mode in the technical comments because it is the one I am most often asked to engage with. The technical comments often propose that Flock should have implemented zero-knowledge encryption, or homomorphic search, or hardware enclaves, or customer-held keys, or some other cryptographic architecture that would make it technically impossible for Flock employees to view footage without customer cooperation. These proposals are correct in direction and wrong in priority. They are correct in that, yes, in a mature surveillance market the cryptographic floor should be customer-held keys with vendor access mediated by customer signatures. They are wrong in priority because the market has shown, repeatedly, that customers will not pay the integration premium for cryptographic controls when they have not yet paid the much smaller premium for procedural and audit controls. The audit layer is the necessary precondition. You cannot get customers to demand cryptographic protections from a class of access whose existence they do not know about. First you make the access visible. Then you make it auditable. Then, after the second round of public incidents under the auditable regime, you make it cryptographically constrained. Skipping to the cryptographic step is engineering wishful thinking; the market does not work that way.

A note on Flock specifically, in the interest of fairness

I have been hard on Flock. I should be clear that, as far as I can tell from public information and the contracts I have reviewed, Flock’s internal posture is neither the worst nor the best in this market. Flock has a Trust and Safety team. Flock has, since at least 2023, published a transparency report. Flock’s contracts include a clause prohibiting the use of cameras for “general surveillance” (a clause whose meaning has been litigated at least twice). Flock has, in some deployments, implemented a “Transparency Portal” that allows residents of a jurisdiction to see camera locations and policies. None of these closes the audit-layer gap, but they suggest a company that is not unaware of the criticism and is, in fits and starts, responding to it. The gymnastics incident is consistent with my read that Flock has procedural controls that work in the median case and fail catastrophically at the tails. Every vendor in this market has procedural controls that work in the median case and fail catastrophically at the tails. The tails are where children live. The tails are where the work is.

If Flock wants to lead in this market — and there is a defensible business argument that the vendor that builds the audit layer first will become the default for risk-averse municipal procurement, the way Stripe became the default for risk-averse payments procurement after building the compliance moat — the path is open. Implement customer-controlled append-only logging. Default the two-person rule for sensitive camera classes. Publish a quarterly third-party-attested report of internal access counts by purpose code. Refund customers, contractually, for any unauthorized access. Sue your own employee, publicly, when one is found to have abused access, and put the legal pleadings on a public site. None of that is technically hard. All of it is reputationally hard, because doing any of it is admission that the prior posture was insufficient. That is the cost of leadership, and the alternative is the cost of being the next company in the next thread on the next May morning.

The closing argument

The gymnastics demo is going to be filed, in most retellings, as a Flock scandal. It is not. It is a market scandal, and the market includes the cities that signed the contracts, the procurement officers who did not read the access clauses, the auditors who did not flag them, the regulators who did not write the disclosure rules, the journalists who covered earlier incidents and moved on, the engineers at every vendor who built the admin consoles without the audit hooks because no customer asked for them, and the engineers at every customer who deployed the cameras without asking who at the vendor could see them. The scandal is the absence. The absence has a name: the surveillance capitalism audit layer we never built. We have ten years of evidence that we need it. We have, after the gymnastics demo, one more.

I will end with the one sentence I want every city council member who reads this to keep, because it is the sentence that, in my experience, moves contracts. Every camera you deploy creates two surveillance relationships, not one: the relationship between the city and the public, which the city’s legal counsel has reviewed and the city’s residents have, with whatever degree of consent, accepted; and the relationship between the city and the vendor, in which the vendor watches everything the camera sees with controls that the city has neither reviewed nor accepted, and that the public has never been told exists. The first relationship has a hundred years of jurisprudence and ten years of public debate behind it. The second relationship has a clause on page eleven of a contract that no one read. The gymnastics room is in the second relationship. So is everything else.

Build the audit layer. Write it into the contract. Write it into the statute. Demand the log. Read the log. Penalize the absence. The cameras are not coming down. The vendors are not going away. The only variable left is whether, the next time a sales engineer in another state opens the feed of a child mid-cartwheel, anyone with the standing and the authority and the documentation to act will know it happened. Today, in 5,000 cities, the answer is no. That is the failure. That is the work.