Security Architecture

xpander enforces limits in the runtime (what each agent can do, its credentials and safety controls) and in where the runtime runs (networks it can reach, where data lives). The runtime controls below are the same in every deployment.

​

Three deployments

​

Permission model

An agent’s permissions are its operation surface, not its system prompt. A Jira agent built for PR triage cannot reach org-admin endpoints because those operations were never wired into its skill. A capability that does not exist cannot be jailbroken or coaxed out. This applies NIST Zero Trust Architecture at the agent’s operation surface rather than the network edge. Agents assembled on xpander carry 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 result, never the OAuth token, API key or IAM credentials. The skill relay in agent-controller and the execution tier attach credentials from Kubernetes secrets at call time, outside the agent loop. A compromised prompt cannot leak a credential the model never had. Provider keys sit in the AI Gateway, never with agents: on Platform > AI governance > Models, or on a self-hosted install in secrets.static (Model keys and Bedrock). A call to a provider with neither key is refused with a message that names the missing key.

​

Endpoints and key names

​

Encryption

On xpander cloud, all of the above uses cloud-provider managed keys, with TLS terminated at xpander’s ingress.

​

Safety controls

Each control runs at the input and output of a skill call, turned on per agent. There is no separate moderation service.

​

OWASP Top 10 mapping

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

​

Next steps