Security

This page describes the security controls that are implemented in the Operator Base platform today. Everything here is a control that is running in production, not a roadmap item. Where a control has a known limit, we state the limit rather than round it up.

It pairs with our Sub-processor list and our Data Processing Addendum, which references this page as the description of our technical and organizational measures.

1. Tenant isolation

Every customer account is a separate tenant, and tenant separation is enforced in the database rather than only in application code.

• Row level security on customer tables. Tenant-scoped tables have PostgreSQL row level security enabled, with policies that compare each row's tenant against the tenant bound to the current database session. Most of those tables additionally have row level security forced, which extends the policies to the table owner as well, and we are completing that coverage on the remainder. Forcing changes nothing for the role our services actually run as, because that role does not own the tables and is already subject to every policy.
• A database role that cannot bypass those policies. Tenant-scoped work runs as a dedicated PostgreSQL role created without login rights and without the ability to bypass row level security. A connection has to explicitly assume that role, either for the life of the connection or for the life of a single transaction, depending on the service.
• Policies fail closed. If the tenant is not bound on a connection, the policies evaluate to no access rather than to all access. A missing tenant binding returns nothing; it does not return everything.
• Defense in depth in queries. Sensitive administrative queries also carry an explicit tenant predicate alongside the row identifier, so a misconfigured connection is caught by the query as well as by the policy.

2. Encryption

• In transit.All traffic to the platform and all outbound calls to third-party providers use TLS. Database connections from our services verify the database provider's certificate authority, which is distributed with each service image. A build-time check in our deployment pipeline blocks any change that disables database certificate verification without a recorded justification.
• At rest. Stored data and files are encrypted at rest by our database and storage provider as part of their platform.
• Credentials you store with us get a second layer. The API keys and OAuth tokens you connect for third-party integrations are encrypted by the application before they reach the database, using AES-256-GCM with a 256-bit key held outside the database. That covers connected model provider keys, CRM and channel credentials, custom tool secrets, and integration server secrets. A database copy on its own does not yield those credentials.
• Platform API keys are stored as hashes. API keys you create for our public API are shown once at creation and stored only as a SHA-256 digest, alongside a last-four display hint. We cannot recover the original key, and neither can anyone with database access.

3. Logging, error reporting, and PII redaction

Redaction runs on every one of our six production services. It is applied to structured application logs and again to error events before they are sent to our error monitoring provider.

What it removes: email addresses and phone numbers, matched by pattern, at any depth inside a structured log payload. It also caps oversized strings and deeply nested objects rather than letting them through unchecked.

What it does not remove, stated plainly: the redaction is pattern based. It does not detect names, postal addresses, or free text. Third-party error responses routinely echo contact fields as free text, and those are not caught. The accurate claim is that no complete email address or phone number reaches our logs from a redacted path. It is not that no personal data is ever logged. We would rather publish the real ceiling than a comfortable one.

4. Audit trail

Administrative actions write to an audit log that is append-only at the database level. The audit table grants the application role permission to insert rows and to read its own tenant's rows, and grants no permission to update or delete them. This is enforced by the database's own policy set, not by application convention, so application code cannot quietly rewrite history even if it tried.

There is one deliberate exception, added for privacy rather than against it: a single narrowly scoped database routine can strip a contact name from audit metadata as part of an erasure request. It removes only that one field, never a row, re-derives the tenant from the session and refuses to run on a mismatch.

5. Data residency

• The AI agent platform's application services and primary database both run in the United States, in the AWS us-east-1 region.
• The operator app's backend, which also holds the sign-in accounts used across the Service, runs in a separate database project in the United States, in the us-west-2 region.
• We have not configured a European or other non-US region for any part of the Service. Processing occurs in the United States.
• Delivery is not storage. Our hosting and content delivery providers serve static files and run edge code from the network location nearest the requesting device, which can be outside the United States. The systems that store data stay in the regions above.

Processing locations for each third-party provider are listed on the Sub-processor page.

6. Access controls and secrets

