Your intellectual property cyber security stack protects the bytes on the wire. The camera watching the server room is the gap.

Because modern surveillance is no longer a set of dumb coax cameras and a DVR in a locked closet. A contemporary deployment adds IP cameras with their own ARM SoC and Linux stack, a VMS or NVR with an RTSP listener, a cloud relay for remote viewing, and increasingly an AI inference box that opens long-lived connections to every camera on the property. Each of those is a networked computer, each has firmware with CVEs, and each sits on or near the same network segments that carry your source repositories, your CAD exports, and your build artifacts. The moment a surveillance device speaks TCP, it enters the IP cyber security scope. Treating it as a facilities problem is how IP-bearing rooms end up guarded by the weakest-patched Linux box on the floor.

On a typical camera-first deployment you add a new Linux device with a GPU, a web dashboard on port 443, an SSH or similar admin interface, one outbound TLS tunnel to the vendor cloud, and up to 25 persistent inbound RTSP connections from the camera VLAN. That device is often racked in the same closet as the DVR, sometimes on the same VLAN, and almost always with a route to the corporate network for single sign-on. The surface includes: the inference box's OS and GPU driver stack, the RTSP parser, the vendor cloud relay, the cached video stored locally for review, and the credentials the box holds for the cameras. A compromise of any one of those turns the camera watching your R&D lab into a live feed available to whoever owns the box. For an IP cyber security posture, that single device is often the softest Linux target inside the perimeter.

It removes the network entirely. The Cyrano unit reads the composite HDMI multiview the DVR already renders for the guard monitor, so it never opens an RTSP connection, never asks for a camera password, and never joins the property LAN. It has zero IPs on your network. Its only uplink is a cellular eSIM. The DVR-to-monitor HDMI cable passes through the unit on its way to the screen, which means from the camera network's perspective, nothing changed. For an IP cyber security program, that means adding AI to watch a server room does not add a single attacker-addressable endpoint to the LAN that carries your IP.

Per delivered HIGH event, roughly 240 KB: an 18 KB JPEG thumbnail, a 220 KB H.264 clip of about six seconds bracketing the detection, and a 612 byte JSON metadata object. Nothing else. No continuous upload of the multiview frame, no face embedding, no plate string, no audio, no live stream. On an average IP-bearing floor with tuned zones, that is between 5 and 40 events per day, or on the order of 1 to 10 MB per day off-property. For comparison, a typical cloud AI camera platform uploads 1 to 3 GB per camera per day of continuous or motion-triggered clips. Three orders of magnitude less video crosses the property boundary, all of it over cellular, none of it on your LAN.

It is, and an IP cyber security program still has to harden it. The difference is that the DVR is already in your scope and usually already on an isolated camera VLAN with no inbound route. Adding a monitor-first AI unit does not change that posture. It does not require the DVR admin password, it does not require opening a port, it does not require putting a new device on the camera VLAN. The control plane for the AI is the cellular modem, not the property LAN, so the blast radius of a Cyrano compromise ends at 'an attacker sees 240 KB event thumbnails' rather than 'an attacker has a shell on a Linux box with credentials to every camera.'

It fills a gap the data-centric tools cannot reach. DLP watches file movement, EDR watches endpoint behavior, CASB watches SaaS egress. None of them see a phone pointed at a whiteboard, a contractor photographing a prototype, or a person with a USB stick in a rack aisle. Physical surveillance of IP-bearing rooms covers that layer. The trap is that most AI surveillance stacks added to do this job re-import the exact risk the rest of the program spent years reducing: a networked, cloud-connected, credential-holding Linux device inside the perimeter. An HDMI-tap architecture closes the physical-layer gap without reopening the network-layer one.

Small and mid-market R&D floors, prototype machine shops, biotech wet labs, secure data closets on multi-tenant office floors, engineering mock-up bays, and law firm document rooms. The common shape: a DVR or NVR already exists for compliance or insurance reasons, the monitor already lives in a back office, and the company wants AI on the footage without reworking the camera plant. The architecture also fits well with regulated environments where camera footage of the interior cannot legally leave the country or the building: the raw multiview never leaves, only event-level payloads do, and those can be routed to an on-premise event sink over cellular backhaul if a cloud receiver is not allowed.

The same way any physical surveillance does: it records and alerts on presence in zones that should be empty at a given hour. The difference an HDMI-tap unit makes for the insider case is that the insider's network access, even if it is broad, does not extend to the surveillance stack. The AI unit is not on any LAN the insider can reach. They cannot disable the inference by SSH'ing into an exposed dashboard, cannot rewrite zone definitions from their laptop, cannot pause alerts from inside the building. Control is through the cellular-backed dashboard only. That is a meaningful hardening against the motivated insider who would otherwise target the camera network first.

Three concrete ones, all small. First, an attacker with physical access to the gatehouse could unplug the unit; detection coverage stops, but no data leaks. Second, a supply chain compromise of the cellular eSIM vendor could affect egress; the mitigation is that the only thing on that path is event payloads, so the blast radius is bounded. Third, the DVR itself could be compromised via its own network interface, which is a pre-existing risk the monitor-first architecture neither creates nor solves. None of these introduce a new attacker path into the corporate LAN or to the IP traffic on it. That is the specific property the architecture is designed to preserve.

They can. The default path is Cyrano's cloud event receiver, but the unit can be configured to POST the 240 KB event payload to an on-premise HTTPS endpoint over the cellular uplink, and the uplink is cellular specifically so it does not require any path through the corporate network. For regulated environments that require event data to land on an owned server, this preserves the property that the multiview never leaves the building while still letting the event metadata and clips be ingested by an internal SIEM or video audit system.