Security is a property of where your agents run
with xpander, agents run inside your own environment, governed by your own controls.
Your data, your audits, and your agents’ memory stay in your cluster and leave it for no one.
SOC 2 Type II certified
GDPR compliant
BUILT FOR ORGANIZATIONS WITH THE STRICTEST SECURITY AND COMPLIANCE REQUIREMENTS
Government
Defense
Critical Infrastructure
Insurance
Finance
Retail
Who draws the boundary around your agents
What the July 2026 agent security incident taught us about running agents in an environment you control.
001
The model never sees your secrets
Credentials live in a vault and are attached downstream on the execution path, after the model’s context ends. Nothing in context to leak.
002
Runs inside your perimeter
Any cloud, your VPC, on-prem, or fully disconnected. Native Kubernetes workloads, so your firewall and egress policy govern the agent.
003
Identity all the way down
Full OIDC end to end. Agents act with the invoking user’s permissions on every call, down to individual tools and to LLM inference.
004
Isolated execution
Throwaway containers: non-root, all Linux capabilities dropped, read-only root filesystem, destroyed when the call returns.
005
Every agent is a governed actor
Each agent has its own identity, scoped permissions, and an owner. Permissions are policy, not convention, whoever built it.
006
Your observability, not another console
Agents emit into your own OpenTelemetry pipeline. No parallel plane to operate, including in a fully disconnected install.
Your infrastructure enforces it, not our promise
A vendor’s sandbox is an attestation you cannot inspect.
A network policy in your own cluster is a control you enforce, and it holds whether or not we got every internal control right.
A vendor-drawn boundary
Hosted platforms, including ours
Isolation you cannot inspect or change
Egress on a path the vendor controls
An assurance you are asked to take on trust
A boundary you draw
Installed in your own cluster
Your firewall, your CNI, your egress policy
Deny-by-default means there is no route out
A control your team enforces and can verify
DEPLOY IN
Managed cloud
Your VPC
On-prem
Air-gapped
GOVERNED BY
Your firewall
Your CNI
Your egress policy
Your identity provider
OBSERVED WITH
Your OpenTelemetry
Your SIEM
Your dashboards
What your security team gets
Deploy where your security requires
The perimeter around your agents is the one your security team already operates.
Managed cloud, your VPC, on-prem, or fully disconnected
Native Kubernetes workloads your tooling treats like any application
No data egress in self-hosted mode; your data trains no one’s model
Every action tied to a real identity
Every agent is a governed actor with a scoped identity, not a shared service account.
RBAC at organization, workspace, agent, and action level
OIDC end to end, down to tools and LLM inference
Per-agent identity with scoped permissions
Credentials your agents use but never hold
Your internal systems become governed tools from an OpenAPI spec or any MCP server.
Secrets in a vault, injected at tool-call time
The model never sees a credential
Per-call, org-scoped role assumption for cross-account access
Nothing survives a call it should not
The shared-writable-surface pattern behind recent public incidents does not exist here.
Ephemeral, non-root, capability-dropped, read-only containers
Per-agent isolated storage, no cross-agent surface
No mounted cluster credentials in the agent workload
Your data stays yours
In self-hosted deployments no operational data leaves your network at all.
TLS 1.3 in transit, AES-256 at rest
Zero-retention agreements with model providers; no training on your data
Tenant isolation in cloud; full data residency in self-hosted
A record of what every agent did
Because the platform executes each action, it lands on the record as it happens.
Full execution traces: runs, tool calls, approvals, cost, failures
Human approval as a step for sensitive actions
Export to your SIEM and observability stack
Certifications
SOC 2 Type II
Independently audited controls for security, availability, and confidentiality.
GDPR
Compliant data processing, with residency determined by where you deploy.
Security is ongoing, not a checkbox
Third-party penetration testing
Regular external tests, with findings tracked to resolution and security updates shipped on a defined cadence.
SIEM export
Security-relevant events flow into the tooling your team already monitors, alongside everything else in your stack.
Prompt-injection detection
Agent inputs are screened before they can turn into a tool call your systems would honour.
Where does our data actually live?
Where you deploy it. In self-hosted mode, agent execution, memory, retrieval, and audit records stay inside your own cluster and leave it for no one. In our managed cloud, data is tenant-isolated and encrypted in transit and at rest. You choose the model based on your residency requirements, not ours.
Can we run agents with no internet access at all?
Yes. The platform installs as native Kubernetes workloads in your environment, including fully disconnected deployments. Because the agent is an ordinary workload in your cluster, your firewall and network policy govern its egress. A deny-by-default policy means an agent has no route out, enforced by your infrastructure rather than by a setting we control.
Does the model ever see our credentials?
No. Agents compose the intent of a tool call, and the credential is attached downstream on the execution path, after the model’s context ends. Secrets are held in a vault and injected at call time. There is nothing in the model’s context to leak or to pass to another agent.
How is this different from an agent platform hosted on a single cloud?
A cloud-hosted platform draws the boundary around your agents inside its own infrastructure, and you get an assurance you cannot inspect or change. xpander installs in an environment you control, so the boundary is yours: your network policy, your monitoring, your identity provider, your data. You are not asked to trust an isolation you cannot see.
We do not want to bet on one model vendor. How do you handle that?
xpander is model-agnostic. Any provider or self-hosted open-weight model sits behind one gateway, and you set which models are allowed, how traffic routes, and what happens on failure as policy. When a model changes, is repriced, or no longer meets your requirements, you swap it and keep the agent. Your data is covered by zero-retention agreements and is never used for training.
How do agents authenticate to our internal systems, and with what permissions?
Your systems become governed connectors, and agents act with the invoking user’s identity through OIDC, down to individual tools and to model inference. An agent inherits the access of the identity behind it and nothing more, and retrieval respects the asking user’s permissions. Every call is attributable to a real user.
What can we audit, and where does it go?
Because the platform executes each action, runs, traces, tool calls, approvals, costs, and failures are recorded as they happen. Traces, logs, and metrics export to your existing observability and SIEM tooling, so agent activity is visible alongside everything else you monitor.
Do you hold certifications, and can we see the reports?
xpander is SOC 2 Type II certified and GDPR compliant. Reports, subprocessors, and our current security posture are available in our Trust Center at trust.xpander.ai.
One platform, governed by your controls
Build, run, and govern every AI agent in your company inside an environment you own.