Defence and security

AI inside the fence: what a defence site actually needs

On a defence site the question is not whether cloud AI is good enough. Outbound traffic is not permitted, so the system has to be complete inside the perimeter.

Ankit Goel 3 min read

On a defence installation the argument about cloud AI never happens, because it cannot start. There is no outbound connection to have the argument about. Whatever the system is, it has to be complete inside the fence: the models, the data, the processing and the alerts, all on hardware the site owns, with nothing that phones home. That constraint is not a special request. It is the specification.

The cameras are already there

Almost every site with a security problem already has cameras, and usually a lot of them: fixed CCTV on the perimeter, body cameras on personnel, dashcams on vehicles. What it does not have is anyone able to watch all of them, all of the time. Footage gets reviewed after something happens, which is the least useful moment to look at it.

The useful system is not a new camera estate. It is a layer over the estate that exists — one that reads the standard video and image formats those cameras already produce, including camera-original RAW, and turns continuous watching into a small number of alerts a person can act on. Detection of objects and of drones. Number plates, civilian and defence. A person followed across camera zones so their movement across the site reads as one path rather than a dozen disconnected clips. And an alert when the same unknown face turns up at the wire for the third time this week, before that is an incident.

People arrive with their faces covered

This is the layer that decides whether the rest is worth running. At a great many sites, for reasons of weather, dust, religion or intent, people arrive with their faces partly covered, and most recognition systems treat a covering as a non-detection and stop there. Ours does not. Recognition through a covering is one of the layers in the system, and it is unusual enough that we are careful how we talk about it.

We publish no accuracy figures for it on a marketing page. Numbers measured on a benchmark do not transfer to your cameras, your lighting and your people, and quoting them would be a way of sounding precise rather than being useful. What we do instead is run it against your own footage and let you judge the result.

Old footage is evidence too

A system that only works on live feeds throws away everything that was recorded before it was installed. The same layers process archive material, so an incident from last month can be investigated properly, and the enhancement toolkit underneath — noise removal and resolution enhancement that yields detail rather than blocks — makes footage readable that was recorded on cameras nobody is going to replace.

That toolkit runs on a single GPU-equipped laptop. This matters more than it sounds. A great deal of footage is reviewed somewhere that does not have a server room attached, and a system that needs one is a system that does not get used.

What “inside the fence” means in practice

  • No external calls. Not “encrypted in transit” — none. The models are installed on site and the inference happens there.
  • Alerts, not monitoring. The output is a notification with the footage attached, not a wall of screens a person has to watch.
  • Layers you choose. Detection, recognition, plates and enhancement are separate models. A site takes what it needs.
  • Yours to audit. The deployment, the documentation and the ability to inspect what the system does all stay with you.

We are a research team in Mumbai, and this work is built and supported in India. If your site needs it, the first conversation is about your cameras and your constraints, not about ours.

The products this is about

Want the longer version?

Each piece is the short form of a conversation we have often. Tell us where you are and we will tell you what it would take.

Talk to us ↗