How we protect your data.

Mesedi is a single Go backend on Fly.io (iad / Ashburn, VA) backed by SQLite on a dedicated persistent volume, with a Next.js dashboard on Vercel and SDKs distributed via PyPI and npm. All customer data lives in the single SQLite database; there is no shared multi-tenant query layer where a misrouted query could expose another customer's rows. Tenancy is enforced at the application layer by binding every authenticated request to its project_id and filtering every read by that id.

The backend, SDKs, and dashboard are MIT-licensed and the full source is on GitHub. You can audit our auth, our SQL, and our webhook signature verification yourself. We consider open-source review a meaningful part of our security posture, not a marketing point.

In transit: TLS 1.2+ on every public endpoint. Fly.io terminates TLS for the backend at mesedi-api.fly.dev and Vercel terminates TLS for the dashboard at mesedi.vercel.app. Both force HTTPS via HSTS. Our SDKs refuse plaintext HTTP by default.

At rest: The Fly persistent volume holding the SQLite database is encrypted at rest at the storage layer (Fly's underlying block storage). API key hashes are stored SHA-256-hashed; we never persist the plaintext value. Stripe customer and subscription identifiers are stored in plaintext alongside the project row because they are not secrets, the security boundary for billing data lives at Stripe itself.

Customer-managed keys: Not offered today. The Fly-level encryption is provider-managed. Customer-managed encryption (BYOK) is on the roadmap behind an Enterprise contract; we don't pretend to have it for Hobby or Pro tier right now.

Customer API authentication is a bearer token on every request. Tokens are validated via a SHA-256 hash lookup with a per-key cache to bound database load. Failed authentication does NOT leak whether a key prefix exists or not, every unauthenticated response is a generic 401.

Customers can mint and revoke their own API keys from the dashboard. Rotating a key is a one-click operation; the old key stops working immediately.

Founder-side admin endpoints are gated by a separate bearer token (MESEDI_ADMIN_TOKEN) compared in constant time against the configured value. The admin token has no overlap with customer keys; the two auth chains cannot grant each other access. The admin endpoints themselves run behind a fail-closed middleware that refuses every request when the token is unset.

The Stripe webhook receiver verifies the Stripe-Signature header against the configured webhook secret using Stripe's own ConstructEventWithOptions helper. Replay attempts and forged webhooks are rejected with 400 and logged.

The backend runs an in-process rate limiter on the public POST /signup endpoint to bound automated abuse from a single IP. Inside the authenticated perimeter, the execution counter on each project lets us detect sudden volume spikes, a key abused after a GitHub leak typically shows a 10-100x volume jump within hours.

Stripe webhooks for charge.dispute.created, invoice.payment_failed, and subscription state changes feed into our admin dashboard so we can act on fraud signals and dunning cases without polling Stripe.

We do not run automated content scanning on telemetry payloads. The Acceptable Use clauses in our Terms cover what customers may not send us; we act on confirmed reports rather than continuous classification.

The full list of third parties that touch customer data lives in the Privacy Policy. The short version: Stripe (payments), Fly.io (backend hosting in Ashburn, VA), Vercel (dashboard hosting), GitHub (source code and SDK distribution), PyPI and npm (SDK distribution). All data is stored in the United States. EU residency is not available today.

Mesedi's technical capability satisfies specific clauses in several AI and security frameworks. These are self-assessed mappings, not third-party audits, but the alignment is concrete and documented:

NIST AI RMF (Measure.2): our SDK plus backend produces a model-output measurement record for every agent execution, which is exactly what Measure.2 calls for under the framework's Measure function.

ISO/IEC 42001 (clause 9, performance evaluation): our eight failure-class detectors run continuously against the event stream and cluster repeated failures into named groups. That is performance evaluation in the sense the standard means it. Our failure-class catalog maps cleanly to clause 9's risk taxonomy.

EU AI Act Article 12 (automatic logging): Article 12 requires high-risk AI systems to keep immutable records of operation. Every execution we ingest is stored with start time, end time, status, token counts, cost, and the full event stream. That record satisfies the Article 12 logging requirement today; you can export it via the Privacy Policy export workflow for your own audit needs.

The framework alignment work was first done at our parent company, Verdifax, LLC, and applies to Mesedi because the underlying technical capability is shared.

Detection alone is not always enough. When an AI failure ends up in front of a regulator, an insurer, or a court, what matters is whether you can prove what happened with evidence the other side cannot dispute. Most AI observability tools produce logs that an operator could theoretically tamper with after the fact.

We are building a tier on top of Mesedi's failure detection that seals every detected incident into a tamper-evident audit certificate. Each certificate binds the agent's git commit, container hash, model identifier, full input/output transcript, and detector decision into a cryptographically signed record. The record satisfies EU AI Act Article 12 in a form that passes legal admissibility tests, not just regulatory checklists.

The attestation technology is provided by our sister product Verdifax, which holds the underlying patent-pending methods. The Mesedi integration is expected on the Cloud Pro tier in late 2026. If your workload requires a court-grade audit trail today, email sales@verdifax.com and we will discuss an early-access arrangement.

Self-assessed framework alignment is not the same as a third-party audit. We have not yet pursued audited certifications; the cost and timeline only make sense once enterprise customers are asking. Our priorities, in order:

SOC 2 Type I when we cross five paying enterprise customers asking for it. Estimated 4-6 months from project start to first report.

ISO 27001 follows SOC 2. Substantial overlap in evidence so the second audit costs less than the first.

HIPAA not on the roadmap. Mesedi is not the right tool for processing protected health information; agent telemetry should be redacted before reaching us if your workload touches PHI.

The backend repo runs Dependabot for both Go modules and JavaScript packages. High-severity advisories against any dependency get triaged within one business day.

Every deploy to production builds a multi-stage Docker image with the Go binary statically linked, then runs on an Alpine base. The image ships only ca-certificates and tzdata alongside the binary; there is no shell, no compiler, and no package manager available to a process running inside the container.

The single Fly machine runs in auto-start / min-1-running mode behind Fly's load balancer, with health checks at /health. Logs ship to Fly's log aggregation; the founder reviews structured warn / error lines daily.

If you find a vulnerability in Mesedi, please send details to security@verdifax.com. We commit to:

Acknowledge within 48 hours. You should hear back from a human, not an autoresponder.

Fix or mitigate within 14 days for critical vulnerabilities, 30 days for high, 90 days for medium. We will tell you what bucket we've placed it in and why.

Credit you publicly if you want, keep your name out of it if you don't. Your choice.

We do not run a paid bug bounty today. As we grow we will add one; in the meantime, a sincere thank-you note and credit on the changelog is the most we can offer.

Out-of-scope: denial of service attacks against our public endpoints, social engineering against our team, and reports that boil down to "your service has a public signup endpoint." In-scope: anything that lets one tenant read or write another tenant's data, anything that lets an unauthenticated caller take admin actions, anything that lets a malicious payload corrupt our store.

If a security incident affects your data, we will email you within 72 hours of confirming the incident with a description of what was affected, what we've done about it, and what (if anything) you should do.

If a regulatory framework you fall under (GDPR, CCPA, sector-specific) requires faster notification, we will meet that timeline. Email us at security@verdifax.com if you need a written commitment to your specific regulatory timeline.

security@verdifax.com

Machine-readable disclosure metadata: /.well-known/security.txt