Security Architecture

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:

---

​

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: explicit verification, no implicit trust, least privilege, applied at the agent’s operation surface rather than the network edge. Agents assembled on xpander 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.
• 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 for the canonical setup.

---

​

Encryption

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

For deeper context on how these controls fit into a governance program, see enterprise AI governance for secure agentic automation.

---

​

Related