Security is the foundational prerequisite for adopting enterprise generative AI at scale. Enterprise security architecture encompasses air-gapped data plane execution, end-to-end encryption in transit and at rest, zero prompt retention guarantees, and strict kernel-level tenant isolation. Protecting proprietary intellectual property, employee credentials, and sensitive customer conversations requires defense-in-depth across the entire network, compute, and database topology.
Unprotected API usage risks exposing proprietary enterprise code, private customer conversations, and legal documents to public model retraining corpora and external third-party logging sinks.
Sensitive inference payloads traversing unencrypted or inadequately authenticated internal network segments can be intercepted, inspected, or manipulated by unauthorized actors.
Flawed database isolation logic can allow malicious actors or compromised service tokens to query other tenants' private request logs, financial balances, or virtual keys.
Adversarial completions attempting to execute unauthorized local shell commands or exfiltrate backend environment variables must be blocked before reaching client runtimes.
Strict multi-tenant isolation enforced at the database kernel level; NOBYPASSRLS connection pooling.
Sidecar operates with zero public internet egress and zero database access, linked only via mTLS 1.3.
TLS 1.3 with HSTS preloading in transit, AES-256 for persistent records, and Key Vault secret sealing.
nRouter enforces an uncompromising security framework across every layer of the architecture. All database transactions execute over tenant-pinned connections with PostgreSQL Row-Level Security (RLS) and NOBYPASSRLS enforcement, eliminating cross-tenant leakage risks. The nrouter-cortex guardrails sidecar operates completely air-gapped—zero public egress and zero database access—communicating exclusively with the gateway over internal mTLS 1.3. Upstream provider credentials remain encrypted in Azure Key Vault, and strict enterprise zero-retention data policies ensure prompt content is never persisted without explicit consent.
Review our security whitepaper, architectural boundaries, and penetration testing certifications in the guides below.
How an LLM gateway runs active PII redaction, prompt-injection detection, and keyword blocklists inline on every request, with key > team > org precedence.
Bring-your-own-key sounds customer-friendly and mostly relocates work to you. nRouter issues one key and credits and manages every provider account — here is the reasoning, the blast-radius math, what the choice costs you, and who should pick a BYOK gateway instead.
"Who rotated that key, and from where?" should be a filter, not an archaeology project. Here is the audit-trail contract we hold ourselves to on an LLM gateway: complete actor attribution, one shared client-IP path, append-only entries, and reads that are role-scoped and tenant-isolated.
A criterion-by-criterion checklist for putting an LLM gateway through SOC 2 — access control, audit attribution, retention, encryption, tenant isolation and availability — with the honest current state of each control on nRouter.
How keys, budgets, and guardrails scope across org, team, and key tiers on an LLM gateway, and why attribution is read from key hashes, never user headers.
A management credential and an inference credential are different tools with different blast radii. Here is how to issue one virtual key per environment-and-service pair, narrow it with the four scope fields, cap it, and rotate it without downtime.
