Security Architecture

Agents act on real systems, not just generate text. The relevant security question shifts from “what might the model say” to “what can the agent do, and under whose authority.” The OWASP Top 10 for LLM Applications risks (excessive agency, sensitive data exposure, prompt injection) only become real when AI gains the ability to act. xpander.ai enforces limits at two layers:

• Application layer: what each agent can do once running (operation surface, credentials, safety controls)
• Infrastructure layer: where agents run, what networks they can reach, where data lives

The platform runs in three editions. This page covers the design principles that hold in all of them; each edition 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 connector, not because a prompt tells the model “don’t call them.” A capability that doesn’t exist can’t be jailbroken, leaked through tool injection, or coaxed out by a clever user. This aligns with NIST Zero Trust Architecture (explicit verification, no implicit trust, least privilege by default), applied at the agent’s operation surface, not just the network edge. The platform’s specialized agents are how this is exposed: a connector with a narrow set of operations, a named owner, and an audit trail.

---

​

Credential isolation

The model sees a tool description ("create_lead", with these parameters) and the call result, but never the OAuth token, API key, or IAM session credentials in between. The AI Gateway and Agent Workers broker authentication outside the reasoning loop. An attacker who compromises a prompt or tool output cannot exfiltrate a credential the model never had. Credentials live as Kubernetes secrets and are read by the gateway and workers at invocation time. Supported patterns:

• OAuth 2.0 with auto-refresh, scoped at the connector level
• API keys and tokens stored as secrets, injected at invocation time
• AWS IAM roles via service accounts (IRSA), where tools assume per-connector roles. See IAM Best Practices.
• End-user delegated identity, where 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

The platform configures encryption at each layer; the substrate depends on the edition. In the Cloud edition, all of the above uses cloud-provider managed keys with TLS terminated at the platform’s ingress.

---

​

Safety controls

Each control operates at the input/output boundary of a tool 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 tool
• Prompt injection blocking inspects tool 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 tool calls a single task can make, preventing runaway reasoning loops
• Locked parameters let you pin specific tool arguments (e.g., always use a specific account ID) so the model can’t override them at runtime

These are application-layer controls. They complement, not replace, infrastructure isolation.

---

​

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