Trust Center

Our security posture, stated plainly

We sell security software, so you should hold us to the standard we ask you to meet. This page documents how Strivio is built, where your data lives, what leaves our infrastructure, and what we have not done yet.

We would rather you learn these things here than discover them during procurement.

Last updated: 18 August 2026 · Reviewed quarterly

Where we stand today

SOC 2 Type II
Not started.
We hold no certifications and will not imply otherwise.
ISO/IEC 27001
Not pursued at this time.
ISO/IEC 42001
Not certified.
Our platform is designed to help you produce 42001 evidence, not to certify us.
Third-party penetration test
Not performed.
Planned. We will publish the date and summary when complete.
Dependency vulnerabilities
Zero known advisories.
npm audit against production dependencies, verified 18 August 2026.
Automated testing
206 tests across 13 suites covering firewall, governance, and enforcement logic.
Customer data in production
None.
Strivio is pre-revenue on the platform. Production currently holds only our own test data.

What this means for you. If your process requires a completed SOC 2 report, we cannot meet that today. If it allows compensating evidence — architecture review, questionnaire responses, contractual commitments — we can support that thoroughly.

Architecture and hosting

Application frontend
Vercel — US East
Application backend
Railway — US East (Virginia)
Primary database
MongoDB Atlas — US East (Virginia), shared cluster tier
Cache and session state
Redis on Railway — US East
Customer-selectable regions
Not available.
All processing and storage occurs in the United States.

No customer data is processed or stored outside the United States, with the exception of the third-party AI provider calls documented below.

Encryption and credentials

Transport
TLS 1.3 and TLS 1.2 with forward secrecy.
Verified ciphers: TLS_AES_128_GCM_SHA256 (1.3), ECDHE-RSA-AES128-GCM-SHA256 (1.2). Certificates managed by our hosting providers.
At rest
Provider-managed encryption on MongoDB Atlas.
Customer-managed encryption keys are not available on our current cluster tier.
Passwords
bcrypt. Plaintext passwords are never stored.
API keys
bcrypt with a cost factor of 12, matched by prefix lookup.
Raw keys are shown once at creation and never stored.
Session tokens
JWT signed with HS256, algorithm explicitly pinned at verification.
Pinning prevents algorithm-confusion and alg:none attacks. Default expiry 8 hours.
Multi-factor authentication
TOTP, generated and verified locally.
No third party is involved in MFA.
Secrets
Held in platform environment configuration and redacted from application logs.

What Strivio stores

When your agents send events to Strivio, we store the prompt or tool-call content in an audit record. This is deliberate: a decision log that does not contain what was evaluated cannot explain why a decision was made.

Prompt and tool-call content
Stored, up to 4,000 characters, then truncated with a marker.
Redaction before storage
None.
Content is stored as submitted: the audit record retains the original. Separately, the firewall supports redaction as a policy outcome — detected PII can be removed from the text before it continues through the pipeline. That is enforcement, not storage redaction: the audit record still holds the original.
Request metadata
IP address, user agent, SDK version, environment, and model identifiers.
Decision records
The evaluation, the policy applied, the outcome, and the reasoning.
Training use
Customer content is never used to train or fine-tune any model.

If storing raw content is not acceptable for your data, tell us during evaluation. We would rather scope a deployment that meets your requirements than have you discover a mismatch after signing.

Retention and deletion

Strivio retains customer records according to the retention period configured for the organization. Plan tiers set a default of 90 days, 365 days, or unlimited, and a negotiated contractual period overrides that default.

When records pass their retention period, Strivio removes the customer content they contain. That means prompt text, tool arguments, detected sensitive values, IP addresses, and free-text notes. The record of what happened survives: which agent acted, when, what was decided, and under which policy. The record survives. Its content does not.

This is deliberate. Deleting audit records outright would break the cryptographic chain that makes the remaining history verifiable. Redacting content leaves that chain intact, so integrity can still be proven for every record we retain.

What is not yet automated. Records themselves are never deleted by this mechanism, only their content. There is no self-service organization deletion, and deletion requests are handled manually. Legal holds are enforced by the system but are imposed and released manually rather than through an interface.

Legal holds override automated retention. An active hold blocks removal for an organization, or for named collections within it, until the hold is released. A hold in an inconsistent state blocks retention rather than permitting it.

CURRENT STATUS

The retention mechanism is implemented and tested but is not yet enabled in production. It runs in preview mode first, producing a report of what would be removed, which we review before enabling removal.

Last reviewed 18 August 2026. Next review 31 October 2026. If this notice is still here after that date, ask us why.

Audit record integrity

Audit records are append-only. Update operations are blocked at the data model layer, not merely by convention.

