Privacy and security

Tenant isolation

Every MCP credential maps to exactly one verified Skavio company. The company, role and rights are taken only from the credential and the private operator binding; no tool argument can select them. Company A can never read, spend or download a result for company B. Isolated tenants are exercised in the test suite, including cross-tenant download denial.

The upstream Processing API credential is held privately by Skavio and is never forwarded to, or disclosed to, an MCP client. Your MCP credential is never sent to the upstream API.

Transport and edge protection

• All traffic uses HTTPS to www.skavio.eu.
• The HTTP server enforces Host and Origin allowlists.
• JSON-RPC responses are bounded; oversized or non-finite bodies are rejected.
• Request bodies, uploads and results have explicit size ceilings.

SSRF and download safety

Result downloads use the exact authenticated path in owned result metadata. Redirects require an explicit storage-host allowlist, HTTPS and a public address; the connection is pinned to the validated IP with the original TLS hostname. Private, multicast and embedded-private IPv6 addresses are rejected. Bearer tokens are never forwarded to storage. Proxy configurations without verified pinning fail closed.

Signed delivery

Every download returns X-Skavio-Tenant, X-Skavio-Content-SHA256 and X-Skavio-Content-Length, plus a detached HMAC-SHA256 signature (X-Skavio-Signature) when the binding carries a delivery key. The signed message binds tenant, job id, result id, byte length and digest, so a client can detect tampering, truncation or cross-tenant substitution. The signing key is operator-provisioned, never returned to a caller and never logged.

Secrets and logging

• Credentials and upstream keys are never logged. Protocol logs are redacted;

audit records contain only allowlisted tool metadata.

• The server never asks you to paste a credential into a chat, code, URL or

report. Store credentials in a secret manager.

• Rotate and revoke credentials from the dashboard; revocation takes effect

immediately.

Data retention

• Local results are private, atomically published, fsynced, and retained for a

bounded window (currently seven days). Expired artifacts and crash-orphaned temporary files are removed while accounting/idempotency records are kept.

• Upstream data follows the Skavio storage policy

and your company retention settings. Local cleanup never deletes customer-owned upstream objects.

• Uploads have no upstream idempotency guarantee; the upload intent is persisted

before dispatch and an uncertain upload is never repeated automatically.

Limits

The server bounds each result to 8 MiB, local results to 256 MiB, remote request bodies to 128 KiB, concurrent requests to eight, and retained upload intents to 1,000 per company. A shared durable request ceiling protects the upstream rate limit. Larger transfer limits require a separately measured streaming/upload session; they are not silently increased.

Durability and recovery

SQLite WAL with FULL synchronization and write transactions protects concurrent admission and spending ceilings. Intent hashes, quotes, job IDs, commercial decisions and accounting survive process restart. Submission commits the intent before dispatch and always reuses its original key and cap. Backups use SQLite's consistent backup API, including committed WAL pages.

Reporting a vulnerability

Contact Skavio through the Skavio website with a description and reproduction steps. Do not include live credentials or customer data. Do not test against other companies' data.