Adoption is outpacing the controls around it

AI is entering most organizations faster than the security work that should surround it, because a working prototype is now a weekend of effort while getting scoped credentials provisioned can take three weeks. The result is a familiar shape: an assistant running on a real person’s account or an over-permissioned service principal, pointed at a whole document library or mailbox because narrowing the scope would have delayed the demo. The retrieval layer in these builds has no concept of who is asking, so the system will happily surface a salary sheet or another customer’s file to anyone who phrases the question well — and instructing a model not to reveal something is a request, not a boundary, which is worse than an outright failure because it holds most of the time and manufactures confidence. Layered on top is a trust problem: teams connect third-party AI tools, browser extensions and plug-ins to production data on the strength of a vendor page, without reviewing what those integrations retain or where the traffic goes. IBM’s 2026 breach research found more than a fifth of organizations had already suffered a breach involving their AI models or applications, with compromised APIs, applications or plug-ins and misconfigured AI cloud workloads each accounting for roughly a quarter of those incidents.

What you gain by building it the other way round

Designing the controls in from the first workflow costs a fraction of retrofitting them, and the difference compounds: scoped identity, permission-trimmed retrieval, approval gates and decision logging are perhaps two extra weeks on your first automation and close to zero on every one after it, because each subsequent build inherits the pattern. That inheritance is why organizations that do this ship their fifth automation faster than their first, while those that do not tend never to reach a fifth. A logged, owned, least-privilege system also survives the questions that eventually arrive — from an auditor, an insurer, or a prospect’s security questionnaire — so security stops being the thing that blocks the program and becomes the thing that lets it expand into regulated data. Containment improves too: when an agent can only reach the records its design requires, a compromised credential or a bad instruction is an incident with a boundary rather than an enterprise-wide one. Most importantly, staff actually use a system they can see the reasoning behind, and adoption is what determines whether any of the projected value materializes.

How AIONYX closes the gap

If you already have AI in production, we start with an assessment of what is really deployed: which accounts and service principals your automations run as, what each one can reach, whether retrieval enforces the requesting user’s actual entitlements, what is being logged and for how long, and which third-party tools have been connected to your data. You get a ranked remediation plan with an owner and a date against each item, not a list of findings sorted by severity score. If you are building from scratch, we design and run the automation with the controls in place from day one — a dedicated service principal scoped to exactly the systems its work requires, credentials in a managed vault on a rotation schedule, document-level permission trimming at query time, private model endpoints with no third-party training on your data, decision-level logging retained to match your regulatory obligation, human approval gates on anything that sends externally or moves money, and a kill switch any authorized member of staff can operate from one screen. Every build runs in shadow mode against live work before it touches anything real, then moves to supervised and finally autonomous operation only where the measured accuracy supports it. Because we run both the automation and the security program under one contract, there is no gap between the team that ships the agent and the team responsible for defending it — which is precisely the gap this article is about.

Physical security and network security are usually bought from different people, on different budgets, at different times. The camera system is specified by facilities, installed by a low-voltage contractor, and never appears on an IT asset register.

Which is how it ends up as an unmonitored, unpatched, internet-adjacent computer inside your perimeter, and why camera estates are one of the more reliable sources of serious findings during an assessment.

What we actually find

Across camera estates we have assessed, these are the recurring findings, roughly in order of frequency.

Default or shared credentials

By some distance the most common. The installer used one password across every device so maintenance was easier, and that password is often the manufacturer default or a trivial variation. It is frequently documented in a shared file, and it is rarely rotated when the contractor relationship ends.

Firmware years out of date

Cameras are commissioned and then never touched, because nothing appears to be wrong. Firmware from four or five years ago is normal. Known, published vulnerabilities with working public exploits are common. Nobody is watching for advisories because the device is not on anyone’s inventory.

Flat network placement

The cameras sit on the same VLAN as workstations and servers — often the same subnet as finance systems. There is nothing preventing a compromised camera from reaching anything else on the network, and no monitoring that would detect it trying.

Direct internet exposure

Someone wanted remote viewing, so a port was forwarded. The device’s web interface is now reachable from anywhere, running old firmware, with the shared credential. Internet-wide scanning services index these continuously; discovery is not the attacker’s hard part.

Unauthenticated video streams

RTSP streams frequently allow anonymous access even when the management interface is password-protected, because they are separate settings and only one of them is obvious.

Wrong or absent time synchronisation

Less dramatic, but it matters at exactly the wrong moment. If a camera’s clock is fifteen minutes out and NTP was never configured, the footage is significantly weaker as evidence — and you discover this while trying to use it.

Why this is worse than it sounds

A compromised camera is attractive for three reasons that have nothing to do with watching video.

First, it is a persistent foothold. Cameras run continuously, are rarely rebooted, and are almost never included in endpoint monitoring. An implant can sit there for a very long time.

Second, it is a pivot point. From a device on a flat network, an attacker can scan and reach systems that are genuinely valuable.

Third, the footage itself is sensitive. Camera coverage of reception areas, workstations and access points is useful reconnaissance for physical or social engineering, and in some jurisdictions unauthorised access to it is a notifiable data breach in its own right.

The finding we report is rarely “your cameras are vulnerable”. It is “there is a five-year-old unpatched Linux device on the same network segment as your finance systems, and nothing is watching it”.

The eight-point baseline

This is the standard we commission every installation to, and the checklist we use when auditing an inherited estate.

1. Dedicated VLAN with explicit-deny policy. Physical security devices on their own segment, with firewall rules permitting only the specific flows the system requires. No path from a camera to a business system.
2. Unique per-device credentials. Default accounts disabled or renamed, unique strong credentials per device held in a managed vault, rotated on a schedule and on any contractor change.
3. Firmware baseline and patch schedule. Every device brought to a supported version at commissioning, with a named owner subscribed to vendor advisories and a quarterly patch window.
4. Unnecessary services disabled. UPnP, Telnet, unused ONVIF profiles, manufacturer cloud connectors and anonymous RTSP all switched off unless there is a documented reason to keep them.
5. No direct internet exposure. Remote access via VPN or an authenticated broker service. Never a port forward, regardless of how convenient it is.
6. NTP configured and verified. Synchronised to a reliable source so timestamps hold up as evidence, and verified at commissioning rather than assumed.
7. Retention matched to written policy. Storage sized to your actual retention obligation, with the calculation documented. Over-retention carries privacy risk; under-retention means the footage is gone when you need it.
8. Inventory and monitoring. Every device on the IT asset register, with health monitoring that alerts when one goes offline. A camera that failed silently three weeks ago is the one covering the incident.

If you inherited an estate

Start with an inventory, because most organisations do not have one and cannot answer basic questions about their own estate. Then, in order: check for internet exposure, change shared credentials, confirm network placement, and check firmware versions against vendor advisories.

Those four steps take a competent engineer a day or two on a typical single-site estate and will resolve the majority of the serious risk. The segmentation work is a project; the credential and exposure work is not, and it is where the immediate exposure sits.

If you are buying new

Put the eight points into the tender document and make them acceptance criteria. Ask how firmware will be maintained after handover, and who owns that. Ask for the network design, not just the camera placement plan.

An installer who cannot answer those questions is quoting for a different job than the one you need done — and the gap between the two is where these findings come from.