Security posture

Adding the Gateway in front of your warehouse changes how fast queries return — not who can see what, what gets logged, or where credentials live. This page is the precise version of that claim.

Credentials pass through

When a BI tool connects to your gateway address with warehouse credentials, the Gateway forwards those credentials to your warehouse. It doesn't store them, log them, or inspect them. Airbrx never sees usable credentials at rest.

• The Gateway opens a session with your warehouse using the credentials the caller provided. The warehouse — not Airbrx — validates them.
• Validation results are cached briefly in memory so the Gateway doesn't re-auth on every query. Credentials themselves are not part of that cache.
• The same applies to OAuth tokens and key-pair authentication. Whatever your warehouse accepts, the Gateway forwards.

Sessions opened against your warehouse appear in your warehouse's session list and audit logs exactly as they would if Airbrx weren't there.

Row-Level Security and column masking

The cached result for a query is whatever the warehouse returned when the warehouse first executed it. That means RLS and masking are still doing the work — they ran on the warehouse, on the warehouse-executed query, with the warehouse-side identity of the user who triggered the cache fill.

For per-user policies to keep working when caching is on, cache rules need to be keyed per user. That's a one-line setting on a cache rule — see the rules concept page for the conceptual model and Ship your first cache rule for a worked example. If you forget, the rules analyzer in the App flags it as a warning before traffic flows through.

Audit trails stay intact

Two audit trails exist side by side, and both are first-class:

• Your warehouse's native audit log. Every query the Gateway forwards to the warehouse appears here, attributed to the user whose credentials were forwarded. Nothing about that changes.
• The Airbrx traffic log. Every query the Gateway sees — cached or forwarded — is recorded by Airbrx. Cached responses don't appear in the warehouse audit log because no warehouse execution happened, but they do appear in Airbrx's log, with the same user attribution. The analytics API exposes these records.

Together, those two logs let you reconstruct exactly what every user asked for and whether the answer came from cache or the warehouse.

Tenant isolation

Each tenant in Airbrx has its own gateway address, its own configuration, its own cache namespace, and its own slice of the analytics record. Cached results from one tenant are never visible to another, even within the same account. The Gateway derives its rule set from the tenant on the incoming request; the API enforces tenant boundaries on every read and write.

Tokens and scopes

Two kinds of token authorize calls into the API: user JWTs (for browser sessions) and Personal Access Tokens (for service flows). Both carry a four-axis scope:

• Method — which HTTP verbs the token can use.
• Path — which API endpoints it can call.
• Tenant — which tenants it can act on.
• Account — which accounts it has any visibility into.

The four axes compose. A token can be scoped to "GET on /config/tenants/{id}/rules for tenant X, in account A" and nothing else. Service integrations get the minimum they need; a leaked token is bounded to its scope, not the full API surface.

Plan-level restrictions sit on top of the four axes — features that require an Enterprise plan are enforced at the API handler regardless of token scope. Both sets of restrictions return 403 with a structured reason; the App renders that into an "upgrade to unlock" prompt or a "this token doesn't include that operation" message.

PATs are created and revoked from your user settings in the App. The underlying endpoints (/oauth/pats, /oauth/introspect) are documented in the API reference.

What runs where

Each resource in Airbrx enforces a different slice of the security story:

• The App never holds credentials. It carries your JWT in a cookie, refreshes it against the API, and renders affordances based on what your token can do.
• The API is authoritative for every authorization decision. The App reads claims for sensible defaults; the API gets the final word on every read and write.
• The Gateway is stateless with respect to user identity — it forwards credentials to the warehouse and uses the rule set it pulls from the API. Cached results are scoped per the rule that produced them, including any per-user keying.

What we are and aren't claiming

Airbrx adds a caching layer in front of your warehouse. It does not replace your warehouse's access controls, your identity provider, or the data classification decisions you've already made. The Gateway honors what your warehouse enforces; it doesn't impose anything new on top.

For the certifications and contractual posture that go with formal security review, contact us through the About page — we can share the current state of compliance work and route the conversation to the right person.

Where to go next

• The Gateway, App, and API — which resource enforces what.
• How the Gateway works — the request lifecycle, including credential forwarding.
• The Four Pillars — how Secure & Compliant fits with the other product goals.