Tethered: Our Agents Are Us — Shu Fang, Two Sigma

Read the talk

Tethered: Our Agents Are Us

In a personal account of work completed the previous year, Shu Fang explains how Two Sigma ran remote cloud agents as employees themselves, then restored accountability with propagated provenance and constrained web access to an enterprise-controlled search path.

From a talk by Shu Fang

At a glance

Ideas worth remembering

  • A separate per-user agent identity creates permission drift, duplicate licensing, incompatible access patterns, and a boundary that must be maintained indefinitely.

  • Existing per-user Kubernetes namespaces can host remote agents under employee identities, with a sidecar obtaining and mounting identity material from a separate service.

  • Authentication establishes who is acting; a propagated agent marker records whether an agent initiated the work and preserves provenance through downstream spans.

  • Safe routing requires both an approved web source and denial of native search and fetch tools, so the model cannot bypass the controlled path.

  • In the implementation Fang described, a controlled index reduced external-egress and prompt-injection exposure but traded away freshness and could not guarantee that hostile content would never pass curation.

  • Personal agents can be self-service because infrastructure is pre-provisioned; broader deployment still requires ordinary production support and security review.

Remote agents force an identity decision

Shu Fang opens with two pieces of context: Two Sigma is 25 years old and operates in a regulated industry, and his account reflects his own views rather than an official company endorsement. Even in that setting, he says, every employee gained access to a cloud agent running under the employee’s own identity. The work described began around June 2025 and had been completed during the year before this talk.

Fang calls these agents “tethered,” borrowing the doubles from the film Us. The metaphor captures the design problem: a double is useful while its behavior remains attached to its human, but dangerous when it can run loose without constraints or accountability.

The project started with a usability problem. Local coding agents were powerful but tied to a command line and a particular computer. The goal was to make remote agents reachable from mobile devices, Slack, and browsers—including by employees who would not be comfortable operating entirely inside a CLI. Moving execution into the cloud broadened access, but immediately raised the question: whose identity should the remote agent use?

0:521:17
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:13 · section reference included

Why “Shu” plus “Shu agent” became the wrong boundary

The conventional answer is to give each agent a separate machine identity associated with its human owner: one identity for Shu, another for Shu’s agent. That looks like clean separation until the two identities must do the same work against the same systems.

Recording frame at 195 secondsOpen full source frame
Recording frame at 195 seconds

The separate identity creates several parallel maintenance problems:

  • Permission drift: Every change to the human’s access must be reflected in the agent account.
  • Duplicate licensing: Software licensed per identity may require a second license.
  • Shared-data incompatibility: Some systems do not support two identities operating on the same underlying user data, including email and other workspace data.
  • A new policy boundary: Systems may reject the machine identity outright, while security teams must repeatedly decide what belongs on each side of the human–agent boundary.

Running the agent as the user removes those synchronization problems. The agent receives the capabilities and access the employee already has instead of depending on a parallel account that must continually imitate them. This simplifies authorization, but it also deliberately collapses the identity-level distinction between human and agent. The rest of the architecture must restore that distinction somewhere else.

The necessary infrastructure already existed for ordinary automation. Two Sigma had Kubernetes clusters across regions, with a namespace for each person in every region. Automated jobs, code containers, and research notebooks already needed remote compute that could act as the user instead of being confined to a laptop.

How does a remote agent start with its user’s identity? A trigger asks a controller to create compute in the employee’s namespace. A sidecar in the resulting pod obtains identity material from a separate identity service and mounts it for the working container. The container therefore executes remotely while retaining the employee’s established identity.

How a remote agent starts as its user

Remote triggerrequest — A request arrives from an interface and asks for compute.
Controllercontrol — Creates compute resources for the request.
User namespaceruntime — A namespace already exists for each user in each region.
Identity serviceidentity — Supplies the user identity for the workload.
Identity sidecaridentity — Retrieves and mounts identity material for the pod.
Agent containerruntime — Runs remotely with the employee’s capabilities and access.
Existing per-user Kubernetes infrastructure supplies compute placement and a user-specific runtime boundary; a separate identity service lets the workload act with the employee’s identity.
Read the diagram as text
  • Remote trigger. request — A request arrives from an interface and asks for compute.
  • Controller. control — Creates compute resources for the request.
  • User namespace. runtime — A namespace already exists for each user in each region.
  • Identity service. identity — Supplies the user identity for the workload.
  • Identity sidecar. identity — Retrieves and mounts identity material for the pod.
  • Agent container. runtime — Runs remotely with the employee’s capabilities and access.
  • Remote trigger → Controller: requests compute.
  • Controller → User namespace: starts pod.
  • Identity service → Identity sidecar: provides identity.
  • Identity sidecar → Agent container: mounts identity.
  • User namespace → Agent container: hosts workload.
