Security architecture
How the Context platform is deployed and secured in a self-hosted production environment, and who owns each part of it.
Scope
These pages describe how the Context platform is deployed and secured in a self-hosted production environment. They cover the components Context supplies in three Kubernetes namespaces of your Amazon EKS cluster, and how those components interact with the AWS services you manage, your model gateway and third parties. The reference architecture is an AWS installation (Amazon EKS, Amazon RDS, Amazon S3, IAM and AWS KMS).
Where a statement depends on an installer or platform setting, the page names the setting. Every setting’s options and product default are in the configuration reference. Statements marked * depend on configuration or environment and can be changed without a product change (see How to read the diagrams).
Out of scope: your own controls in your AWS account (described only where they affect Context), Context Code on user machines, and Context’s access to the environment for support, which is covered separately (see What your team decides).
The security pages are:
| Page | What it covers |
|---|---|
| Network boundaries | Deployment boundaries, every network path out of a sandbox, inbound sandbox ports |
| Agent sandbox | Sandbox lifecycle, sandbox identity, what runs inside a sandbox |
| Request trace | One prompt followed through every check |
| Credential handling | How credentials are applied to sandbox requests, and what a sandbox can read |
| Data at rest | Where data is stored and which component reads it |
| Agent threats and controls | Threat model mapped to the OWASP Top 10 for LLM Applications |
| Permissions reference | Principals, roles, the roles matrix, agents, approvals, administrator access, sign-up |
| Known issues and hardening | Security properties that depend on configuration, and their remediations |
| What your team decides | Decisions to settle before and after installation |
| Configuration reference | Installer and platform settings named on these pages |
| Glossary | Terms used on these pages |
Responsibilities
| Area | Your organization | Context |
|---|---|---|
| AWS account, VPC, subnets, load balancer, outbound path | Owns and operates | States requirements |
| Amazon EKS cluster, nodes, kube-system, network policy enforcement | Owns and operates | Supplies NetworkPolicies with the release |
| Amazon RDS, Amazon S3, AWS KMS: encryption, backups, retention | Owns and configures | Uses them through IAM roles for service accounts |
| IAM role policies used by Context workloads | Owns | Specifies required permissions |
| Model gateway (LiteLLM) and model provider agreements | Owns and operates | Sends model requests to it, through the egress proxy when Sandbox Workload Identity is on |
| Context components, sandbox isolation, authorization, release contents | Approves installation | Builds, ships and supports |
| Installer configuration values | Set during installation and upgrades; see the configuration reference |
How to read the diagrams
The diagrams on these pages use the following notation.
| Notation | Meaning |
|---|---|
| Service box | A Context service (Kubernetes Deployment). “Application Pods” marks a function of the application tier rather than a separate service. |
| Box inside the sandbox Pod | A process or container inside a sandbox Pod. |
| AWS service | An AWS service in your account. |
| External box | Your internal systems; your model gateway; a system reached over the internet. |
| Outer groups | AWS account, Region, VPC and private subnets; the Amazon EKS cluster; a Kubernetes namespace. |
| Sandbox network policy | The sandbox NetworkPolicy. |
| Sandbox Pod (untrusted) | A sandbox Pod, treated as untrusted: anything inside may be influenced by content the agent reads. |
| Group outside Context’s namespaces | Systems you operate, or third parties. |
| Solid arrow | A request, labeled with what it carries. |
| Dashed arrow | An answer, or a fallback path. |
Arrow ending in x | A refused connection; the label states why. |
| Label marked * | A path that is open because of configuration. |
| Dotted arrow | A connection the network policy allows but the platform does not use. |
| ◆ | Enforcement point, where the Context application tier decides. |
| ◇ | Check inside the sandbox, which guides the agent but is not a security boundary. |
| ⊘ | No check. |
| ✕ | Denied by NetworkPolicy. |
| * | Caused by configuration or environment rather than by the platform’s design; resolvable without a product change (Known issues and hardening). |
System context
Your users reach the Context platform through an internal load balancer. The platform calls your model gateway for model requests, AWS services you manage for storage and identity, your systems through connectors, and a small set of third parties.
flowchart LR users["Your users<br/>browser, Context Code"] -->|HTTPS| alb["Application Load Balancer<br/>internal"] subgraph acct["Your AWS account"] alb --> ctx["Context platform<br/>Amazon EKS, three namespaces"] ctx -->|data, identity| aws["AWS services<br/>Amazon RDS, Amazon S3, IAM, AWS KMS"] end ctx -->|application credentials| tp["Third-party APIs<br/>Parallel, Composio, Box"] ctx -->|"sandbox egress (S-01) *"| inet["Public internet<br/>any destination *"] ctx -->|connector calls| sys["Your systems<br/>MCP servers, any address (S-04) *"] ctx -->|model requests| gw["Model gateway<br/>LiteLLM, operated by you"] gw -->|model calls| prov["Model providers<br/>for example Amazon Bedrock and OpenAI models"]- Models (for example Amazon Bedrock and OpenAI models) are served through your LiteLLM model gateway; which provider hosts each model is set in your gateway. The model configurations the deployment offers are set in the installer (see Model gateway settings). With Sandbox Workload Identity on, sandboxes reach the gateway through the egress proxy; with it off (the default), they call it directly with the gateway key they hold. The application tier also calls it directly, with its own key, for reports, dictation, embeddings and follow-up suggestions.
- The application tier calls Parallel (web search), Composio (connector actions) and Box (file integration) with credentials it holds. Composio is in the path only when a Composio key is configured (S-16). Media generation uses a media provider key (fal.ai) when one is configured.
- Connectors can reach your systems that expose MCP servers. The connector target settings decide which addresses are permitted; permitting every private address range and any public address is finding S-04 *.
- Sign-up can be open to any email address, depending on the sign-up settings (S-11 *). For sign-in methods, see Sign-in options.
- Releases are distributed through Replicated and installed with KOTS. The installer and image pulls reach Replicated; the application does not call it.
Components
flowchart LR subgraph ns["Release namespace (context-vpc)"] edge["Edge router (Traefik)<br/>ingress"] --> app["Application tier<br/>Deployment, 3 to 24 replicas<br/>API; authorization and approvals;<br/>identity broker 3443; connectors gateway ◆;<br/>egress authorizer 3444 ◆; drive authorization ◆"] app -->|start run| wf["Workflow service<br/>Temporal"] wf --> worker["Temporal worker<br/>Deployment"] worker -->|deliver prompt| pod subgraph np["Sandbox network policy"] pod["Sandbox Pod<br/>harness, tools (bash, CLIs), identity sidecar"] end pod -->|API, connector calls| app pod --> drive["Drive gateway<br/>Caddy"] pod --> egress["Egress proxy<br/>Envoy"] drive -->|authorize each request| app egress -->|authorize each request| app app -->|per-request token| conn["Connectors service<br/>Deployment"] sup["Supporting services<br/>Streaming (Phoenix), Messages (NATS),<br/>Documents (OnlyOffice), Analytics (ClickHouse)"] end app -->|SQL| rds["Amazon RDS for PostgreSQL"] drive -->|file bytes| s3["Amazon S3"] egress -->|model calls| gw["Model gateway (LiteLLM)"] conn -->|MCP calls| mcp["Your MCP servers<br/>any address *"]| Component | Kind | Role |
|---|---|---|
| Edge router (Traefik) | Deployment | Ingress for the application |
| Application tier | Deployment, 3 to 24 replicas by default | API, authorization and approvals, identity broker (port 3443), connectors gateway ◆, egress authorizer (port 3444) ◆, drive authorization ◆ |
| Workflow service (Temporal) and Temporal worker | Deployments | Start runs, claim sandboxes, deliver prompts |
| Sandbox Pod | One per task run | Harness, tools (bash, CLIs) and identity sidecar, inside the sandbox network policy |
| Drive gateway (Caddy) | Deployment | Carries file bytes between sandboxes and Amazon S3 |
| Egress proxy (Envoy) | Deployment, only with Sandbox Workload Identity or Sandbox Egress Proxy (domain allowlist) on | With identity on, carries model calls to the model gateway; with the domain allowlist, limits outbound destinations |
| Connectors service | Deployment | Makes MCP calls to connector targets |
| Supporting services | Deployments | Streaming (Phoenix), Messages (NATS), Documents (OnlyOffice), Analytics (ClickHouse) |
| Sandbox controller | Deployment in its own namespace | Creates and removes sandbox Pods |
| Observability stack | Optional, in its own namespace | Loki, Tempo, Alloy, Grafana, Prometheus, Alertmanager |
- The application tier serves the product API and makes every authorization decision for requests that start in a sandbox: API calls, connector tool calls (through its connectors gateway), drive requests and model requests. It also connects to MCP servers when a connector is registered, to refresh its tools and to renew OAuth tokens. It runs 3 to 24 replicas by default (Workspace Min Replicas and Workspace Max Replicas).
- Temporal and its workers orchestrate task runs: they claim or create a sandbox, establish its identity, deliver prompts and tear the sandbox down. The streaming service relays the agent’s live output to the browser.
- Two proxies sit between sandboxes and other services: the egress proxy (Envoy) handles outbound traffic and, with Sandbox Workload Identity on, adds model credentials; the drive gateway (Caddy) carries file transfers. The egress proxy is deployed only with Sandbox Workload Identity or Sandbox Egress Proxy (domain allowlist) on, both off by default; without it, sandboxes call the model gateway directly. The connectors service sits behind the application tier: it runs only connector calls that the application tier’s connectors gateway has authorized, and accepts only tokens that gateway issues for each call. With identity on, the egress proxy asks the application tier’s egress authorizer (port 3444) before every model request, and the drive gateway asks it before every file transfer. Sandboxes do not call it directly.
- The sandbox controller creates and removes sandbox Pods. It holds cluster-wide permission to create, change and delete Pods (S-18).
- OnlyOffice provides document editing. ClickHouse stores analytics data and uses the shared application IAM role.