Known issues and hardening
Known security properties of a self-hosted deployment, how serious each is, what causes it, and how to resolve it.
How to read the findings
Severity is assessed for a deployment where the setting or environment that causes the finding is in place.
| Severity | Meaning |
|---|---|
| High | Exposure of your data or loss of service without further preconditions |
| Medium | Requires an additional condition or has limited impact |
| Low | Hardening or disclosure |
| Not rated | Pending review |
| Cause | Meaning |
|---|---|
| Configuration * | A setting causes the finding, and an existing setting resolves it |
| Environment * | An object or permission in your environment that the Context release does not create |
| Product | A product change is required |
| Product and environment * | A product change and a change in your environment are both needed |
Findings marked * can be resolved without a product change. Findings caused by a setting apply only while that setting is at the value shown; the setting’s product default is in the configuration reference.
Environment findings
Findings S-01 to S-18 concern the deployment, its network and its infrastructure.
| ID | Finding | Severity | Cause | Remediation |
|---|---|---|---|---|
| S-01 | With the egress setting at Open internet, sandboxes can reach the public internet directly on any port | High | Configuration * | Set Sandbox Egress Posture to Domain allowlist (or Workspace only), then replace pooled sandboxes so they pick up the change |
| S-02 | With the egress setting at Open internet, the egress proxy’s forwarding route forwards any destination without a check | High | Configuration * | As S-01; closed with S-01 |
| S-11 | When Allowed Sign-Up Email Domain is *, sign-up is open to any email address; a new account receives an organization and an assistant on your model gateway, or joins a mapped organization (P-08) | High | Configuration * | Limit Allowed Sign-Up Email Domain to your domains, require email verification or an invitation, or use single sign-on only |
| S-14 | Sandbox identity and the denial of private networks depend on network policy enforcement in the cluster | High until confirmed | Environment * | Confirm network policy enforcement and address-spoofing protection in your cluster |
| S-17 | When Show Organization Infrastructure Page is on, any organization owner or admin, in any organization, can delete every sandbox in the deployment (P-09) | High with S-11 | Configuration * | Turn off Show Organization Infrastructure Page |
| S-03 | Sandboxes can reach the private upstream ranges, and Pods in the same namespace, on port 443 through the proxy’s forwarding route | Medium; depends on the contents of the range | Configuration * | As S-01; limit the sandbox private upstream CIDRs (advanced) setting to the model gateway |
| S-04 | With Allow All Private Connector Targets on and the connector network policy off, the connectors service may call any public address and any address in the private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10), and its outbound traffic is not limited by NetworkPolicy | Medium | Configuration * | Limit connector targets to your MCP servers (Connector Target URL Allowlist); turn on Enable Connector Egress NetworkPolicy |
| S-06 | In release 1.1.2994, one log-shipping token serves the whole deployment and can be used from your network; log labels are supplied by the caller; the bundled Loki does not authenticate | Medium | Product | Per-sandbox token with server-set labels (product change). Until then, restrict load balancer source ranges (Allowed Source CIDRs). |
| S-09 | Sandboxes do not use a hardened runtime class (they share the node kernel) | Medium | Product and environment * | Expose the runtime class in the installer (product change); provide gVisor or Kata on nodes (your team) |
| S-12 | The default ServiceAccount in the application namespace carries the application IAM role | Medium | Environment * | Remove the role annotation |
| S-18 | The sandbox controller holds cluster-wide permission to create, change and delete Pods | Medium | Product | Scope the controller to the sandbox namespace (product change) |
| S-05 | With Deny internal-only paths at the edge off, the boot token can be used from your network to read the sandbox start-up configuration | Low | Configuration * | Turn on Deny internal-only paths at the edge |
| S-07 | In release 1.1.2994, application metrics are served without authentication when observability is on | Low | Product | Upgrade to a release that includes the change: metrics move to a private port that no Service or edge route exposes, and the main port requires a token |
| S-08 | A revoked sandbox identity can be honored for up to 2 seconds (10 at most) | Low | Product | Clear identity caches on revocation (product change) |
| S-10 | The telemetry gateway and cluster DNS are reachable from sandboxes without authentication | Low | Product and environment * | Authenticate the telemetry gateway (product change); limit DNS recursion (your team) |
| S-15 | An internal load balancer with no WAF and no source address restriction | Low; revisit with S-11 | Configuration * | Restrict Allowed Source CIDRs; add a WAF |
| S-16 | When Composio API Key is set, connector requests may be sent to a third party outside your network | Low (disclosure) | Configuration * | Confirm use and approval; remove the key if unused |
| S-13 | An application IAM role policy that contains a wildcard action | Not rated; pending review of the policy | Environment * | Scope the policy to required actions |
Permissions findings
Findings P-01 to P-09 concern who can do what inside the platform (see Permissions reference).
| ID | Finding | Severity | Cause | Remediation |
|---|---|---|---|---|
| P-01 | Any workspace member, or any organization member through an organization-level task, can run another person’s personal assistant. The run has that person’s file permissions, including their private drive; its approval requests go to the person who started it. | High | Configuration * | Turn on the restriction on running another person’s assistant, which limits running a personal assistant to people with explicit rights to it. It covers personal assistants only; organization owners remain able to run them. Test it before you turn it on. |
| P-02 | Agents owned by an organization admin receive the admin’s organization-wide file access | High; Medium once P-01 is closed | Product | Limit agent file delegation to permissions granted directly to the owner (product change) |
| P-08 | Open sign-up: anyone who can reach the application can create an account; depending on domain mapping and fallback settings, a new account joins your organization as a member, possibly without email verification | High | Configuration * | Limit Allowed Sign-Up Email Domain to your domains, require email verification or an invitation, or use single sign-on only |
| P-09 | Any organization owner or admin, in any organization, can view deployment sandbox state and delete every sandbox in the deployment, interrupting all running tasks | High with P-08 | Configuration * | Turn off Show Organization Infrastructure Page |
| P-03 | Organization admins and owners have standing access to every workspace, including private and personal workspaces | Medium | Configuration * | Turn on the private-workspace restriction for organization admins, or adopt standing access as your policy |
| P-04 | Any organization member can edit, archive or change the visibility of any organization-visible skill | Medium | Product | Limit editing to skill owners and editors (product change); until then, deny rules per person |
| P-05 | New agents use the Full preset, which asks for nothing; there is no organization-wide policy | Medium | Configuration * and product | Set your agents to Supervised or Connectors. An organization-wide policy layer requires a product change. |
| P-06 | Workspace admins can reconfigure or delete members’ assistants in their workspace | Low | Product | Product decision |
| P-07 | Agents can be given admin or owner roles, in a workspace or the organization, and can then manage members | Low | Configuration * | Turn on the agent role restrictions |
Status of product changes
Status of each finding that needs a product change, in releases after 1.1.2994.
| ID | Status |
|---|---|
| S-06 | Partly fixed in releases after 1.1.2994: each sandbox gets its own log token bound to its run, and the log gateway sets the labels itself. The bundled Loki still does not authenticate; it is reachable only through its NetworkPolicy. |
| S-07 | Fixed in releases after 1.1.2994: metrics are served on a separate port that no Service or edge route exposes, and the main port requires a scrape token or a superadmin session. |
| S-08 | Open: revocation does not clear the identity cache. |
| S-09 | Open in the installer: the runtime class can be set in the Helm chart (agentSandbox.runtimeClassName) but not in the installer. You still provide gVisor or Kata on nodes. |
| S-10 | Open |
| S-18 | Open: the sandbox controller is still granted Pod permissions cluster-wide. |
| P-02 | Fixed only for organizations on Permissions v4 (OpenFGA) (off by default): an agent checks as itself and does not receive its owner’s file access. Open for organizations on the legacy engine. |
| P-04 | Fixed only for organizations on Permissions v4: editing an organization-visible skill requires edit rights on the skill. On the legacy engine, an admin can withdraw Manage skills from the Member role as a workaround. |
| P-05 | Open: there is still no organization-wide policy layer. Full remains the default preset for new agents. |
| P-06 | Changed only for organizations on Permissions v4: configuring and deleting an agent is limited to its sponsor and organization admins. Open for organizations on the legacy engine. |