Skip to main content
Erys
Security

Eight layers of defence in depth

While other agent platforms ship with plaintext credentials and remote code execution vulnerabilities, Erys runs every agent inside multiple layers of isolation, from the kernel up. Security isn't a feature — it's the foundation.

Defence in Depth
EU Hosted
Encrypted
GDPR Compliant
49,500OpenClaw instances vulnerable to RCE
0Erys instances with known vulnerabilities
400+Unvetted OpenClaw skills (malware found)
8Independent security layers in Erys

What security researchers say

Independent research teams have publicly analysed agent platform security. The findings are clear.

A lethal trifecta of remote code execution, credential theft, and unvetted third-party skills.

Palo Alto Networks (Unit 42)

A security nightmare for organisations that deploy it without understanding the attack surface.

Cisco Talos Intelligence

Found unsafe for use in any environment handling sensitive data.

Kaspersky Labs

How we protect your agents

Each layer adds an independent barrier. Compromise of one layer does not compromise the others.

01

gVisor kernel-level sandboxing

Every agent container runs inside a gVisor sandbox, intercepting all system calls before they reach the host kernel.

gVisor provides an application kernel written in Go that implements a substantial portion of the Linux system call interface. It acts as a barrier between the containerised application and the host kernel, meaning even if an agent executes malicious code, it cannot access host resources. This is the same technology Google uses to isolate workloads in Google Cloud.

02

UID/GID process isolation

Each agent process runs under a unique, unprivileged user ID. No two agents share the same identity.

Every agent is assigned a unique UID and GID at creation time. This means processes from one agent cannot read, write, or signal processes belonging to another agent, even if they share the same node. File system permissions enforce strict separation at the OS level.

03

Non-root containers

All containers run as non-root users. No agent has elevated privileges on the host.

Container images are built to run as non-root by default. The Kubernetes security context enforces runAsNonRoot: true and drops all Linux capabilities. Even if an attacker gains code execution inside a container, they cannot escalate to root or modify system binaries.

04

Namespace Pod Security Standards

Kubernetes namespaces enforce the Restricted pod security standard, the strictest level available.

We apply the Pod Security Standards (PSS) Restricted profile at the namespace level. This prevents privilege escalation, host namespace sharing, host path mounts, and use of privileged containers. Every pod must pass these admission checks before it can be scheduled.

05

Network policies

Network policies restrict all inter-pod communication. Agents cannot communicate with each other or with unauthorised services.

Calico network policies enforce a default-deny posture. Each agent namespace only permits egress to the internet (for API calls) and ingress from the agent-backend service. Agent-to-agent traffic is blocked. Internal services are further restricted to only the ports and protocols they need.

06

Read-only root filesystem

Container root filesystems are mounted read-only. Agents can only write to their designated working directory.

The root filesystem of every agent container is mounted as read-only. Writable storage is limited to an emptyDir volume mounted at the agent working directory. This prevents attackers from modifying system binaries, installing backdoors, or persisting malware outside the designated directory.

07

External Secrets Operator

Secrets are never stored in cluster manifests. They are injected at runtime from Google Cloud Secret Manager.

We use the External Secrets Operator to sync secrets from Google Cloud Secret Manager into Kubernetes. Secrets are never committed to Git, never stored in ConfigMaps, and never visible in pod specs. They are mounted as environment variables at container startup and rotated automatically.

08

Encryption at rest and in transit

All data is encrypted with AES-256 at rest and TLS 1.3 in transit. No exceptions.

Google Cloud encrypts all data at rest by default using AES-256. All network traffic between services uses TLS 1.3 with certificate verification. Database connections to Cloud SQL are encrypted via the Cloud SQL Auth Proxy. There is no unencrypted data path in the platform.

Data residency & GDPR

All Erys AI infrastructure runs on Google Cloud Platform in the europe-west4 (Netherlands) region. Your data never leaves the EU unless you explicitly connect to a third-party AI provider that processes data elsewhere.

We are fully compliant with GDPR and the UK Data Protection Act 2018. You can request access to, correction of, or deletion of your data at any time. We respond to all data subject requests within 30 days.

For AI model provider data handling, we offer Bring Your Own Key (BYOK) support, allowing you to use your own API keys and contracts with Anthropic, OpenAI, or Google directly. This means your agent conversations are governed by your own agreements with those providers.

Ready for agents you can actually trust?

Try Erys free with 100 AI credits. See what proper agent security looks like — no Docker, no plaintext credentials, no sleepless nights.