• Role-based permissions. Operator accounts within a tenant hold granular permissions, and sensitive operations check a specific permission rather than a general admin flag.
• No secrets in source control. Every credential is injected into a service at start-up from a managed secret store. Keys and connection strings are read from the environment only, and a secret scanning check runs before code is committed.
• Rate limiting and abuse controls. Public entry points such as the chat widget, hosted forms, the voice orb, the public API, and authentication endpoints carry per-IP, per-session, and per-tenant rate limits. On our public API key path, failed key lookups are held in a cache separate from successful ones, so a key-guessing attack cannot evict legitimate entries from the lookup cache.
• Isolated execution for custom tools. Customer-authored tool code runs inside a separate V8 isolate that shares no heap with the host and exposes no host objects to the script, under a memory cap and an execution timeout, with a bounded number of concurrent sandboxes.

7. Monitoring and alerting

Infrastructure alarms cover queue depth, service health, error rates, and custom tool execution. Alarms route through a notification topic to an alerting channel monitored by our engineering team. Deployment failures publish to the same channel. Application errors are captured by our error monitoring provider, with per-event rate limiting so a single failing component cannot drown out a rarer signal.

8. Optional content safety screening

Agents can be configured to screen inbound and outbound messages through a content safety classifier. The screening is off unless you enable it on a specific agent. When the classifier is unavailable the pipeline continues rather than blocking your agent, which is a deliberate availability choice you should know about when you rely on it.

9. Your data: export and data subject requests

• Full account export is available to you today.A tenant administrator can request an export of the account's data from the dashboard. The archive is assembled into a private storage bucket and delivered through a short-lived signed link. Exports expire and are re-downloadable until they do.
• Single data subject exports are produced by our team. To answer an individual access or portability request under Articles 15 and 20 of the GDPR, email support@operatorbase.app and we will produce an export covering only that data subject. There is no self-service control for this yet. The full account export above is available to you immediately and contains that data subject alongside the rest.
• Erasure of a single contact is available to you today. Since August 19, 2026, a tenant administrator holding the contact deletion permission can erase an individual contact from the AI agent platform dashboard. The control shows a preview of the records the erasure will affect before anything is destroyed, then schedules it with a cancellation window, seven days by default, during which the request can still be withdrawn because nothing has been destroyed yet. You can set that window to zero where a request needs to be honored immediately. Send an erasure request to support@operatorbase.app instead if you would rather our team ran it.
• What erasure does not reach.It pseudonymizes the contact record rather than removing every row. It does not reach copies held in third-party systems you have connected, such as your CRM or your telephony provider, and those have to be erased in those systems too. It is keyed to the contact record, so a voice call record that is no longer linked to a contact is not matched and not erased. And our append-only audit trail keeps entries for six years: erasure strips the contact's name from the entries keyed to that contact, but entries keyed to something else, such as a conversation, can still carry it. If you are asked whether every trace of a name is gone, the accurate answer today is that it is not. Section 9 of the Data Processing Addendum states these limits in the contract.

Article 28 obligations, including how we assist you with data subject requests, are set out in our Data Processing Addendum.

10. What we do not claim

Security pages are easy to inflate, so here is the other side of the ledger. As of the date at the top of this page, Operator Base does not hold and does not claim:

• SOC 2 Type I or Type II attestation, ISO 27001 certification, or any other third-party compliance audit or certification.
• HIPAA compliance or a Business Associate Agreement. Do not put protected health information into the Service.
• PCI DSS certification. Card payments are handled by Stripe and card numbers never reach our systems.
• An independent penetration test or a bug bounty program.
• Multi-factor authentication, single sign-on, or SAML for operator accounts.
• Automated dependency vulnerability scanning or static security analysis in our build pipeline.
• A published uptime commitment or service level agreement outside of an individually negotiated enterprise agreement.

If any of these is a requirement for your organization, tell us before you buy rather than after. We would rather lose a deal on an honest answer than win one on a claim we cannot support.

11. Reporting a vulnerability

If you believe you have found a security vulnerability in Operator Base, email support@operatorbase.app with the subject line "Security" and enough detail to reproduce the issue. Please do not test against other customers' data or run automated scans against production. We will acknowledge your report and keep you updated while we investigate. We do not currently operate a paid bounty program.

12. Contact

For security questionnaires, vendor reviews, or questions about anything on this page:

DIGITAL WARRIORS LLC
180 NE 29th St, Apt 330
Miami, FL 33137
support@operatorbase.app