Security at AgenticOmni

AgenticOmni has not completed a SOC 2 examination, and we do not hold a SOC 2 report. We are not ISO 27001 certified. We are not HIPAA compliant. We do not hold a PCI DSS attestation. We do not publish an availability percentage or an uptime SLA.

We say this plainly because a security page that overstates its position is worse than one that lists its gaps. If your diligence needs any of the above, ask us where we actually are and we will give you the current answer.

AgenticOmni runs on Google Cloud. Cloud Firestore is the system of record; the API and the web application run on Cloud Run. The deployment region is us-central1, and the Cloud KMS keys that protect your credentials live in the same region. Each environment is a separate Google Cloud project with its own Firestore database, its own authentication pool and its own keys.

The credentials we hold on your behalf — OAuth access and refresh tokens for the channels and accounting systems you connect, and the webhook secrets we issue — are encrypted before they are written to the database. In production the key is a Google Cloud KMS symmetric key (agenticomni-keyring in us-central1). Where encryption is required, the writer refuses to store the secret in plaintext rather than falling back silently. The application and its API are served over HTTPS.

Every record is stored beneath the organization that owns it, and access is decided from the caller's own identity token rather than from anything the client sends:

• The caller's organization comes from a signed claim in their authentication token, and the database rules compare it to the organization on the document being read or written.
• A second claim can confine a user to specific storefronts within their organization, so a representative assigned to one store does not see another store's records.
• Only platform staff roles hold any cross-organization access, and for support or debugging rather than routine use.
• Every data query in the API is filtered by organization, so a missing or wrong identifier returns nothing rather than everything.
• Order creation is not possible from a browser. The order wizard posts to the API, which creates orders with the Admin SDK, so idempotency, order numbering and inventory allocation cannot be bypassed from a client.
• A signed-in user can update only orders belonging to their own organization and storefront, and the two order lifecycle fields — status and intake_status — are refused to clients entirely. Deleting an order is limited to organization administrators.
• Reads of the most sensitive collections — audit logs, invoices and integration configuration — are restricted further, to the roles that need them.

Access is role-based. Platform roles are platform admin, platform support and platform developer. Organization roles are brand admin, brand manager, brand rep, warehouse staff and viewer, with a separate customerrole for the customer portal that reaches only the customer's own records.

Time-based one-time-password multi-factor authentication, with single-use backup codes, is implemented for accounts that enable it.

The operations API writes an audit entry for the actions it performs — a dead-letter retry or resolution, and a change to alert routing. An entry records the actor, the organization, the resource and the action that was taken, plus the context the calling operation supplies, such as the task type or the resolution note. An entry does not store a field-level before and after value, so the audit trail answers “who did what, and when” rather than providing a full change history of every field. Order lifecycle transitions carry their own event trail instead: the order service writes an event document on each state change, stamped with the actor and the time. Audit entries are readable by organization administrators and platform staff — not by every member of the organization — and are surfaced in the product on each approval record.

Work that fails against an external system is placed on a dead-letter queue with a pending, retrying then resolved lifecycle, so a failure is retried and then held for inspection rather than lost. Each failure is classified by severity and vendor and routed to email and Slack; the default route sends every high-severity failure to the platform owner. Operators can review and replay the queue in the admin console.

Application errors are reported to our error tracker with request bodies and personal data stripped before they leave the process.

Automated backups are not enabled yet, and point-in-time recovery is off. Until that changes, recovery from a data-destroying fault is bounded by the database's short version-retention window rather than by a backup you can restore to a chosen point. We would rather you learn that here than from your own diligence.

Closing that gap is a prerequisite for taking live traffic, and this page will state the schedule and the retention window once they are running.

Google Cloud hosts the application, the database, the key management and the file storage. Firebase provides authentication. Cloudflare fronts the development hostnames. Resend delivers transactional email, Slack receives operational alerts, and our error tracker receives stripped crash reports.

The commerce and accounting systems you connect — Shopify, Walmart, WooCommerce, Xero — are reached only with credentials you authorize, and only for the operations you enabled. We do not sell or share your data with anyone else.

Email us at the address below with Security reportin the subject line. Please do not test against production data or against another organization's tenant, and give us a chance to fix the issue before disclosing it. We do not run a paid bounty programme.