Security

This page describes the controls that protect the AirHive warehouse management service (the “Service”) and the data your organization keeps in it. It is written for the person doing due diligence before trusting us with their operation, so it states what is in place today rather than what is planned.

• In transit. Every connection to the Service runs over TLS. Session cookies are marked secure in production, so the browser will not send them over an unencrypted connection.
• At rest. The database and file storage are encrypted with AES-256 by our infrastructure provider.

• Passwords are stored as bcrypt hashes. We never hold, log, or transmit a password in readable form, which is also why we can never tell you what yours is.
• Two-factor authentication (TOTP) is available to every user and works with any standard authenticator app. It is offered, not imposed: each user decides whether to turn it on.
• A suspended account is rejected on every request, not only at sign-in, so revoking access takes effect immediately rather than when the current session expires.

• Session cookies are httpOnly — JavaScript running in the page cannot read them, so a script injected into the browser cannot walk off with your session.
• Cross-site request forgery is blocked by a double-submit token, enforced globally rather than route by route.
• Sessions are bound to the browser that created them. If a session token appears from a different browser family, it is refused; a change of IP address is allowed but recorded. A stolen cookie is therefore not enough on its own.

Permissions are resolved by shared guards that every endpoint goes through, not by checks written case by case — the pattern that lets one forgotten line become an open door.

• Users hold roles, and roles carry read or write access per module.
• Which modules an organization has at all is set when the organization is created and can only be changed by us, not self-served.
• Administrative surfaces sit behind their own guard, separate from ordinary authentication, and sensitive operations require a re-authentication step.

Every business record carries the identifier of the organization that owns it, and the boundary is applied in the service layer that all data access passes through — one place to audit rather than one per query. Records are indexed by that identifier so the filter is enforced on every read, not applied after the fact.

The Service keeps separate audit trails for general activity, administrative actions, catalog item changes, and supplier changes. Every exchange with the AI assistant is recorded as well — see the Privacy Policy. Audit entries are written outside the transaction they describe, so the record of a failed operation survives the failure instead of being rolled back with it.

• Request rate limits apply per organization, with tighter limits on sign-in and administrative endpoints.
• Automated sign-in attempts are filtered by a bot-protection challenge.
• Uploaded files are size-capped and type-checked on the server. Client-side validation is treated as a convenience, never as a control.

Security checks run on every proposed change, before it can be merged: a scan for credentials accidentally committed, static analysis for security defects, plus build, lint, type checking and the test suite. Database migrations follow an expand-then-contract discipline — a column is never dropped in the same change that introduces its replacement — so a deployment can be reversed without losing data.

The infrastructure and third-party services that process data on our behalf are listed by name, with the data each one handles, in the sub-processor table of our Privacy Policy. We update that list whenever a provider is added or replaced.

AirHive does not currently hold a SOC 2 report or ISO 27001 certification, and we would rather say so plainly than let a security page imply otherwise. The controls above stand on their own and can be verified by exercising the Service. If your procurement process requires a formal audit, contact us and we will tell you honestly where we are.

If you believe you have found a security flaw, write to security@airhivemx.com with enough detail to reproduce it. We will acknowledge your report and keep you informed while we work on it. Please give us a reasonable window to fix the issue before disclosing it publicly. We will not pursue legal action against anyone who reports a flaw in good faith and does not access, alter, or destroy other people’s data while finding it.

We review these controls periodically and update this page when they change. The “Last updated” date above reflects the most recent revision. Questions about anything here go to security@airhivemx.com.