> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xpander.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Architecture
> How xpander.ai keeps agents bounded, credentials isolated, and data governed - the design principles behind every deployment
xpander.ai enforces limits in two places:
* **In the runtime**: what each agent can do once running (operation surface, credentials, safety controls)
* **Where the runtime runs**: where agents run, what networks they can reach, where data lives
xpander runs in three deployments: xpander cloud, Hybrid and Air-gapped. This page covers the design principles that hold in all of them; each deployment page shows its network architecture and data flows:
Control plane and data plane hosted by xpander
Your VPC runs the data plane; xpander Cloud syncs configuration over PrivateLink
Every component in your environment; zero egress to xpander
***
## Permission model
Each agent's permissions are part of its *operation surface*, not its system prompt. A Jira agent built for PR triage doesn't have access to org-admin endpoints because those operations were never wired into its skill, not because a prompt tells the model "don't call them." A capability that doesn't exist can't be jailbroken, leaked through injected skill output, or coaxed out by a clever user.
This follows [NIST Zero Trust Architecture](https://www.nist.gov/publications/zero-trust-architecture): explicit verification, no implicit trust, least privilege, applied at the agent's operation surface rather than the network edge. [Agents assembled on xpander](https://xpander.ai/products/specialized-agents) are how this is exposed: each carries skills with a narrow set of operations, a named owner, and an audit trail.
***
## Credential isolation
The model sees a skill description (`"create_lead"`, with these parameters) and the call result, but never the OAuth token, API key, or IAM session credentials in between. The agent-controller's skill relay (`agent-controller`) and the execution tier broker authentication outside the agent loop. An attacker who compromises a prompt or skill output cannot exfiltrate a credential the model never had.
Credentials live as Kubernetes secrets and are read by the skill relay and the execution tier at invocation time. Supported patterns:
* **OAuth 2.0** with auto-refresh, scoped per skill
* **API keys and tokens** stored as secrets, injected at invocation time
* **AWS IAM roles** via EKS Pod Identity or IRSA, where skills assume per-skill roles. See [IAM Best Practices](/self-hosted/iam-best-practices).
* **End-user delegated identity**, where, if the outside system allows it, each user's own OAuth tokens authorize the call (so audit trails attribute actions to the right human)
For self-hosted deployments, create a Kubernetes secret with your LLM provider keys and reference it via `envFromSecretKeys` in your Helm values rather than passing keys as `--set` flags. See [Managing LLM API Keys](/self-hosted/hybrid#managing-llm-api-keys) for the canonical setup.
***
## Encryption
| Tier | What's encrypted | How |
| - | - | - |
| In transit | All xpander traffic | TLS, with ingress certs from cert-manager (Let's Encrypt or internal CA), externally provisioned certs mounted as a secret, or self-signed for dev. Hybrid control-plane sync is TLS 443 (public or PrivateLink). |
| At rest, application data | Agent state, threads, messages, memory, KB embeddings (PostgreSQL); cache and sessions (Redis) | Encrypted persistent volumes (EBS+KMS, Azure Managed Disk, GCP CMEK) or transparent DB encryption. On EKS the default StorageClass sets `encrypted: "true"` (account `aws/ebs` key or a CMK via `kmsKeyId`). |
| At rest, secrets | Kubernetes secrets in etcd | Envelope encryption (one-flag on EKS/AKS/GKE, KMS configuration on self-managed clusters) |
On xpander cloud, all of the above uses cloud-provider managed keys with TLS terminated at xpander's ingress.
***
## Safety controls
Each control operates at the input/output boundary of a skill call. Toggle-on per agent; no separate moderation service.
* **PII detection** scans both inputs and outputs and can mask values before they reach the model or the downstream skill
* **Prompt injection blocking** inspects skill outputs for the patterns used to override system instructions through retrieved content (the "ignore previous instructions" class of attack)
* **Content moderation** filters unsafe categories in generated responses
* **Step limits** cap how many skill calls a single task can make, preventing runaway reasoning loops
* **Locked parameters** let you pin specific skill arguments (e.g., always use a specific account ID) so the model can't override them at runtime
***
## OWASP Top 10 mapping
| OWASP Top 10 (LLM) risk | Where xpander addresses it |
| - | - |
| Excessive agency | Operation-surface scoping per agent; approval holds on skill actions and gated commands ([Approvals](/use/approvals)) |
| Insecure output handling | PII masking, content moderation, schema-validated skill outputs |
| Sensitive information disclosure | Credentials never reach the model; deployment isolation; PII detection |
| Prompt injection | Built-in injection detection on skill outputs; isolated skill execution |
| Supply chain risks | Pinned chart and image versions; immutable deploy snapshots; version-controlled skill definitions |
| Unbounded consumption | Step limits, token budgets, per-agent cost ceilings |
For deeper context on how these controls fit into a governance program, see [enterprise AI governance for secure agentic automation](https://xpander.ai/resources/enterprise-ai-governance-for-secure-agentic-automation).
***
## Related
xpander cloud: planes, identity, and data handling
AWS network boundary, PrivateLink, and what leaves your VPC
Zero egress to xpander Cloud
RBAC, SSO, API keys, and audit logs
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.