SoxAI.io: The Most Secure AI Gateway in 2026

1. Why "Most Secure" Matters in 2026

"Most secure" is a claim that has to mean something. In the AI-gateway category, it can't mean "we have a content filter." Three years of LLM deployments in production have shown that the threats are stack-wide — and so is the defense.

In April 2023, Samsung's semiconductor division banned ChatGPT after engineers pasted proprietary source code into the chat box to summarize it. The data was on a third-party server; the company had no way to retrieve it. In February 2023, a Stanford student extracted Microsoft Bing Chat's full system prompt — including its internal codename, "Sydney" — with a few sentences of careful prompting. In February 2024, a tribunal ruled Air Canada legally liable for a fare its chatbot hallucinated — the chatbot's outputs were the company's outputs. Three years, three distinct failure modes, and only the first one is what most teams imagine when they think "AI security."

(For a full technical treatment of how DLP and Prompt Guard address the first two of those incidents, see our Defense-in-Depth deep-dive. This post is about the broader question: what does it take to be the most secure AI gateway — not just to ship a content filter.)

The shape of 2026 makes this question urgent.

Regulatory pressure is operational, not theoretical. The EU AI Act risk-classification phase is rolling out; high-risk LLM applications must document their controls. SOC 2 Type II is now the price of admission for enterprise SaaS procurement, not a nice-to-have. State-level privacy regulation (CCPA, CPRA, Colorado Privacy Act, the Texas Data Privacy and Security Act) keeps expanding the surface area of what counts as a notifiable incident.

Business pressure has caught up. CISO sign-off before LLM production deployment is becoming standard at companies above a few hundred employees. Cyber-insurance carriers are writing "generative AI usage" exclusions and premium loadings into renewal policies. Procurement teams have started asking, in writing, for evidence — encrypted findings, audit chains, key rotation procedures, tenant isolation models. "We have an AI firewall" no longer passes review.

Technical pressure compounds both. New prompt injection techniques are cataloged every month. Model capabilities improve, which means the consequence of a leak or a jailbroken agent grows in lockstep. Most importantly: the attack surface is not a single point. It's the whole stack — identity, tenancy, role assignment, token issuance, request filtering, encryption, audit. A defense at any one of those layers does not save you from a failure at another.

This is the central architectural argument of this post. Most-secure is not a single tool. It's an architecture where every layer is designed to fail safely on its own, and every layer is designed to assume the others will sometimes fail.

That diagram is not marketing decoration. Each ring is enforced in production, on every request that traverses the gateway. The rest of this post is a tour through the rings, in order, with the same standard applied to each: what threat it defends against, what the failure mode is, and how SoxAI implements it.

2. Layer 1 — Identity and Authentication

Every other layer's guarantees rest on knowing who the caller is. Get this layer wrong and nothing downstream matters — an attacker authenticated as system_admin has every privilege the rest of the system grants.

SoxAI supports three authentication paths. They are not redundant; they are choices for different deployment contexts.

Email + password is the lowest-friction option for self-serve sign-ups. Passwords are hashed with Argon2id — the password-hashing algorithm that won the Password Hashing Competition, parameterized to the conservative side of current hardware. Plaintext passwords are never stored, never logged, never returned through any API. Login failures rate-limit to five attempts per account per fifteen minutes; the next attempt receives 429 regardless of correctness. Password reset requests are limited to three per email per hour.

OAuth and OIDC SSO are the recommended path for organizations. Google and GitHub OAuth are wired in directly for personal accounts. For tenants, OIDC SSO connects to Okta, Azure AD, Auth0, Google Workspace, or any compliant identity provider. SoxAI does not store the provider's OAuth tokens; only the user identity is persisted. Account provisioning can be automated through SCIM where the IdP supports it.

WebAuthn is the phishing-resistant option. It supports USB hardware keys (YubiKey, Titan), platform authenticators (Face ID, Windows Hello, Touch ID), and passkeys synced across iCloud or Google Password Manager. WebAuthn is also the mechanism behind step-up authentication — every sensitive admin operation in SoxAI requires a fresh hardware-key tap, regardless of how long the session has been active.

Session tokens are short and rotating:

Refresh tokens rotate on every use. If two refresh requests show up with the same token (which is what session theft looks like operationally), the entire session family is revoked immediately. This is the same defense web banks use; it shifts the cost of session theft from "ongoing access" to "one request, then locked out."

