Security at MeerStack
MeerStack watches and protects our customers’ production systems, so we hold ourselves to the standard we help them meet. This page lists only controls that exist in the product today.
Compliance status
We are building toward SOC 2 Type I, and later Type II. We do not hold a SOC 2 report or any other certification today, and we will say so plainly until an independent auditor has issued a report.
While we work toward that, we can share our security documentation and answer security questionnaires under NDA.
Ask at security@meerstack.com.
Tenant isolation
Every customer organization’s data is separated in the database, not only in application code.
- Postgres
- Row-level security is enabled and forced on every table that holds organization data. The application connects with a least-privilege role that sees only the current organization’s rows. The server refuses to start if its role could bypass row-level security or if any tenant table is unprotected.
- Metrics, logs and events
- Every API read goes through a read-only account with a per-organization row policy. A query without an organization fails instead of returning another tenant’s data, and a test makes sure every new table gets the policy.
- Message queue
- Each component uses its own credentials with only the topic permissions it needs.
Encryption
- In transit
- The console and API use HTTPS with HSTS. Connections from the Service to its databases and message queue use TLS with server certificate verification.
- Secrets at rest
- Stored credentials such as single sign-on client secrets, integration tokens and MFA secrets are sealed with AES-256-GCM and bound to their owner, so a sealed value cannot be moved to another record.
Identity and access
- Single sign-on
- OpenID Connect (for example Okta, Microsoft Entra ID, Google Workspace) with the authorization-code flow and PKCE, strict token validation and per-organization allowed email domains. Organizations can turn off password sign-in once SSO is set up.
- Multi-factor authentication
- Authenticator apps (TOTP) and one-time recovery codes. Organizations can require MFA for every member.
- Passwords
- Hashed with argon2id. Accounts lock for 15 minutes after 5 failed attempts, and sign-in is rate-limited per client address.
- Sessions
- Secure, HttpOnly cookies with CSRF protection, idle and absolute timeouts, and immediate revocation on sign-out, password reset, MFA reset or removal.
- Roles and scopes
- Built-in and custom roles with least-privilege scopes. Nobody can grant permissions they do not hold, and administrators cannot lock themselves out.
- Mobile apps
- Short-lived access tokens (15 minutes) and rotating refresh tokens stored only as hashes. Reuse of an old refresh token is treated as theft and signs that device out. Administrators can sign out any phone remotely.
Audit trail
Changes to users, roles, sign-in policy, SSO, monitors, AI settings and other configuration are recorded with the person or key that made them. The audit table is append-only: the application’s database role can add records but cannot change or delete them, and database triggers enforce the same rule.
MeerAI safety controls
- One gateway
- All AI calls go through one gateway that enforces per-organization budgets and records every call: model, purpose, tokens and cost.
- Least data
- The assistant reads only data the signed-in person may see, from the sources an administrator allows. Fields marked as personal data are filtered out before anything is sent to the model.
- People approve
- By default every action the AI proposes needs a person to approve it. Changes to users, roles and sign-in settings can never be made by the AI on its own.
- Model hosting
- Production uses DeepSeek open-weight models through OpenRouter, routed only to inference providers in the United States that do not store or train on your content. Your content is not sent to DeepSeek’s own service.
- Keys and training
- Provider API keys are never logged or returned in responses. We do not use customer data to train models.
Mobile notifications
Push tokens are stored but never returned in full. By default, a notification on a locked screen shows only the severity and the affected service. Every device registration, change and test is recorded in the organization’s audit trail.
Reliability
Production will run on Amazon Web Services in a US region. The design runs in one region across three availability zones, with every layer redundant so that losing a zone does not stop data intake or alerting. Postgres uses synchronous replication, and the message queue keeps three replicas of acknowledged data. Daily backups are taken, and backup and restore are tested with a scripted drill.
Secure development
- Tests
- Every code change runs automated tests, including tenant-isolation and authentication tests.
- Signed builds
- Container images are built in CI with software bills of materials (SBOMs) and signed with Sigstore cosign. Production deploys require manual approval.
- Reviews
- We completed an internal security review of the whole platform in 2026 and fixed all critical and high findings. We plan an independent third-party penetration test.
Incident response
We investigate security events promptly and notify affected customers without undue delay, as described in our DPA and as the law requires.
Report a vulnerability
Found a security issue in MeerStack? Email us first, with enough detail to reproduce it, and give us a chance to fix it before you share it. We reply to every report.