Bringing AI in at Verkada

Route controller findings while engineers need proof

Published Oct 24, 2026

You’re a forward deployed engineer working with Verkada’s security and reliability team. The team is in the room.

The setting

provides physical security and building technology for organizations with many sites. Its lets staff manage doors, access schedules and user credentials from web and mobile devices.

Vulnerability findings arrive faster than controller context can be reconstructed.

Fast answers for security administrators pull against the review needed to avoid overstating controller exposure.

Who you’d be doing this for

“My facilities lead asked if this affects our clinics, and I still don’t have a clean answer.”

Jokha Rwigamba · Security Administrator · a character in this brief

Manages door access across a distributed healthcare network using cloud-managed controllers.

What is at stake

Vulnerability findings reach engineers without the controller context needed to judge their severity. You have to decide where the route stops assembling firmware and exposure evidence for a finding and where an engineer takes over to set its severity.

Why it isn’t already fixed

Every obvious fix costs something else. That’s the part you’d have to decide.

  • evidence gathered per finding vs findings reaching engineers
  • AWS evidence reads vs Command context access
  • customer reassurance vs unsupported exposure claims
  • routing coverage vs on-call stability

Why Verkada

Access Control connects cloud-managed door permissions to deployed controllers, so an ungrounded exposure call reaches both physical operations and customer trust.

Written with these in mind

embedded AI systems buildersecurity-minded forward deployed engineerreliability workflow designer

Not your kind of problem? 77 more at Verkada, or browse every organization.

Where the organization context comes fromThe postings this brief was written from, and the reporting read before it.

The organization context comes from public information. The situation and characters are written for the brief.

Job postings it was written from

Public descriptions of the work at Verkada. They are listed as sources, not as openings. The lines under a posting are its own words, where it meets this brief.

Reporting read before this brief was written

The pieces closest to the situation in this brief.

This is the setup. The work is inside.

Running it puts you in the room: the full situation and its constraints, stakeholders who push back in their own words, and the decisions that are yours to make. What you produce becomes a Day One Plan — work you can show someone instead of describing.

Other live briefs connected to this one, and what connects them.

The same setting, from another role

Each is set around Verkada’s Access Control, written for a different role. They’re separate briefs, not the same scenario.

Other problems with a similar purpose

In each of these, as in this one, the aim is to engineer security-critical controls whose correctness holds up even when carefully examined by skeptics.