2:553:25
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:55 · section reference included

The identity shortcut creates two serious dangers

The first danger is internal attribution. Because the person and agent authenticate as the same actor, ordinary identity logs cannot answer whether a human clicked, typed, or called something directly, or whether an agent initiated the action. That distinction matters when a company needs to audit an action, block agent-specific behavior, or reconstruct what happened.

Recording frame at 383 secondsOpen full source frame
Recording frame at 383 seconds

The second danger is web access. Models contain point-in-time knowledge, so useful agents often need search and fetch tools for current information. Unrestricted internet access, however, creates several risks at once:

  • Exfiltration: Sensitive information or intellectual property can leave the company.
  • Hostile input: Untrusted pages can return prompt injections, malware, or exploit content.
  • Licensing exposure: The agent may retrieve and use material without appropriate rights.

Fang frames the design as a finance problem: preserve the return from agents acting with full user capabilities while reducing the associated risk. That yields two concrete controls to build—provenance that separates human and agent activity, and a constrained route for web access.

5:075:37
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:07 · section reference included

A propagated header records more than the actor

Two Sigma’s implementation restores attribution with a header propagated through agent activity much like a distributed trace ID. Agent-controlled HTTP clients, MCP connections, skills, and harness code populate the header and continue carrying it through subsequent calls. Deterministic infrastructure surrounding the model preserves the metadata even though the model’s decisions are nondeterministic.

How does that marker preserve the origin of a multistep result? Consider a remote request that enters through Slack and causes an agent to call several internal services. The authenticated actor remains the employee throughout. At each hop, the agent marker joins the internal span: the first call records that an agent initiated the work, downstream calls inherit the marker, and the final result can be traced back through the chain. The observable change is larger than a label saying “an agent did this”; the record now contains the route that led to the outcome.

A separate “Shu agent” account would identify the initial machine actor, but identity alone would not necessarily preserve the complete causal chain through later systems. Propagated metadata supplies provenance across the sequence while the underlying authorization still belongs to Shu. Actor identity and execution origin become separate, complementary facts.

How agent provenance survives a multi-service call chain

Employee requestorigin — The user initiates work through a remote interface.
Agent runtimeorigin — Populates the provenance marker while acting as the employee.
First servicetrace — Receives the user identity and agent marker.
Downstream servicetrace — Carries the marker into an internal span.
Result with provenanceoutcome — The action chain can be reconstructed back to its origin.
The employee identity authorizes each call, while agent metadata propagates through the trace so the initiating path remains reconstructable.
Read the diagram as text
  • Employee request. origin — The user initiates work through a remote interface.
  • Agent runtime. origin — Populates the provenance marker while acting as the employee.
  • First service. trace — Receives the user identity and agent marker.
  • Downstream service. trace — Carries the marker into an internal span.
  • Result with provenance. outcome — The action chain can be reconstructed back to its origin.
  • Employee request → Agent runtime: delegates work.
  • Agent runtime → First service: identity + marker.
  • First service → Downstream service: propagates marker.
  • Downstream service → Result with provenance: records causal chain.
7:548:24
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:54 · section reference included

Replace open egress with one controlled web path

For web access, Fang says the system used Web Grounding for Enterprise, described in the talk as access to Google’s web index from inside the company’s existing VPC and network controls. It mirrored the two capabilities agents needed—search and fetch—without letting the agent contact arbitrary external sites directly.

Recording frame at 630 secondsOpen full source frame
Recording frame at 630 seconds

The tradeoff was freshness. Fang said that, the last time he checked, indexed data was available within roughly 24 hours and more frequently updated sites within roughly six hours. Those figures are explicitly time-bound observations from the described implementation, not permanent service guarantees. For the use cases under discussion, he considered the delay acceptable in exchange for removing direct external egress.

