Security

Email support@meshcrunch.com with Security in the subject and enough detail to reproduce the issue. There is one inbox, not a separate security address — we would rather tell you that than publish a second one nobody is watching. We will confirm receipt and keep you updated while we investigate. Please give us a reasonable window to remediate before disclosing publicly.

We aim to acknowledge a report within three working days and to give you an assessment within ten. There is no bug bounty and no payment; if that matters to you, say so before spending time on it. We will credit you when a report leads to a fix, unless you would rather we did not.

The website, the API, and every transfer to and from object storage use HTTPS. API certificates are issued by Let's Encrypt and renewed automatically at the ingress; the website is served over TLS by our hosting provider.

• Uploaded models and generated outputs live in a private object-storage bucket. There is no public read access and no public URL for any file.
• Uploads go directly from your browser to storage using a URL we sign for one specific location. Model data never passes through our API.
• The server chooses every storage location. A client cannot name one, which is what prevents a request from being aimed at somebody else's file.
• Downloads use signed URLs that expire in five minutes, generated per request. Storage locations are never disclosed to a browser, and no long-lived link to a private file exists.
• Upload URLs expire in ten minutes, and the size limit is enforced against the object that actually arrived — a signed upload URL cannot cap its own transfer, so verification happens afterwards and anything oversized is deleted.

• Sign-in is handled by Auth0. MeshCrunch never receives or stores your password, and no access token is exposed to your browser — it is attached to API calls server-side.
• Anonymous sessions use a token signed by our API and held in an HTTP-only cookie that scripts cannot read. Identity is never taken from anything a client can simply assert about itself.
• Every request for an asset, job, result, or download URL is checked against the caller's verified identity. A request for something belonging to someone else is answered as not found, so record identifiers cannot be probed for existence.
• Authorization is enforced by the API, not by the interface. Calling the API directly gains nothing over using the site.

• An AI client connects over OAuth, through the same Auth0 sign-in the web app uses. There is no API key to create, store, or paste into a configuration file, and nothing to leak if one is committed by mistake.
• Tokens are issued for the MCP service as a separate resource from our REST API, so a token obtained for an agent cannot be replayed against the API, and the reverse is equally true.
• Access is granted by explicit consent to two named permissions, one to read and one to run jobs that spend your processing credits. Approving only the read permission is supported, and gives you an agent that can see your library but cannot spend anything.
• The sign-in window always opens on auth.meshcrunch.com. A consent screen on any other domain, or one that appears when you did not start a connection, should be closed — no legitimate connection begins without you asking for it.
• An agent is bound to the account that authorized it and reaches nothing else. Every call goes through the same ownership check as a browser request, with the same not found answer for anything belonging to someone else.
• Plan limits apply unchanged. An agent passes the same quota and credit gates as the web app, so it has no separate allowance and connecting one raises no limit. Paid entitlement is re-derived from the subscription on every call rather than at connection time, so access ends when a subscription does rather than at the next reconnection.
• Mesh data never passes through the MCP server. Models are uploaded through the web app straight to object storage; an agent works on what is already in the account and receives short-lived download URLs, not bytes. Removing the server from your client ends its access.

• Processing runs on dedicated worker services, separate from the API, each in its own container running as a non-root user.
• Mesh tools are run as isolated subprocesses with a fixed time budget and arguments passed as a list — never assembled into a shell command — and every intermediate file stays inside a temporary directory created for that one job and destroyed with it.
• Uploads are screened against a closed list of accepted formats and a content check before a worker ever opens them.
• Worker containers drop every Linux capability, run under the default seccomp profile, cannot escalate privileges, and have a read-only root filesystem — the only writable path is the scratch volume holding that job's temporary directory, which is destroyed with the pod.
• Each has a hard CPU, memory, and disk ceiling, and each job has a time budget. An input crafted to run forever exhausts its own budget and fails with a message; it cannot occupy a worker indefinitely or starve the rest of the cluster.
• Preview images for the asset library are rendered by the same worker services, under the same isolation, from the model you uploaded and nothing else. They are written to the same private storage and reached the same way — an ownership check, then a short-lived signed link.
• Conversion output is read back and parsed before it is stored. A file the exporter wrote but no parser accepts is discarded rather than handed to you, and a failed conversion leaves nothing behind in storage.
• Uploads and job submissions are rate-limited per identity, with stricter limits for anonymous sessions, which are free to create.

• An asset you delete is removed from storage as part of the request, along with every output generated from it. The record is marked deleted only once the files are actually gone.
• An asset you leave alone is deleted automatically when its retention window closes — a scheduled sweep runs hourly and removes the expired source, its outputs, and any artifact a job wrote without recording. Failures are retried and escalated rather than swallowed.
• Uploaded models and generated outputs are not backed up. One copy exists, and a deletion is unrecoverable. That is a deliberate trade in your favour on privacy and against you on recovery, so keep your own copies.
• The metadata database — accounts, asset records, job history, subscriptions — is backed up nightly to separate private storage under a credential scoped to it alone, kept for 30 days. Each dump is read back with pg_restore before it is stored, which proves the archive is complete and readable but stops short of restoring it; any step that does not end in a verified stored file exits non-zero rather than passing quietly. This protects your account and the record of your work; it does not protect the model files, which are not in the database.

Credentials for the database, message broker, object storage, and identity provider are held as secrets in the deployment environment and are never present in the codebase or in the browser. The manifests in our repository carry placeholders, and the deployment workflow is written to apply files individually so it cannot overwrite a live secret with one.

On internal access we will only claim what is true of a small team: the people who operate the service can reach the production database and the storage bucket, because someone has to. There is no formal approval workflow, no per-access audit trail, and no separation of duties. If your procurement process requires those, we do not have them.

Both services write structured JSON logs: request and job identifiers, timings, stage names, error messages, file sizes and storage keys. They never contain model contents, credentials, access tokens, or signed download URLs. A collector running on the node forwards them to a log store, so one job can be followed across the API and the worker that ran it rather than only inside a single process.

Logs are kept for 30 days and then deleted automatically, the same window we retain metrics for. Both the collector and the store run on our own infrastructure inside this deployment, so application logs are not sent to a third-party logging provider. Anyone who can reach the monitoring dashboard can read them, which means the operators described under Secrets and access above.

Stated explicitly, because their absence matters as much as the controls above:

• No SOC 2, ISO 27001, or comparable audit or certification. We are not in a readiness programme for one.
• No signed data-processing agreement, and no contractual SLA on offer.
• No penetration test has been commissioned, and no third party has reviewed this system.
• No customer-managed encryption keys, and no guarantee about which geographic region your files are stored in.
• No public status page. We have an internal incident runbook, but no committed breach-notification timeframe beyond what the law requires of us.
• No backups of uploaded models or generated outputs. The metadata database is backed up nightly; the files themselves are not.
• Database backups are stored in private object storage but are not encrypted with a key held outside the deployment, so an operator with cluster access can read them.
• Database restores are exercised by hand rather than on a schedule, so nothing periodically proves a dump is still restorable.
• No single sign-on, no customer-visible audit log, and no formal internal approval workflow for production access.
• No alerting. Metrics and logs are collected and can be graphed, but no rule watches them and nothing pages anyone, so a fault is found when someone looks or when a customer tells us.
• No liveness probe on the processing workers: one that wedges without exiting is noticed by queue depth rather than by the platform.

If you need any of these for a procurement process, email support@meshcrunch.com and we will tell you honestly where we stand.