Two Sigma runs each employee's cloud agent with that employee's identity because separate machine identities create permission, licensing, data-access, and boundary problems.
2
A propagated header distinguishes human actions from agent actions and preserves the chain of steps that produced a result.
3
The firm routes web search and fetch through Google's Web Grounding for Enterprise inside its network, accepting stale results to reduce exfiltration and prompt-injection risk.
Summary
Shu Fang describes how Two Sigma gives every employee a remote cloud agent that runs as the employee, rather than creating a separate agent identity. A separate identity quickly creates problems with permissions, software licenses, systems that reject multiple identities, and ownership boundaries. Two Sigma already had Kubernetes namespaces for each person in every region, with a sidecar mounting the person's identity into the pod. Fang focuses on two risks. A shared identity makes human and agent actions difficult to distinguish, while open web access can expose sensitive data, admit prompt injection, and create licensing problems. The firm propagates an agent header alongside the user's identity, allowing actions to be attributed and replayed through the full chain. For web access, it uses Google's Web Grounding for Enterprise and blocks native search and fetch tools. The index can be up to 24 hours old, but Fang says the reduction in risk is worth the loss of freshness.
A separate agent identity creates operational problems quickly
The usual design gives each person a machine identity for their agent, such as a Shu identity and a Shu agent identity. Fang says this breaks down because permissions are hard to keep synchronized. Software licensing may need to be paid for twice. Some systems, including Google Workspace and email, do not support two identities interacting with the same underlying data. The team would also have to manage the boundary between the person's identity and the agent's identity. Running the agent as the user removes these constraints because the agent has the same access and capabilities as the person.
Existing Kubernetes namespaces made remote agents practical
Two Sigma already had a Kubernetes namespace for every employee in every region. The namespaces were created for automated jobs that could not stay on a local machine, along with code containers and research notebooks. A controller receives a request for compute resources, and a sidecar retrieves the employee's identity from a separate identity service. The sidecar mounts that identity into the pod, so the container runs as the employee. Fang's point is that the firm did not need to invent a new platform for agents. It reused infrastructure that already supported user-owned remote workloads.
A shared identity requires a second signal for attribution
When the human and the agent use the same identity, ordinary identity logs cannot show who took an action. Fang says the firm needs to audit, block, and trace actions while distinguishing a human operation from an agent operation. Two Sigma addresses this with a header that agents append throughout a request chain. Fang compares it with a trace ID propagated through distributed systems. Agent clients, MCPs, skills, harnesses, and frameworks can populate and preserve the header. The user's real identity remains attached to the request, while the header identifies the agent path.
The header preserves provenance beyond the immediate actor
The attribution mechanism does more than identify whether an agent acted. It lets the firm recover the full provenance of a result across multiple steps. Fang says the team can replay the chain of actions that led to an end result. With a separate Shu agent identity, the firm might know only that the agent started a flow and would lose the later links back to its origin. The propagated header carries that origin through the system. Fang compares the mechanism to trace IDs, but the additional control over agent harnesses and frameworks lets the firm enforce propagation.
Open web access combines several risks for a regulated firm
Fang says current models need external web access because they cannot update their knowledge from live data on their own. Search and fetch tools therefore become core agent capabilities. They also create several risks at once. Sensitive information could be exfiltrated, untrusted content could return to the model and cause prompt injection, and malware or other vulnerabilities could enter through web content. Two Sigma also has to avoid using licensed material without the required rights. Fang calls this combination the firm's biggest fear when agents run with a user's full identity.
Two Sigma trades web freshness for a smaller exposure
Two Sigma uses Google's Web Grounding for Enterprise to provide search and fetch within its existing network boundary. Fang describes it as a web index that can be reached inside the firm's VPC and network controls. The tradeoff is freshness. He says the index was fresh within 24 hours, or within 6 hours for more regularly updated websites, based on the information available to him. The firm judged that delay acceptable for most agent use cases because it removes the need for direct external egress. Fang says the risk dropped much further than the value did.
Blocking native tools forces agents through the controlled path
Using the controlled index requires more than telling an agent to prefer it. Two Sigma blocks the native web search and web fetch tools provided by agent harnesses and frameworks. The tools are removed from the agent's available set, so requests cannot simply route around the approved service. When an agent needs web access, it goes through the firm's supported MCP, CLI, client code, or skills and reaches the Web Grounding cache index. Fang presents this as an application of existing controls rather than a new security mechanism.
The firm deployed a managed cloud-agent fleet for every employee
Two Sigma shipped a framework that runs cloud agents as user identities behind the attribution and web-access controls. Employees can interact with the agents through remote interfaces, including options for people who are not comfortable with a CLI. The firm also deployed a managed fleet of cloud agents for every user, so the available capabilities can be improved centrally. Each employee already has the infrastructure needed to build and deploy an agent into their namespace with their identity. Larger shared agents still go through ordinary production support and security review, like other applications.
