Trust & security

Security & data handling

Airbrx sits in the path of the warehouse connections you choose to route through it. It processes queries, applies configured rules, and can store results so later requests can be answered from the cache. This page explains where that data goes, how credentials are used, and which protections depend on your deployment.

What happens to a query?

Your client sends a request to the Airbrx gateway. The gateway evaluates it using the tenant’s configuration and rules. Depending on those rules and the state of the cache, it may forward the request to the warehouse, answer from a cached response, or apply configured invalidation rules.

Caching requires handling and retaining response data. Cached responses and associated files can contain actual result values. Query activity records are a separate dataset and can contain SQL, parameters, usernames, request identifiers, timing, errors, and cache decisions.

Treat both the cache and query logs as potentially sensitive. A log that contains no result rows can still contain personal information in SQL literals, parameters, or user identifiers.

Where is it stored?

Storage arrangement	What it means
Airbrx-hosted storage	Airbrx operates storage for the cache, logs, and related service records on your behalf. Hosted Starter deployments use this arrangement.
Customer-controlled storage	Configured caches, logs, and related records are written to your cloud storage account. Airbrx components read or write those objects using the permissions granted for the service.

Account, authentication, configuration, support, billing, and operational records are also needed to run Airbrx. Choosing customer-controlled cache storage does not move every Airbrx record into your account, prevent gateway processing, or automatically restrict all processing to your storage region.

We can review the actual storage destinations, access roles, and processing locations for your deployment. Confirm those settings directly rather than relying on a plan name as a complete description of data residency.

How are warehouse credentials handled?

The caller supplies the warehouse credential for its request. Airbrx maintains that credential through the active request cycle so the operation can complete, including asynchronous execution and result collection where needed. The executor works with this caller-supplied credential; it does not require a separate, standing credential for future warehouse queries.

When an executor saves credential-bearing state during that cycle, it encrypts the credential using AES-256-GCM. That request state is distinct from the cached query result and from the token hash that may appear in activity records.

Optional warehouse monitoring. A configurable option can store a credential to check which warehouses are running. The credential is stored encrypted using a configurable encryption key and is used while it remains valid. This monitoring is separate from completion of an individual query. Review the setting, credential scope, lifetime, encryption-key configuration, and removal process when enabling it.

Warehouse request credentials, optional monitoring credentials, Airbrx application sessions, cloud-storage permissions, and browser-saved scan credentials serve different purposes. Review their access and retention separately when configuring a deployment.

Use appropriately scoped credentials and revoke them at the issuing system when access should end. Deleting a saved browser connection removes that browser’s copy; it does not revoke the original credential or establish that every server-side record has been deleted.

How does caching interact with permissions?

Queries executed by the warehouse use the supplied identity and its warehouse permissions. A cache hit returns a previously stored result and does not necessarily run the query at the warehouse again.

Cache rules determine which request attributes distinguish one result from another. Configure them to preserve the access boundaries your workload requires, including differences between users, roles, warehouses, and session context. Shared caching should be used only when the relevant users are entitled to the same result.

Changes to permissions, row-level policies, masking, or data can require invalidation or a different caching rule. Workloads that cannot safely reuse a result should bypass caching. These dependencies matter when evaluating whether a particular workload is appropriate for Airbrx.

What appears in logs and reports?

Query records can include the statement and its parameters, who ran it, the relevant tenant and warehouse, the rule applied, whether the response came from cache, response size, timing, and errors. Reports aggregate that activity to help customers understand service behavior and cost.

Separate application and infrastructure logs support authentication, troubleshooting, security, and administration. Depending on configuration, account events or operational alerts may also be sent to communication services such as Slack.

Access to query logs and reports should follow your organization’s data-access rules. SQL normalization and identifier hashing do not by themselves make those records anonymous.

What happens when I scan a warehouse?

You can connect the scan tool to a warehouse or run the supplied query yourself and paste or import its results.

Connected scan. Your browser sends the connection details and credential to a relay that communicates with your warehouse. It may discover available warehouses, execute the scan, poll for completion, and return query-history results. The returned data is then analyzed in your browser. This is more than a single network request, and the relay handles the data in transit.

Paste or import. The scan analysis runs in your browser. Applying generated rules or invoking a connected service is a separate action that can send the information needed for that action.

Saved information. The tools can save credentials, connection details, preferences, and scan results in browser storage so you can return later. Scan results can contain SQL and usernames, and saved data can survive a browser restart. Use Disconnect everything within the tool, or clear its site data, when you want to remove it. On a shared device, another person with access to the browser profile may also have access to that saved information.

Browser removal controls do not revoke warehouse credentials, clear other origins automatically, or erase service records already created elsewhere.

Does Airbrx send data to an AI provider?

The AI rule-recommendation endpoint uses Anthropic. Invoking it sends the selected SQL statements and associated query metrics and identifiers to generate recommendations. The input is validated and normalized, but these steps do not guarantee removal of personal information or confidential content.

That endpoint is separate from ordinary gateway caching and the browser-based scan calculations. Before using AI assistance with customer data, confirm that your organization permits the disclosure and review the applicable provider and processing terms. This page does not make a zero-retention or provider-training guarantee.

When is data deleted?

Cache freshness and data deletion are separate controls. A result can expire or be invalidated for serving while its stored object, historical version, or backup remains.

For customer-controlled storage, review your bucket lifecycle, object versions, backups, execution records, and logs. For Airbrx-hosted storage, contact us for the applicable retention and deletion arrangements. Credential expiry and revocation also differ from deletion of the stored credential record.

Closing an account or disabling a tenant is not a promise of immediate erasure of every associated record. Deletion must account for the storage systems involved, customer instructions, and legitimate legal or security retention requirements. Our Privacy Policy explains how to submit a request.

What security controls are relevant?

The service includes authenticated APIs, account- and tenant-scoped authorization, configurable cache boundaries, encrypted public-service connections, and credential encryption for asynchronous cache execution and optional warehouse monitoring. Storage permissions, encryption settings, logging configuration, and data lifecycle controls also depend on the deployed environment.

Review the controls that apply to your actual deployment and workload. This page does not claim that every configuration has identical protections or that the service has no security risk.

For a security review, contact us to discuss data flows, provider involvement, access controls, credential handling, and contractual requirements. Where Airbrx processes personal information on your behalf, processor obligations can apply even when storage remains in your account. This page is not a substitute for the data processing terms required for that relationship.

What if I stop using Airbrx?

You can route affected clients directly to the warehouse by changing their connection configuration. Plan that change for your clients, certificates, authentication, and network setup. Removing Airbrx from the query path is separate from revoking its access, exporting records, and deleting stored data.

Website storage and privacy

The website uses browser storage for display preferences. Authentication, scan tools, contact forms, and partner referrals add the storage needed for those features. Referral attribution cookies require your agreement; a separate cookie remembers acceptance or refusal. External asset providers and the contact-form provider receive ordinary request information when their resources load.

See the Privacy Policy for the cookie details, provider disclosures, and your choices.