How the SecurSpaces proxy service works
Most of the security claims in this documentation resolve to one component. Credentials do not reach the developer’s machine because the SecurSpaces proxy service holds them. Egress is restricted because the proxy service filters it. AI spend is attributable because the proxy service labels it. Repository access is auditable because the proxy service sees it.
This page explains what that component does. There is nothing to configure on it — the proxy service is not optional and has no settings of its own. What you configure is network policy, project resources, and AI routing, each documented separately.
Why everything passes through it
A Citrix SecurSpaces™ workspace has no direct route to anything. It cannot reach the internet, your repositories, or your internal systems on its own; every connection it opens terminates in the proxy service first.
That single property is what makes the other controls enforceable rather than advisory. A policy a workspace could bypass would be a recommendation. Because there is no path around the proxy service, a developer with full control of their own workspace — including root in a container they built — still cannot reach a destination policy forbids, and still cannot read the credentials their tools are using.
What passes through it
| Traffic | What the proxy service does |
|---|---|
| HTTP and HTTPS | Applies network policy, brokers credentials for repositories and services, and records the request |
| Git over HTTP, including Git LFS | Routes repository traffic so that access uses platform-held credentials and follows policy |
| DNS | Resolves names for the workspace, including the internal names used to reach workspace applications |
| TCP and UDP | Carries traffic for services that are not HTTP |
| SSH | Carries outbound SSH, when an administrator has enabled it and a method is configured for the target host |
Credentials are held, not handed over
When a workspace reaches a repository or an external service, it does not present a credential, because it does not have one. It addresses the destination by an identifier the platform assigns, and the proxy service resolves that to the real endpoint and attaches the credential on the way through.
The practical consequences are worth stating plainly:
- Nothing long-lived is written to the developer’s machine, whichever IDE or connection method they use.
- Nothing readable is written inside the workspace either, so a compromised workspace does not yield a usable credential.
- Revoking access at the platform takes effect on the next request, without touching any endpoint or workspace.
Policy is applied here
Network policies attached at platform, organization, and project level are combined, and the result is applied to every connection. A destination that no policy allows is refused.
Policies are evaluated against both the address and the domain, which is why an allow list works even when a destination resolves to a changing set of addresses. For how policies are written and assigned, see Network policies.
How HTTPS connections are handled
An HTTPS connection out of a workspace is two connections. The proxy service terminates the one from the workspace, reads the request, decides what to do with it, then opens its own connection to the destination and forwards the request there.
This is what makes the rest of the platform’s controls possible on encrypted traffic:
| The proxy service can | Because it reads the request |
|---|---|
| Apply policy to a domain rather than only an IP address | The destination is in the request, not only in the TLS handshake |
| Attach a repository or service credential | The credential is added to a request the workspace never sees |
| Attribute AI usage to a user, project, and workspace | Identifying headers are added before the request is forwarded |
| Route provider traffic to an AI gateway | The destination is matched against the configured endpoints |
None of that is possible while the connection is opaque to the platform.
What the workspace trusts
Because the proxy service presents its own certificate to the workspace, the workspace has to trust the certificate authority that issued it. SecurSpaces adds its service CA certificate to the workspace’s trust stores at start, which is why HTTPS tools inside a workspace work without per-tool configuration.
A consequence worth knowing: a tool that pins a certificate, or that uses its own trust store rather than the system one, may reject the connection. Some language runtimes and package managers do this. See Container image requirements.
Where decryption happens
Decryption happens inside the deployment you host, on the proxy service pods, and the request is re-encrypted before it leaves for the destination. Traffic is not sent to Citrix, and it is not decrypted anywhere outside your cluster. In SecurSpaces Flex the same is true of the Citrix-managed environment your organization is allocated.
Note:
Inspect also names a specific network policy behavior, which reports on TCP content and is applied through the built-in Inspect Traffic policy. That is a separate, optional setting. The handling described here applies to HTTPS whenever a SecurSpaces network policy is attached, whichever behavior the policy uses. See Network policies.
How SSH connections are handled
SSH is handled the same way structurally — an SSH connection out of a workspace is also two connections rather than one tunnel — with one important difference. The proxy service does not read the contents of an SSH session. It terminates the transport, decides whether the connection is allowed, and presents the right credential, but what passes through afterwards is not examined.
A workspace opens an SSH connection to the proxy service rather than to the destination. The proxy service authenticates the workspace, applies the SecurSpaces network policy to the destination, then opens a separate connection onward and authenticates to the destination itself.
The credential it presents is the developer’s personal SSH identity, which the platform holds. It is read from the secret manager at the moment the connection is made and used to sign the handshake; it is not written into the workspace, so a process inside the workspace cannot copy it.
Note:
Inbound SSH — a developer connecting from a local IDE into their workspace — is terminated by the workspace service rather than the proxy service. That connection is authenticated against the developer’s registered public key, and the session is recorded. The proxy service governs traffic leaving a workspace.
What this means for an assessment:
- A workspace cannot open an SSH connection to a destination the SecurSpaces network policy does not allow.
- The private key used toward external systems is never in the workspace.
- Session contents are not decrypted or logged. Commands typed in an SSH session are not recorded by the proxy service, so SSH does not provide the request-level visibility that HTTPS does.
What it does not do
- It is not your organization’s own outbound proxy. If your organization requires outbound traffic to pass through an existing proxy of your own, that is configured separately and sits downstream. See External proxy configuration.
- It is not a web application firewall. It governs where a workspace may connect and what identity is used, not the content of application payloads.
- It does not inspect SSH session contents. See How SSH connections are handled.
- It does not govern Model Context Protocol traffic. See AI Gateway.