Providing the safer tool is insufficient if the original tools remain available. The harness therefore denied its native web-search and web-fetch tools, removing them from the agent’s usable tool suite. Requests that needed web information were redirected through supported MCP, CLI, client-code, or skill paths into the controlled index. This was a routing rule enforced outside the model, rather than an instruction asking the model to remember the preferred route.

What route remains after the native tools are denied? The agent has one permitted path to web-derived information and no native bypass. Search and fetch remain useful capabilities, but their network path changes from arbitrary internet egress to an indexed service operating inside the controlled boundary.

The controlled index also applied curation and other safety controls that Fang said reduced prompt-injection risk. It did not eliminate that risk: he explicitly allowed that curation could fail. Keeping retrieval internal primarily reduces exposure and gives the enterprise a controlled inspection point; it does not make hostile content inherently trustworthy.

In Fang’s assessment, these controls moved the risk–return position without removing the core capability. The index lagged the open web, but the provenance marker supplied more observability than identity alone, and web access no longer required unrestricted egress. His conclusion was that the risk fell much further than the expected value did.

Open web access versus the tethered route

Cloud agentagent — Runs as the employee and needs current information.
Native search and fetchblocked — Direct web tools are denied and removed from the available suite.
Open internetblocked — Direct access creates exfiltration and hostile-input exposure.
Supported MCP, CLI, client, or skillallowed — Routes requests through an approved interface.
Enterprise web indexallowed — Provides search and fetch inside existing network controls.
Controlled web resultallowed — Returns indexed information without arbitrary external egress.
Denying native tools closes the bypass; supported clients direct search and fetch through the enterprise-controlled index.
Read the diagram as text
  • Cloud agent. agent — Runs as the employee and needs current information.
  • Native search and fetch. blocked — Direct web tools are denied and removed from the available suite.
  • Open internet. blocked — Direct access creates exfiltration and hostile-input exposure.
  • Supported MCP, CLI, client, or skill. allowed — Routes requests through an approved interface.
  • Enterprise web index. allowed — Provides search and fetch inside existing network controls.
  • Controlled web result. allowed — Returns indexed information without arbitrary external egress.
  • Cloud agent → Native search and fetch: tool denied.
  • Native search and fetch → Open internet: no route.
  • Cloud agent → Supported MCP, CLI, client, or skill: approved request.
  • Supported MCP, CLI, client, or skill → Enterprise web index: search or fetch.
  • Enterprise web index → Controlled web result: returns indexed content.
9:5610:26
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:56 · section reference included

What had shipped—and the boundaries that remained

By Fang’s account, the prior year’s work produced a framework combining remote user-identity execution, non-CLI interfaces, provenance propagation, and controlled web access. Two Sigma also operated a managed fleet of remote agents for employees while preserving the more general ability for anyone at the firm to deploy an agent into their own namespace under their full identity.

Recording frame at 853 secondsOpen full source frame
Recording frame at 853 seconds

The Q&A sharpens an important security distinction: the provenance header is not authentication. Someone could populate an agent marker themselves, but that would not let them become Shu. The system still verified the originating identity through its existing identity chain, then used the separate header to classify and trace agent involvement. For non-HTTP downstream work, the marker entered through an RPC boundary and became part of the internal span, much like a trace ID.

Fang also expected self-managed models to become attractive for a substantial share of enterprise inference. His reasons were operational: cost, provider deprecations, and performance changes when frontier labs released new models. He presented this as his personal direction of travel, not as a description of the deployed architecture.

Agent session data introduced another privacy boundary. Two Sigma tried to keep a user’s sessions localized rather than exposing them broadly across the firm, because work sessions could contain information privileged to that employee. Within that boundary, usage patterns could improve configuration and personalization based on what the person actually did, rather than only their position in an organizational hierarchy.

Provisioning was deliberately unremarkable: the necessary namespace infrastructure already existed for every user, so an employee could build an agent with existing frameworks and deploy it under their identity. Promotion was a separate decision. An individually useful agent did not become a team-wide or company-wide service merely because it could run; it went through the normal production questions around support, security, and operational ownership, like any other application.

13:0313:33
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:03 · section reference included

Resources

Transcript & slides

Loading transcript and slides…

Transcript download