Building Secure AI Systems for Restricted Network Environments
Building Secure AI Systems for Restricted Network Environments
In fields like defense, finance, healthcare, and critical infrastructure, security policies often mandate strict network isolation. Subnets holding proprietary IP, client records, or trading algorithms are completely disconnected from the public web.
However, as engineers and decision-makers increasingly rely on advanced AI models (like GPT-4o or Claude 3.5 Sonnet) to run their operations, this isolation presents a massive obstacle.
How can a team access high-performance cloud AI from a workstation that has no route to the internet? And how can security teams guarantee that sensitive data is not leaked, intercepted, or abused in the process?
At Seven Labs, we designed a zero-trust network relay using Bluetooth RFCOMM and application-level encryption to solve this exact problem. Here is an in-depth look at how we build secure AI systems in highly restricted environments, detailing our cryptographic choices, proxy architectures, and threat mitigation models.
1. Threat Modeling for restricted AI Access
When introducing an external communications channel (like Bluetooth or a hardware bridge) into a restricted zone, we must analyze the attack vectors. Our threat model identifies three primary risks:
RESTRICTED ZONE (Air-Gapped Workstation) UNTRUSTED TRANSIT (Bluetooth / WAN)
+-------------------------------------+ +----------------------------------+
| [Data Exfiltration] | Sniffing | [Eavesdropping / MitM] |
| Workstation files leaked via AI API |============>| Rogue nodes intercept data stream|
+-------------------------------------+ +----------------------------------+
^ ^
| |
+---------------------[Injection]-------------------+
Malicious system modifications
- Data Exfiltration: Malicious software or users on the offline PC packaging sensitive local assets into prompt payloads and transmitting them out of the network under the guise of an LLM query.
- Eavesdropping and Man-in-the-Middle (MitM) Attacks: Adversaries sniffing the local physical transport medium (such as the Bluetooth radio waves) to capture raw prompts and responses.
- Command Injection and Reverse Tunnels: An attacker using the relay to establish an interactive shell or reverse proxy tunnel, gaining unauthorized remote access to the internal workstation.
2. The Solution: End-to-End Encrypted Protocol Proxy
To address these risks, Seven Labs implemented a protocol proxy combined with application-level End-to-End Encryption (E2EE). The workstation remains IP-isolated; it has no network interface card (NIC) connected to the internet, no default route, and no DNS resolver pointing outside.
Instead, the workstation communicates with an Android-based cellular relay device over an encrypted Bluetooth serial stream.
+---------------------------------------------------------------------------------------------------+
| CRYPTOGRAPHIC PROTOCOL FLOW |
| |
| Offline Workstation (Client) Android Relay (Server) |
| |
| 1. Generate Ephemeral ECDH Key Pair |
| (secp256r1 curve) |
| |
| 2. Transmit Public Key (A_pub) ----------> [Raw RFCOMM Socket] ---------> Received Key (A_pub) |
| |
| 3. Received Key (B_pub) <---------------- [Raw RFCOMM Socket] <---------- Transmit Key (B_pub) |
| |
| 4. Compute Shared Secret (ECDH) Compute Shared Secret |
| S = A_priv * B_pub S = B_priv * A_pub |
| |
| 5. Derive AES-256-GCM Session Key Derive Session Key |
| K = HKDF(S) K = HKDF(S) |
| |
| 6. Encrypt Payload + Auth Tag Decrypt Payload |
| C = Encrypt(Payload, K, IV) --------> [Send Ciphertext] -------------> Process to GPT-4o |
+---------------------------------------------------------------------------------------------------+
3. Cryptographic Implementation: ECDH Handshake and AES-GCM
To prevent any third-party eavesdropping over the air, the connection must be encrypted before any payload transfer. We implement an Elliptic-Curve Diffie-Hellman (ECDH) handshake using the secp256r1 (P-256) curve.
Here is a conceptual implementation of how the client-side workstation initiates this secure tunnel:
// Node.js Client-Side Cryptography Handler (Concept)
import crypto from 'crypto';
export class SecureChannel {
constructor() {
this.ecdh = crypto.createECDH('secp256r1');
this.ecdh.generateKeys();
this.sessionKey = null;
}
getPublicKey() {
return this.ecdh.getPublicKey();
}
deriveKey(serverPublicKey) {
const sharedSecret = this.ecdh.computeSecret(serverPublicKey);
// Derive a cryptographically strong 256-bit key using HKDF-SHA256
this.sessionKey = crypto.hkdfSync(
'sha256',
sharedSecret,
Buffer.alloc(0), // salt
Buffer.from('SevenLabs-AI-Relay-Context'), // info
32 // key length
);
}
encrypt(plaintext) {
const iv = crypto.randomBytes(12); // GCM standard IV length
const cipher = crypto.createCipheriv('aes-256-gcm', this.sessionKey, iv);
let ciphertext = cipher.update(plaintext, 'utf8');
ciphertext = Buffer.concat([ciphertext, cipher.final()]);
const tag = cipher.getAuthTag();
// Package: IV (12B) + Tag (16B) + Ciphertext
return Buffer.concat([iv, tag, ciphertext]);
}
decrypt(buffer) {
const iv = buffer.subarray(0, 12);
const tag = buffer.subarray(12, 28);
const ciphertext = buffer.subarray(28);
const decipher = crypto.createDecipheriv('aes-256-gcm', this.sessionKey, iv);
decipher.setAuthTag(tag);
let decrypted = decipher.update(ciphertext);
decrypted = Buffer.concat([decrypted, decipher.final()]);
return decrypted.toString('utf8');
}
}
By deriving an ephemeral session key that is never stored on disk and changes with every connection, the system achieves Perfect Forward Secrecy (PFS). If an adversary captures the encrypted RFCOMM stream over the air and steals the device's pairing key later, they still cannot decrypt past sessions.
4. Preventing Data Exfiltration: Content Filtering and DLP
Simply encrypting the transport channel is not enough. An internal attacker or compromise on the workstation could use the relay to stream gigabytes of source code or customer data out of the zone.
To prevent this, the Android Relay application acts as a Data Loss Prevention (DLP) proxy:
- Payload Inspection: The relay decrypts the prompt, parses the JSON structure, and runs local regex and semantic classification scanners.
- PII and Target Asset Scrubbing: If the scanner detects credit card numbers, social security identifiers, internal database connection strings, or specific proprietary keywords, the relay blocks the request immediately.
- Size Limits: Hard limits are enforced on prompt tokens (e.g., maximum 4,000 tokens) to prevent bulk document exfiltration via large prompts.
5. Mitigating Command Injection and Shell Execution
Standard network bridges run the risk of an attacker reversing the link to execute commands on the internal system. The Seven Labs design prevents this by restricting the transport to an application-level API proxy.
There is no raw TCP socket forwarding. The workstation client cannot make arbitrary TCP requests to external IP addresses, nor can the external relay write commands back to the workstation's OS. The only valid data formats are structured JSON messages matching the chat completion schema. Any incoming message that does not pass schema validation is instantly dropped.
6. Security Architecture Best Practices Checklist
If your engineering team is tasked with building an AI interface for restricted subnets, adhere to the following checklist:
- Protocol Isolation: Use a non-routable physical layer (like Bluetooth RFCOMM or custom USB serial) instead of bridging TCP/IP networks.
- Ephemeral Session Cryptography: Handshake using ECDH and encrypt payloads using AES-GCM or ChaCha20-Poly1305.
- Strict Schema Validation: Reject all packets that do not strictly conform to your predefined JSON schema.
- Local Audit Logging: Write tamper-proof logs on the local workstation, tracking every model query, token count, and destination.
- Content Scanning: Scan prompt payloads at the gateway for credentials, keys, and PII prior to transit.
7. Enterprise Frequently Asked Questions
Can this system defend against physical access attacks?
If an attacker gains physical control of the workstation and the paired mobile device, they can query the AI system. However, they cannot use the connection to extract keys or compromise the network because the session keys are ephemeral, and the communication channel is restricted to application-layer JSON commands.
How does this compare to on-premise local LLMs?
On-premise LLMs (like hosting Llama-3-70B on internal servers) offer complete isolation but require significant upfront investment in GPU hardware, cooling, and maintenance. Our relay system offers an alternative: accessing state-of-the-art cloud models while keeping the workstation isolated from general internet access.
Is Bluetooth secure enough for corporate use?
By layering ECDH key exchange and AES-256-GCM encryption on top of the Bluetooth physical layer, the security is equivalent to TLS. Standard Bluetooth vulnerabilities (such as BlueBorne or pairing-key sniffing) only target the lower stack layers and cannot read or alter our encrypted payload.
Technical SEO Schema & Internal Links
- Keywords: Secure AI Systems, Air-Gapped AI, Enterprise AI Security, Restricted Network LLM.
- Internal Links:
- Learn about our secure programming in SaaS Development services.
- Understand how we identify system loopholes via VAPT Audits.
- Reach out to our secure systems engineers on our Contact page.
Secure Your Core Enterprise Infrastructure with Seven Labs
Maintaining security in restricted network environments does not mean you have to fall behind in AI capabilities. Seven Labs designs, builds, and audits secure communication links and custom AI relays that respect your network boundaries.
Consult with Seven Labs' Security Engineers to safeguard your enterprise AI systems today.
Seven Labs Service
VAPT Penetration Testing & Cybersecurity