What the layer does NOT defend against is the user choosing a weak password and getting phished. Argon2id can't help if the user typed their password into a phishing page. That's why SSO and WebAuthn exist — and why for tenants, SoxAI strongly recommends them.

3. Layer 2 — Organization and Tenant Isolation

SoxAI is multi-tenant. One running instance serves multiple organizations, each with its own users, teams, policies, channels, quotas, and price tables. The architectural question is: what stops Tenant A from seeing Tenant B's data?

The answer is two independent mechanisms operating at different layers of the stack.

Application-layer scoping is the primary defense. Every database query is generated through sqlc, which means queries are parameterized statements with WHERE tenant_id = $1 baked in at compile time — there is no string concatenation, no ad-hoc query construction at runtime, no SQL injection vector. Every handler in the gateway and console resolves the tenant_id from the authenticated session before constructing any query. Cross-tenant reads simply do not happen at the application layer.

PostgreSQL Row-Level Security is the defense-in-depth backstop. Selected sensitive tables (DLP findings, audit logs, prompt-guard findings) carry RLS policies that scope row visibility to a session-variable app.tenant_id. If a developer ever writes a query that forgets the tenant filter, PostgreSQL refuses to return rows for the wrong tenant. The application-layer scoping is what should always work; the RLS is what catches the bug if the application-layer scoping ever drifts.

Cross-tenant probes return 404, not 403. This is a deliberate design choice. A 403 Forbidden response on a tenant-scoped resource (like GET /v1/tenants/12345/users/678) would tell an attacker that tenant 12345 exists. 404 Not Found returns the same response whether the tenant doesn't exist, the user doesn't exist, or the requesting party doesn't have access. There is no enumeration vector. You can't probe to find out which tenant IDs are real.

Per-tenant configuration flows from the same isolation principle. DLP policies, Prompt Guard policies, channel routing rules, quota assignments, price tables, branding, custom domains — all scoped to the tenant. Tenant A's DLP rules don't affect Tenant B's traffic, and Tenant A's tenant_admin can't see Tenant B's policies.

Self-host is available for organizations where multi-tenancy is not acceptable on principle. SoxAI ships under a source-available commercial license that includes the full source for the gateway, console, and admin tools. Deploy on your own Kubernetes, your own PostgreSQL, your own Redis — same gateway, same DLP engine, same console, running entirely inside your perimeter. The License Engine ensures version + entitlement integrity, but the perimeter is yours.

4. Layer 3 — Teams and Member RBAC

Inside a tenant, who can do what? This is the role-based access control layer, and the design follows the principle of least privilege: new members get the minimum capabilities to do their job, and elevation requires an explicit action by someone authorized to grant it.

SoxAI has five platform roles. They are not a "permission menu" — they are operationally distinct duties, designed so that the role with the most data access (system_admin) has the least operational visibility into specific tenant content, and the role with the most tenant-content access (tenant_admin) has no platform-level powers.

The critical property here is that no platform role sees customer prompt content. A system_admin can decrypt a DLP finding (under WebAuthn step-up, and the decrypt writes an immutable audit row, and the encryption keys are tenant-scoped where appropriate) — but routine operational access to platform health, channel routing, and infrastructure metrics never exposes prompt bodies. Platform admins see audit metadata: who decrypted what, when, why, from which IP. The prompt content is encrypted with key material the platform admin's session does not casually access.

Teams are the structure within a tenant. A team is a group of members with a shared quota policy. A tenant might have a "Production" team with a high quota and a strict DLP policy, an "Experiments" team with a lower quota and audit-only DLP, and an "Interns" team scoped to a cheap model with a hard daily cap. Team-level policies propagate to member tokens; member-level overrides are explicit.

Members are individuals within a team. Each has their own login, their own API tokens (which are bound to the member, not the team), and their own usage records. When a member leaves, revoking their account revokes their tokens — the team's quota remains intact for the rest of the team.

Least-privilege defaults: new members enter at user. Elevation to tenant_admin is an explicit tenant_admin action and is itself audit-logged. There is no implicit "you've been with the org for six months, your role gets promoted" path. Role changes are deliberate.

Tenant admins cannot escalate to platform roles. This is the cleanest cross-tenant containment: a compromised tenant admin can hurt their own tenant, but they cannot reach into another tenant or the platform infrastructure.