Each record carries a SHA-256 hash computed over its immutable fields plus the hash of the preceding record for that tenant, forming a per-tenant hash chain. Modifying or removing a record breaks the chain and is detectable on verification.

Where a hash cannot be computed at write time, the record is marked with a sentinel value rather than written silently unhashed, so gaps remain visible during verification.

Third-party AI providers

Strivio's detection engine is pattern and heuristic based. It does not send customer data to any external model. Two features do involve third-party AI providers, and both are described here.

Website chatbot

Conversations with the assistant on this website are sent to Anthropic's API to generate responses. Conversation content, the page visited, IP address, and user agent are stored in our database. These records are currently retained indefinitely and are visible to platform administrators. This is a marketing feature and is unrelated to the security platform.

Model proxy (optional)

If you route agent traffic through Strivio's proxy endpoints, requests are inspected and then forwarded to OpenAI or Anthropic. Prompt content is scanned in memory and is not persisted by the proxy; only metadata is recorded.

You supply your own provider API key with each request. If no key is supplied, the request is forwarded using Strivio's provider credentials. We recommend always supplying your own key so your traffic is governed by your own provider agreement.

If the firewall scan fails for any reason, the request is blocked rather than forwarded. The proxy fails closed.

Neither provider is used to train models on your data under their standard business terms. Review their published terms for the account under which requests are made.

Subprocessors

Vercel
Frontend hosting
Request metadata
Railway
Application hosting and Redis
All processed data in transit; session and projection state
MongoDB Atlas
Primary database
All stored customer data
Anthropic
Website chatbot responses
Visitor conversation content
OpenAI / Anthropic
Model proxy forwarding, if you use it
Prompt content you route through the proxy
Stripe
Payment processing
Billing data only. We do not store card details.
Sentry
Error monitoring
Diagnostic metadata and stack traces
Resend
Transactional email
Recipient address and message content

We will notify customers before adding a subprocessor that processes customer content.

Who can access customer data

Strivio is currently operated by its founder, who is the only person with access to production systems. No contractors, offshore teams, or third-party support vendors have access to customer data.

Tenant isolation
Every data query is scoped to a tenant identifier and enforced by middleware on all customer-facing routes.
Role-based access
Five roles with a defined hierarchy. Cross-tenant requests by non-administrators are rejected and logged.
Administrative access logging
Administrative access that crosses a tenant boundary is recorded with operator identity, tenant accessed, endpoint, source IP, and timestamp. These records are append-only.
IP allowlisting
Customer-configurable per organization.
How access is used
To investigate and resolve issues: support requests you raise, and platform errors affecting service integrity. We do not access customer data for any other purpose.

What we do not have yet. We cannot provide customer-visible support-access reports, and we have no separation of duties, because there is one operator. These change as the team grows, and we will update this page when they do.

For enterprise requirements. If you need restricted vendor access, access notification, or specific contractual controls, raise it during evaluation. We can commit to these contractually rather than discover a mismatch later.

Backups and recovery

Our production database runs on a shared MongoDB Atlas tier that does not include automated backups. We take manual snapshots and store them separately from production.

Migrating to a dedicated cluster with continuous backups and point-in-time recovery is our next planned infrastructure investment. We will update this page when it is complete.

If your requirements include a specific recovery time or recovery point objective, tell us before you buy. We would rather have that conversation upfront.

Security testing

Automated tests
206 tests across 13 suites covering detection, policy enforcement, governance workflows, and durable resolution.
Dependency scanning
npm audit against production dependencies. Zero known advisories as of 18 August 2026.
Detection coverage
16 weighted detection categories spanning sensitive data, injection, exfiltration, and behavioral signals.
Third-party penetration test
Not performed.
Planned. We will not describe internal testing as a penetration test.
Independent security assessment
Not performed.

Incident response

We maintain an incident response process for investigating suspected security events. If a confirmed incident materially affects customer data, affected customers will be notified without unreasonable delay after verification and assessment.

We have not adopted a specific regulatory notification window. If your agreement requires one, raise it during evaluation and we will address it contractually.

Reporting a vulnerability

If you have found a security issue in Strivio, we want to hear about it. Email security@strivioai.ai with reproduction steps, affected endpoints, and supporting evidence.

We acknowledge receipt and investigate reported issues. We will not pursue legal action against researchers who report in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate.

We do not currently operate a paid bug bounty. We credit researchers publicly with their permission.

Security questionnaires and vendor review

Send questionnaires to security@strivioai.ai. We respond to vendor security reviews and will tell you plainly when we cannot meet a requirement.

For commercial questions, contact sales@strivioai.ai or book a demo.