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, and tests check that prompts, outputs and credentials never appear in them, including on error paths.

Retention and deletion

A background job deletes expired data hourly. Deleting a finished AI run (DELETE /ai/deployments/{id}) removes it from the live database at once and reports what was deleted; copies in database backups disappear when those backups expire.

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.
• Every command carries an Ed25519 signature bound to your node, that command, its exact payload (model, digest, limits), an expiry and a single-use nonce. The worker pins the control plane’s key at enrollment and refuses anything unsigned, altered, expired, replayed or addressed to another node.
• The worker proves it holds the private key generated on your machine at enrollment to get one-hour sessions; the enrollment credential alone is not enough once legacy mode is off.
• 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; client addresses come only from the configured proxy (FORWARDED_ALLOW_IPS).
• Access tokens last 15 minutes and belong to a server-side session: signing out ends it everywhere at once. Refresh tokens work once; reusing one ends the whole session.
• Operators and admins must use a TOTP authenticator app; without it, no operator feature or other customer’s data is reachable.
• Operators can quarantine a node instantly (no authentication, tunnel closed, deployments moved) and release it later. Open tunnels re-check their node every 15 seconds, so a revoked or quarantined node is cut off within 15 seconds even if the disconnect message is lost.
• 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). The dashboard’s Content-Security-Policy lets it load scripts only from itself and send data only to itself and the API.
• Unset ENVIRONMENT counts as production, so a forgotten setting cannot run with development defaults.
• 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.
• Token counts reported by provider machines are treated as claims: billable output tokens are capped by the response bytes and input tokens by the request size the gateway counted itself. Operators see providers whose claims exceed what was observed.
• CI pins every action to a commit SHA and runs dependency, secret, static-analysis, container and configuration scans on every pull request.

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 size caps bound inflation but do not prove the provider ran the right model; signatures prove a message is intact, not that the work was done honestly.
• A provider could keep a broken runtime “READY”: customers see failed requests, but resource time is still charged until an operator refunds it.
• Tokens are kept in the browser’s localStorage. The CSP limits where an injected script could send them, but it still allows inline scripts.
• Workload containers run as the image’s default user (root for the Ollama image), and GPU deployments see every GPU on the machine.
• 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.