Weave puts a semantic firewall, envelope-encrypted credentials, tenant-scoped access control, and an audit trail between your AI clients and the MCP servers they call.
Hosted in Germany. Where a protection is opt-in, configurable, or still being rolled out, this page says so.
Tool calls, resource reads, and prompt gets on the gateway and MCP transports pass through a pipeline of 10 security scanners on the request and response side (some scanners apply to one direction only). Enforce mode is the default; deployments and tenant policies can switch to shadow mode, which records findings without blocking.
Detects API keys, tokens, private keys, and connection strings before they reach tools or leave the platform.
Identifies personal data like SSNs, credit card numbers, German IBANs, and email addresses in tool arguments and results.
Catches system override attempts, role impersonation, delimiter injection, and response poisoning.
Detects dangerous shell commands (rm -rf, DROP TABLE), SQL injection, reverse shells, and force pushes.
Detects exfiltration endpoints (webhook.site, ngrok), credentials in URLs, and internal network access attempts.
Catches bulk data extraction patterns, SELECT *, pagination bypass, and oversized response payloads.
Detects privilege escalation (sudo), path traversal, command chaining, and subcommand injection.
Flags request arguments that target cloud metadata, loopback, or private network addresses, including encoded IP forms.
Flags invisible Unicode bidirectional override characters used for visual spoofing.
Neutralizes instruction-like markup (<system>, <IMPORTANT>) in tool responses before it reaches the model.
Call rejected before it reaches the MCP server (on the response side, the result is withheld). Audit entry recorded.
Sensitive content replaced with safe placeholders. Execution continues with cleaned data.
Call held until the user or a tenant admin approves or denies it. Pending approvals expire after 5 minutes by default.
Finding recorded in audit trail. Execution continues unchanged.
The firewall scans the MCP transports below, not just REST.
Credentials are encrypted with a unique per-tenant Data Encryption Key (DEK). The DEK itself is encrypted with a Key Encryption Key (KEK) held by the KMS provider configured for the deployment. If the tenant key cannot be used, encryption falls back to the platform-wide key and the fallback is logged.
AES-128-CBC + HMAC-SHA256 authenticated encryption. Stored credentials are kept only in encrypted form in the database.
Each tenant gets a unique random encryption key. Compromise of one tenant's data does not expose others.
KEK managed via Local Fernet (default), AWS KMS, or HashiCorp Vault Transit, selected per deployment.
The vault supports tenant DEK rotation: credentials are re-encrypted under row locks in one transaction and the key version is incremented. Rotation is not yet a self-service action.
MCP server credentials are decrypted server-side when a container starts and injected as environment variables, not passed through the model context.
A log filter on the backend root logger redacts common secret patterns (API keys, bearer tokens, passwords) from log messages.
Tenant separation is enforced in the application layer, which scopes queries to the caller's tenant. PostgreSQL Row-Level Security (RLS) policies are in place as a database backstop and are being rolled out to fail-closed enforcement.
RLS policies on tenant-scoped tables match tenant_id against the session tenant. A runtime guard flags queries without tenant context (warn by default, reject in strict mode). Database-level fail-closed enforcement is not yet active.
Four principal types (Human, Agent, Service, Workflow). API keys stored as SHA-256 hashes only — plaintext shown once at creation.
Fine-grained access control with allow/deny rules. Pattern matching on server names, tool names, and capability types.
Unknown OAuth scopes require admin approval. Predefined scope packs and scope policies classify risk (low to critical).
Servers granted an OAuth connection can call tools only while the grant is active and the connection is usable. Grants are individually revocable.
MCP server containers run with a read-only root filesystem, no-new-privileges, all Linux capabilities dropped, and memory, CPU and process limits. Non-root (UID 1000) is enforced on the Kubernetes runtime; on the Docker runtime, containers run as the image's own user.
Over 90 distinct audit actions are defined across the platform. Tool calls, logins, credential access, configuration changes, and governance decisions are recorded in a tenant-scoped audit log.
12 actions
Tool calls, resource reads, prompt gets, bridge requests
25 actions
Login, OAuth flows, token revocation, device registration
6 actions
Registration, data export (Art. 20), account deletion (Art. 17)
6 actions
Block, redact, require approval, log only, allow, confirmation resolved
Platform servers and databases run on Hetzner Cloud in Germany. Sub-processors are listed in our DPA; tools you connect call their own third-party APIs.
Self-service export (Art. 20) of account data (profile, servers, credential metadata, connections, reviews, audit entries) as JSON.
Self-service account deletion (Art. 17) that stops your containers and deletes your servers, credentials, connections, and profile. Audit log entries are retained.
Let's Encrypt certificates with auto-renewal. HTTP traffic redirected to HTTPS at the proxy. HSTS enabled with a max-age of at least one year.
X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, and a Permissions-Policy that disables camera, microphone, and geolocation.
Docker network separation: an internal network (database, Redis, backend, MCP containers) and a web network (reverse proxy, frontend, backend). Only the reverse proxy publishes public ports.
We publish our DPA (Art. 28 GDPR), privacy policy, and legal notice. For security-specific inquiries, contact us directly.