Security & limitations

Trust model

AgentMesh runs models on computers owned by independent providers. Container and process isolation protect the provider's machine from the workload; they do not protect the workload from the provider. A provider can read the model files, the process memory, and every prompt and response their node handles. Confidential computing (hardware-isolated nodes with attestation) is not implemented.

Use community nodes only for data you would be comfortable sharing with a stranger.

What data is stored

Logs redact API keys, node credentials, bearer tokens and Paystack keys.

Worker safety for providers

• The worker only accepts “deploy an approved model with these limits” and “stop” from the control plane, and validates both. It never runs customer commands.
• Model weights come only from allowed hosts (Ollama registry, Hugging Face), pinned to exact versions and checked by digest; every redirect is checked.
• Workloads use their own ports, model directories and processes; your own Ollama install is never used or modified.
• On Linux, each workload runs in a systemd user scope with hard memory and CPU limits. On macOS limits are advisory.
• Signed self-updates accept only releases signed with the operator’s offline key, so a compromised control plane cannot push code.
• The Docker worker needs the Docker socket, which is root-equivalent on the host. Prefer rootless Docker on a dedicated machine.

Platform controls

• Login and registration are rate limited per client address and per email.
• Production startup refuses insecure settings: weak SECRET_KEY, wildcard CORS, non-https public URL, or an unapproved live Paystack key.
• Security headers on the API and dashboard (nosniff, frame denial, referrer policy; HSTS on the API in production).
• Paystack webhooks are checked with an HMAC-SHA512 signature in constant time, processed once, and credited only on matching amount and currency.
• All balance changes go through ledger entries with idempotency keys; reconciliation checks balances against the ledger.
• The dashboard redirects to checkout only on Paystack’s own domain.
• Billable output tokens are capped by the response bytes the gateway counted itself.

Known risks

These are recorded in the project's security review and are not fixed yet:

• Token counts come from the provider’s machine. The byte cap bounds output-token inflation but does not prevent it; input tokens are not bounded.
• A provider could keep a broken runtime “READY”: customers see failed requests, but resource time is still charged. Refunds need a ledger correction feature that does not exist yet.
• Session tokens are kept in the browser’s localStorage and there is no Content-Security-Policy yet, so an XSS bug could steal a session.
• No multi-factor authentication for anyone, including operators who approve payouts.
• Per-email login throttling lets someone who knows your address delay your sign-in by up to a minute.
• Customer balances can go below zero by up to one billing interval before deployments stop.
• The audit log is not tamper-evident, and secrets live in environment variables rather than a secret manager.

Not yet verified

Reporting a vulnerability

Providers: if you suspect your node's credential was exposed, revoke the node in the dashboard; the worker stops its workloads and deletes its credentials when it learns it was revoked. Customers: revoke exposed API keys under API Keys.