5. Layer 4 — API Tokens and Network Controls

Tokens are how applications authenticate to the gateway, and they are the most commonly leaked authentication artifact in any system. The defense is multi-pronged.

Tokens are prefixed sox- — a deliberate choice. Standard secret scanners (gitleaks, trufflehog, GitHub's push protection) recognize the prefix and can flag accidental commits. If your developers paste a token into a repo, the prefix is what makes the leak detectable in CI before it ever reaches a public registry. The other 32 characters of entropy do the cryptographic work; the prefix does the operational work.

Tokens are shown once. When a user creates a token in the console, the plaintext is displayed exactly once. After that, only the SHA-256 hash is stored. If the database is compromised, the attacker gets hashes, not usable tokens. If the user loses the token, they create a new one — there is no "show me my token" recovery path because there is no plaintext to show.

Per-token controls. Each token can be configured with:

• IP allowlist — CIDR ranges from which the token is valid. The same token used from your CI runner's IP is rejected if it suddenly shows up from a residential connection in another country.
• Country allow / deny list — for tokens that should never be used outside specific jurisdictions.
• Tenant scope — every token belongs to exactly one tenant. There is no cross-tenant token by design.
• Optional spending cap — a maximum dollar amount the token can consume before being auto-rejected.
• Rate limits — requests-per-second, requests-per-minute, requests-per-day caps per token.
• Revocation — immediate. Revocations propagate to running gateways through PostgreSQL LISTEN/NOTIFY. The next request hits the rejection within milliseconds, not minutes.

Network-level enforcement. All traffic is TLS 1.3, terminated either at Cloudflare (the default SaaS configuration) or at your own ingress (for self-host). Plain HTTP is rejected before the request body is read — no opportunistic upgrade, no fallback. SSRF prevention validates every upstream URL against an allowlist before any outbound request — a compromised channel configuration cannot redirect traffic to an internal service through the gateway.

Per-channel credentials are encrypted at rest, separately from token storage. Upstream provider API keys (your OpenAI key, your Anthropic key) live in a different encryption domain than user-facing tokens. Compromise of one does not yield the other.

6. Layer 5 — Data Loss Prevention

DLP scans every request body for sensitive content before the request leaves your perimeter. SoxAI ships fifteen builtin detectors covering credit cards (with Luhn validation), credentials (OpenAI keys, Anthropic keys, AWS access and secret keys, GCP service keys, JWTs, PEM private keys), PII (US SSN, Chinese national ID with GB 11643 check digit, email, Chinese mobile, internal IPs filtered against RFC 1918, MAC addresses), and financial (Bitcoin wallets).

Three actions per policy: mask (replace the matched span with [REDACTED_<detector_code>] and forward the rewritten body), block (reject the request with 403), or audit_only (pass through unchanged, record the finding for review). Custom detectors — both regex and dictionary — can be added per tenant for internal codenames, customer ID formats, and tenant-specific patterns.

DLP is fail-closed: if the engine encounters a runtime error, the request is blocked. A blocked legitimate request is a recoverable operational event; a leaked credit card number is a regulator-notifiable incident. The asymmetry decides the failure mode.

For the technical anatomy — detector chains, post-validator design, encryption format, audit invariant, custom-detector implementation — see the Defense-in-Depth deep-dive.

7. Layer 6 — Prompt Guard

Prompt Guard scans every request body for adversarial inputs: prompt injection, jailbreak, system-prompt extraction, tool-hijack, role-confusion, encoding-evasion, and chat-template smuggling. SoxAI ships 195+ builtin Layer-1 patterns across nine languages (English, Chinese, Japanese, Korean, Russian, Arabic, Spanish, French, German), all under open licenses.

Detection uses three layers. Layer 1 (regex + Aho-Corasick dictionary) catches the bulk at ≤ 2 ms. Layer 2 (Unicode-anomaly and zero-width-character heuristics) is seeded but currently inactive — runtime activation is on the immediate roadmap. Layer 3 (optional LLM-judge) catches semantic edge cases at ≤ 200 ms under a strict deadline, with a per-tenant daily call budget so traffic spikes cannot become runaway cost.

Three actions per policy: block (403 with prompt_injection_blocked), sanitize (rewrite the matched spans, then forward — three sub-modes: strip, wrap_quote, replace_token), or audit (pass through, record).

Prompt Guard is fail-open — the opposite of DLP. A missed detection degrades a defense layer; a blanket block from a scanner crash produces a system-wide outage. Cost asymmetry runs the other way.

Full technical treatment — the three-layer rationale, threat-category taxonomy, LLM-judge implementation, performance budget — is in the Defense-in-Depth deep-dive.

8. Layer 7 — Encryption at Rest and Multi-Key Rotation

DLP findings, Prompt Guard findings, and any other sensitive payload stored at rest are encrypted with AES-256-GCM. The algorithm choice is deliberate. AES-256 is the symmetric primitive blessed by NIST for classified data; GCM mode provides authenticated encryption — meaning ciphertext that has been tampered with is rejected at decrypt time, not silently returned with corrupted plaintext.

The multi-key registry is what makes rotation operationally feasible.

Every ciphertext carries a Key ID (KID) header. When a finding is encrypted, the active key's KID is prepended. When the same finding is later decrypted, the KID tells the registry which key to use. Adding a new key marks it active; the previous active key becomes retired. Retired keys stay in the registry — they're still needed to decrypt findings encrypted before the rotation.

The critical operational property: rotation requires no re-encryption. A million historical findings encrypted under kek-2025-12 continue to be readable using that key after kek-2026-01 becomes the new active key. New findings get the new KID. Old findings keep their old KID. No background job has to walk the database; no downtime window has to be scheduled; no risk of partial-rotation state where some rows are readable and some are not.

HMAC-SHA-256 keyed dedup hashes are written alongside the ciphertext. The hash is computed with a tenant-scoped HMAC key — same input value always produces the same hash, but two different tenants computing the hash on the same value produce different hashes (no cross-tenant correlation). This is what lets compliance teams ask "has this card number been seen?" without ever decrypting anything. Search the hash; if it matches, you've established existence without exposure.

Key material storage: in production, key material is in Ansible Vault, distributed at deploy time, never written to logs. For self-host deployments that require HSM-backed key custody (financial-services, defense, regulated healthcare), the registry is designed to plug into HashiCorp Vault, AWS KMS, or GCP KMS — the abstraction is intentional; the keyset doesn't have to live on the gateway's filesystem.

9. Layer 8 — Audit and Compliance

Every system that handles sensitive data has to answer two questions: who did what, and can you prove nobody erased the answer? SoxAI's audit layer answers both.

audit_logs is append-only at the database level. A PostgreSQL trigger blocks DELETE and UPDATE on the table. This is not enforced by the application — it is enforced by the database engine. An application-layer bug or a compromised service account cannot remove rows. The only path to modifying audit logs would be a DROP TRIGGER followed by DELETE, which requires database-superuser privileges that the application service accounts don't have. The trigger itself is created by migration, version-controlled, and re-applied on every deploy.

Audit-before-plaintext is the invariant that closes the most common audit-system bypass pattern.

The pattern looks like this: an operator reads the data, then "forgets" to log the read. In a typical system, the audit write is a "best-effort" sidecar — if it fails, the operator still got their data. SoxAI inverts this. On every decrypt operation, the audit row is written before the plaintext returns to the caller. If the audit insert fails — for any reason: database unavailable, network blip, validation error — the entire decrypt is aborted with a 500 and no plaintext exposed. There is no path through the decrypt handler that returns the value without first creating a record of who asked for it.

What lands in audit_logs: every sensitive admin operation (decrypt requests, role changes, channel suspensions, key rotations, tenant deletes, license rotations), every authentication event (login successes, login failures, MFA challenges, account lockouts), every cross-tenant probe (even the rejected ones — they're a useful signal for anomaly detection). The retention horizon is configurable but defaults to seven years, and the storage is your responsibility in self-host deployments (the application doesn't dictate which warehouse you mirror to).

WebAuthn step-up sits on top of audit. Sensitive operations don't just write an audit row — they require a fresh WebAuthn challenge first. The audit row records that a human's hardware key produced a signed assertion within the last sixty seconds. Session theft does not buy access to sensitive operations because the session never had the hardware key.

Compliance posture as of mid-2026:

10. The 2026 Security Reality

Three pressures are reshaping how enterprises buy and deploy AI infrastructure.

Regulatory. The EU AI Act's risk-classification phase is rolling out through 2026. High-risk applications — and most production LLM deployments touching personal data, financial decisions, or critical infrastructure are classified high-risk — must document their controls. "We use an AI gateway" no longer answers the question; auditors want to see how the gateway enforces tenant isolation, how findings are encrypted, who can decrypt them, how the audit trail is made tamper-resistant. The companies that started building these answers a year ago are passing. The companies that planned to "figure it out later" are starting again from scratch.

SOC 2 Type II has crossed from nice-to-have to required in enterprise procurement above mid-market. The audit costs real money and real engineering time, but the procurement discussions don't progress without the report. State-level US privacy regulation expands the surface area: a notifiable incident in California now also implies notification obligations in Colorado, Connecticut, Texas, and (depending on the data) the EU.

Business. CISO sign-off before LLM production is now standard at companies above a few hundred employees. The CISO is not the person who wants to debate prompt-engineering technique — the CISO is the person who wants to see the architecture diagram, the threat model, the encryption posture, the audit trail. AI vendors who can't produce these artifacts get rejected at the procurement gate, not at the technical-fit conversation.

Cyber-insurance carriers have caught up. AI usage now shows up in policy questionnaires; some carriers write generative-AI exclusions; others write premium loadings that scale with how much LLM traffic the insured business handles. A documented security architecture changes the underwriting.

Technical. Prompt-injection techniques are cataloged and shared in red-team communities every month. Encoded payloads, indirect injection through retrieved content, multi-turn jailbreaks that exploit context windows — the catalog is growing, not shrinking. Model capabilities improve in parallel, which compounds the consequence: a jailbroken model in 2024 produced offensive content; a jailbroken model in 2026 can convincingly draft a contract, generate executable code, or impersonate a known person well enough to fool a phone screening.

The teams that approach AI security as a checkbox at the end of the release process discover the inadequacy the first time something goes wrong. The teams that approached it as an architecture from day one have eight layers, every layer enforced at the gateway, every layer audited end-to-end. Those teams pass procurement. Those teams pass incident review.

11. Conclusion — A Security-First Architecture

Eight layers, each enforced at the gateway, each designed to fail safely on its own:

1. Authentication — Argon2id, OIDC SSO, WebAuthn step-up, rotating refresh tokens
2. Tenant isolation — application-layer scoping with PostgreSQL Row-Level Security as backstop
3. RBAC — five roles with least-privilege defaults, no platform role sees prompt content
4. API tokens — hashed at storage, gated by IP / country / scope / rate / cap
5. Data Loss Prevention — fifteen builtin detectors, mask / block / audit, fail-closed
6. Prompt Guard — 195+ patterns, nine languages, three detection layers, fail-open
7. Encryption at rest — AES-256-GCM, multi-key rotation, HMAC dedup hashes
8. Audit — immutable, append-only at the database, audit-before-plaintext invariant

This is not eight features bolted onto an off-the-shelf reverse proxy. It is an architecture where each layer was designed against a specific failure mode and where the failure modes were studied before the layers were built. SoxAI was security-first from the first commit; we did not retrofit.

If you're evaluating AI gateway security in 2026, the question is not "do you have an AI firewall." The question is "what does your perimeter look like when one layer fails." If your vendor's answer is a single product, you have one perimeter. If their answer is eight layers, you have eight chances to stop an incident before it becomes a notification obligation.

Two paths forward from here.

SaaS is the fastest deployment — fifteen minutes from sign-up to first request, all eight layers enabled by default, no infrastructure to manage. For most companies, this is the right answer.

Self-hosted is for organizations where the data perimeter must be physical. SoxAI ships under a source-available commercial license that includes the full source for the gateway, console, and admin tools. Deploy on your own Kubernetes, your own PostgreSQL, your own Redis, your own key custody (HashiCorp Vault, AWS KMS, GCP KMS, HSM). Same engines, same DLP, same Prompt Guard, same audit invariant — running entirely inside your perimeter.

Either way, the eight layers are how SoxAI defines "most secure" — and how we expect that claim to be evaluated.

---

Next steps:

• Security features overview — visual walkthrough of the full architecture
• Defense-in-Depth deep-dive — technical anatomy of DLP and Prompt Guard
• Compliance documentation — OWASP, SOC 2, GDPR posture
• SoxAI for Enterprises — self-host, SSO, dedicated SLA, compliance checklist
• Start a free trial — 15-minute setup, $0.50 trial credit, no card required