How we protect your data.

Mesedi is a single Go backend on Fly.io (iad / Ashburn, VA) backed by Neon Postgres 17 (AWS us-east-1, N. Virginia), with a Next.js dashboard on Cloudflare Workers and SDKs distributed via PyPI and npm. Hosted customer data lives in one Postgres database shared across every project. Tenancy is enforced at the application layer: every authenticated request is bound to its project_id and every read is filtered by that id.

We would rather state the consequence than imply separation we do not have. This is application-level isolation, not physical isolation: a bug in that filtering is the realistic path to one customer seeing another's rows. That is precisely why every read path filters on project_id, why tenancy is covered by tests, and why the source is public for you to check rather than take on trust.

Self-hosted deployments default to SQLite on local disk instead. Same schema, same tenancy filtering; you own the data and the backups.

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.

Every hour, per tenant, Mesedi commits a Merkle checkpoint over the events it ingested and anchors it to Rekor, Sigstore's public transparency log. The anchor lives in infrastructure Mesedi does not control, checkpoints chain to each other, and cumulative counts make a truncated export refute itself. Altering an already-anchored record afterward would require rewriting a public log thousands of other projects depend on.

Verification is designed to run without trusting us: every report ends with four steps that start from hashing your own export and building the mesedi-verify tool yourself from the public repo at the exact commit named in the report, never from a binary we hand you. It runs offline. The boundary is stated plainly on the evidence layer page: anchoring proves the record was not rewritten after the fact; it does not prove the events were true when written. Evidence begins at ingestion.

Mesedi observes your agent out-of-band via a one-line SDK wrap. We never sit in the critical path of your LLM calls, tool invocations, or agent execution: the SDK ships events asynchronously via a background shipper. If your agent code is running, an outage on our side does not stop it.

Fail-open remote halt. The SDK's optional hard-halt feature includes a Server-Sent Events subscription to GET /executions/{id}/halt-stream, used by the dashboard's operator Halt button. The reader is deliberately fail-open: connection failures, 4xx/5xx responses, and network partitions are caught, logged at DEBUG, and swallowed. The wrapped agent keeps running with any local budgets still enforced client-side. There is no hard dependency on Mesedi's backend availability.

Local budgets are enforced by the SDK, not the backend. Customers configure per-execution budgets across four axes (input tokens, output tokens, wall-clock seconds, step count) and the SDK enforces them at safe boundaries (between LLM calls, tool calls, and explicit checkpoint() calls) in the customer's own process. Enforcement never depends on Mesedi's backend being reachable. Mesedi itself never decides to halt an execution, only operators (via the dashboard button) or the customer's own budget rules do.

Backend dependencies. What DOES require Mesedi's backend: dashboard access, detector runs, webhook delivery, remote halt from the dashboard. Any of these degrade during a Mesedi outage. What does NOT: your agent's execution, its LLM calls, its tool calls, or any local budget you have configured.

In transit: TLS 1.2+ on every public endpoint. Fly.io terminates TLS for the backend at api.mesedi.ai and Cloudflare terminates TLS for the dashboard at app.mesedi.ai. Both force HTTPS via HSTS. Our SDKs default to the HTTPS production endpoint; the base URL can be overridden only for local development against a custom backend.

At rest: The Postgres database is encrypted at rest by Neon at the storage layer, and connections to it require TLS. Point-in-time restore covers a 24-hour history window, which is the practical limit on how far back a bad migration or an accidental delete can be undone. Stating it here rather than leaving it to a support ticket. 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.

Network access to the database: Postgres is reachable only over TLS, with credentials held as Fly secrets and never committed to source. We do not currently use an IP allowlist. Our API runs on Fly, whose outbound addresses are shared across the platform and can change without notice, so an allowlist would permit any workload on Fly while risking a silent outage whenever that pool shifts: operational fragility bought in exchange for a restriction that does not restrict the people who matter. Private networking via PrivateLink requires compute inside an AWS VPC, which is a platform change we have not made. Both are on the roadmap and neither is pretended to be in place today.

Customer-managed keys: Not offered today. The at-rest encryption is provider-managed by Neon. Customer-managed encryption (BYOK) is not currently available; if you need BYOK for your deployment, contact hello@mesedi.ai to discuss your requirements.

