The TEE mentioned in this article is essentially hardware level identity/encryption similar to the boot chain of a phone or game console, so if you trust nvidia then it sounds like it would work. If you trust nvidia. And all of the other implementation details.

But basic logic says if the data (your prompt) gets processed by anything then it needs to be able to read it.

There is actually Homomorphic encryption where you can operate on encrypted data, but I don’t imagine it’s used much in machine learning since it takes 100-10,000x longer than the plaintext operation.

You also have the option of network booting. Generally the PC gets an initial boot image over the network, then mounts an ISCSI disk for the OS to fully boot from.

This causes disk access to be a bit slow, but is useful for a Pi when you’re tried of the SD card dying and don’t have a M2 hat.

1. https://wiki.archlinux.org/title/Preboot_Execution_Environment
2. https://wiki.archlinux.org/title/ISCSI/Boot

Alternatively, can they run over a tailscale subnet router?

Yes, the cameras wouldn’t need to be aware of tailscale (or a VPN), you’d just put a pi or install tailscale on a PC there and expose the cameras over the subnet router config to your server also on tailscale.

The other answers covered options on hooking up the internal DNS, so here is the https part for the sake of completeness.

One option is running an internal CA, but that’s for crazy people. And you have to distribute your root CA to every device using it, which can be annoying if you don’t have centralized configuration management in place.

If you want https with caddy and don’t want it exposed you can use a DNS challenge with your external DNS provider. Check the list here for your provider.

Assuming docker and your dns isn’t built in you build a custom docker image with the plugins you need. This is a Dockerfile for route53 based on here:

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/route53

FROM caddy:alpine

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

And then a docker-compose.yml in the same dir to use it:

services:
  caddy:
    build: .
    restart: unless-stopped
    ports:
      - 80:80
      - 443:443
      - 443:443/udp
    volumes:
      - ./caddy_data:/data
      - ./caddy_config:/config
      - ./conf:/etc/caddy

With this mount setup you write conf/Caddyfile and include the DNS provider specific configuration relevant to your plugin, probably documented in its repo.

If they’re just internal the simplest way is to add another IP on the same interface to whatever is serving your service, then bind the service to that IP and add the entry in DNS.

If for some reason you want to keep everything hosted on one IP, for a reverse proxy, caddy is pretty simple. An example caddyfile would be:

http://service1.devicename.lan/ { 
    reverse_proxy 1.2.3.4:9005
}

http://service2.devicename.lan/ { 
    reverse_proxy 127.0.0.1:1234
}

This would also allow you to set https in the future using ACME (dns method if internal only) or your own CA / custom cert.

Does this work different than the policy key? As far as I know the keys under software\policies are used by both group policy and intune, and honored by windows home editions so I’d expect they’d work more reliably than an outlook config setting.