Trust & security
Start with one workload. Expand with evidence.
Airbrx helps you reuse eligible query results and understand the warehouse traffic you route through it. Choose your first connection, review how its data is handled, and measure performance before extending the rollout.
Prefer to start without connecting a warehouse? Run the scan query yourself and paste the results for analysis in your browser.
You choose the scope
Three decisions, all yours.
Start with selected connections
Route a supported tool or team through Airbrx. Other connections can continue directly to the warehouse.
Set the caching rules
Choose which queries are eligible for reuse and the access boundaries those results must preserve.
Measure the outcome
Review cache hits, query timing, and bytes served on the traffic you route.
Follow the data
From request to result.
Your selected client sends a request to the gateway. Airbrx processes the request and applies your configured rules. It can forward the request to your warehouse or return an eligible cached response.
Caching stores result data. Query logs are separate and can contain SQL, parameters, usernames, timing, and cache decisions. Both deserve the same care you give other sensitive warehouse records.
Cache and log storage can be Airbrx-hosted or customer-controlled, depending on your deployment. Airbrx also maintains account, authentication, configuration, and operational records needed to run the service. We can map these flows with your team before a rollout.
Before a rollout
Five questions to settle.
Where will our data be stored?
The deployment determines where caches, query logs, and service records are stored. With customer-controlled storage, Airbrx accesses the configured objects using the permissions you grant. With hosted storage, Airbrx operates those stores for your service.
Our current AWS regions are Northern Virginia (us-east-1) and Oregon (us-west-2). Your deployment review identifies the applicable locations, access, and any recovery copies. Customer-controlled cache storage does not move every service record into your account.
How does caching work with our permissions?
Warehouse requests use the caller’s supplied credential and its warehouse permissions. A cache hit serves a previously stored result, so the cache rules must preserve the user, role, and session boundaries your workload needs.
Share a cached result only among users entitled to the same answer. When permissions, masking, row-level policies, or data change, review invalidation and cache rules. Queries that need a fresh warehouse authorization check can bypass caching.
Do you keep warehouse credentials?
The executor uses the credential supplied by the caller throughout the active request cycle, including asynchronous completion and result collection. It does not require a separate standing credential for future queries. Credentials saved in execution state are encrypted using AES-256-GCM.
Warehouse monitoring is a separate option. If enabled, it can store a credential encrypted with a configurable key and use it while valid to check running warehouses. Review the credential’s scope, key configuration, and removal arrangements when enabling it. Expiry or revocation stops authorization; deletion of a saved record is a separate lifecycle step.
What if the gateway is unavailable — or we want to leave?
Airbrx is in the path of the connections you route through it. Gateway availability and network conditions can affect those connections. Include performance, failure handling, and recovery requirements in your evaluation.
You can reconfigure affected clients to connect directly to the warehouse. Plan the change around your clients, authentication, certificates, and network setup. Any required availability or recovery commitments belong in your service agreement. Exporting records, revoking access, and deleting stored data are separate exit steps.
What can we review before moving ahead?
Bring your architecture and security requirements. We can walk through data flows, storage ownership, credential handling, tenant and cache boundaries, encryption, providers, and retention responsibilities for your proposed deployment.
The service uses authenticated APIs, tenant-scoped authorization, encrypted public connections, and encryption for saved execution credentials. Storage permissions, cache boundaries, key configuration, and retention settings are part of the deployment review.
Where Airbrx processes personal data on your behalf, the applicable DPA and processing schedules need to be in place. Security & data handling is the detailed companion to this page; the Privacy Policy explains our data handling, and your agreed service and processing terms set the contractual commitments.
Measure it
Make the next decision from your own traffic.
A history scan helps identify repeated queries worth evaluating. A pilot then shows how your chosen rules perform on routed traffic.
Review cache hits and misses, response timing, matched rules, and bytes served. Compare representative traffic with your warehouse baseline, including cache misses, result freshness, and access behavior. Use those findings to decide where to expand.
Scan estimates depend on the history and assumptions used. Actual performance and savings depend on workload, cache eligibility, configuration, and service and infrastructure costs. Reports cover the traffic you route through Airbrx.
Start with a scan that fits your review
Two ways in.
Connect a warehouse
Use appropriately scoped, read-only access. The browser sends connection details and a credential to a relay, which may discover warehouses, execute the scan, poll for completion, and return query-history data for browser analysis.
Run the query yourself
Use the supplied query and paste or import the results for analysis in your browser. This path does not require you to provide a warehouse credential to Airbrx. Applying rules or invoking a connected service is a separate action.
Scan tools can save connections, credentials, and results in browser storage, which may survive a restart. Use the tool’s Disconnect everything control or clear its site data to remove saved browser data. Revoke a credential at its issuer when access should end; clearing a browser does not revoke it or delete records held elsewhere.
Know which services are involved
Who touches what.
AWS supports the warehouse service. It provides infrastructure and storage in the US regions above. Descope handles login, including identity and authentication information. Its sign-in role does not require warehouse SQL, query results, or warehouse credentials. Applicable hosting, support access, and subprocessor arrangements are addressed in the processing review.
You choose any AI. Airbrx supplies an MCP integration for compatible clients. You decide whether to connect an AI provider and what tools and data it can access. Requests and responses may contain customer data, which your selected client or provider handles under your arrangements with it. Gateway caching and browser scan calculations do not require an AI connection.
Agree the data lifecycle before the rollout
Freshness and deletion are different controls.
Cache freshness and physical deletion are separate controls. An expired result may remain in stored objects, versions, logs, or recovery copies.
Your processing schedule should identify retention, return and deletion periods, storage responsibilities, and treatment of residual copies. Customer-controlled storage also needs its own lifecycle settings. Discuss these requirements during the deployment review so the agreed terms match the systems in use.
The website and applications also use browser storage for features such as display preferences, sign-in, scans, and referral choices. External assets and contact forms involve their providers. See the Privacy Policy for details and choices.
Find the opportunity. Choose the next step.
Start with your query history, or bring us the requirements for a focused pilot. Choose the workload, agree its data handling, and measure the result.