Recovery objectives. A bad migration or an accidental delete is restored from Neon's point-in-time history to the second, measured at 39 seconds on 27 August 2026. Losing the database provider entirely is the harder case: recovery runs from an off-platform backup, measured end to end at 11 minutes on 28 August 2026, covering provisioning a new database, restoring into it, and cutting the API over. Worst-case data loss in that scenario is up to 48 hours.

How far back we can restore. Different question from how much data a recovery loses, and the one customers usually mean. Anything in the last 24 hours can be restored to the second. Beyond that we hold one encrypted snapshot per day for 30 days. Past 30 days there is nothing: snapshots expire and are not archived. Stating the cliff rather than leaving it to be discovered.

Off-platform backups. A full database dump runs nightly, is encrypted with AES-256 before it leaves the machine that made it, and is stored with a different vendor from the database itself so that losing one provider does not mean losing the data. If a nightly backup does not happen, we are alerted within 36 hours.

We test the restore, not just the backup. A backup you have never restored is a hypothesis. An automated drill runs monthly: it fetches a real backup, decrypts it, restores it into a clean database, and fails loudly if the data is stale or the restore is incomplete. The full recovery path including cutover was rehearsed by hand on 28 August 2026.

What this does not cover. Everything runs in a single US region with no multi-region failover, so a full regional outage takes Mesedi down. Mesedi is operated by one person, with no on-call rotation and no secondary responder; if the operator is unavailable, recovery waits. We would rather you knew that before signing than found it out during an incident. It is also why a Mesedi outage is designed not to break your agents, described above under reliability posture.

If a project-admin key is compromised, email security@mesedi.ai. We acknowledge inside 48 hours, suspend the project, revoke the key, and share a 90-day report of every agent run and HTTP request attributed to that key. The full step-by-step procedure, what to include in your report, and what we explicitly do not do are documented in the incident response runbook. Read/write key compromises are self-service; rotate them from the API Keys page in your dashboard.

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 reveal whether a specific API key prefix exists in our store; every credential failure returns HTTP 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), Neon (managed Postgres, holds all hosted customer data, AWS us-east-1), Fly.io (API hosting in Ashburn, VA), Cloudflare (dashboard hosting, CDN, DNS, and encrypted off-site database backups in R2), GitHub (source code and SDK distribution), BetterStack (status page and uptime monitoring), Resend (transactional email), 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 twenty-plus 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.

Self-assessed framework alignment is not the same as a third-party audit. Mesedi does not currently hold any third-party audited certifications.

SOC 2 Type I is not currently pursued. Enterprise customers with SOC 2 requirements should contact us to discuss their timeline and audit scope.

ISO 27001 is not currently pursued. Enterprise customers with ISO 27001 requirements should contact us.

HIPAA: we are willing to sign a Business Associate Agreement with healthcare customers. The technical posture that makes this workable is already the default: agent telemetry payloads are truncated at the SDK before transmission, egress destinations are normalized to host-only so URLs never carry identifiers to us, and the data-leakage scanner redacts secrets and PII patterns before storage. PHI should still be minimized at the source; the SDK's truncation and redaction are the backstop, not the plan. Healthcare teams evaluating Mesedi should contact us to start the BAA conversation.

If you are evaluating Mesedi through a procurement or vendor-risk process, we answer standard security questionnaires (SIG, CAIQ, or your own format). Contact us and we will return written answers; most of what a questionnaire asks is already stated on this page, and where the honest answer is "not yet", that is the answer you will get.

What exists today: this page, the MIT-licensed source for the backend, SDKs and dashboard open to your own review, the sub-processor list above, two-factor authentication and OAuth sign-in on the dashboard, tier-configurable data retention with deletion on account closure, SDK-side payload truncation with pre-storage secret and PII redaction, and the verifiable audit trail described above, which your own auditors can check without trusting us. What does not exist yet: a SOC 2 report and a third-party penetration test. Both are planned against real customer demand rather than performed for the badge, and the open codebase plus continuous CodeQL analysis and the vulnerability disclosure process below are the interim substance behind that choice.

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 a distroless static 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@mesedi.ai. 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 pay cash bounties today. For any verified in-scope vulnerability, we will add 25,000 free agent executions to your Mesedi account as a token of appreciation, plus a thank-you note and credit on the changelog if you want public recognition.

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@mesedi.ai if you need a written commitment to your specific regulatory timeline.

security@mesedi.ai

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