For years, the default assumption when deploying AI agents inside an organisation was straightforward: give the agent its own machine identity, grant it the permissions it needs, and manage that identity separately from the humans it serves. On paper this feels safe and clean. In practice, it creates a different set of problems — ones that compound quietly over time.
The Hidden Cost of a Separate Identity
When an agent runs under its own account, two things start to diverge: what the human user can access and what the agent can access. Permissions get updated for one and not the other. Software licenses may need to be counted twice. Some systems — Google Workspace being a common example — do not easily support multiple identities operating on the same data. And anytime the agent crosses the boundary between public and private information, someone has to draw and maintain that boundary manually.
The alternative explored by engineers at Two Sigma, a quantitative hedge fund operating under strict regulatory constraints, is to drop the separate machine identity entirely. Every agent runs as the user it serves, inside that user’s existing access boundary. Permissions never need to be synchronised because they were never split.
What Running “As the User” Actually Means
Two Sigma already provisioned per-user Kubernetes namespaces — isolated computing environments — for research notebooks and automated jobs. Adding an agent meant placing it inside a namespace that already existed, pulling credentials from an identity service via a sidecar process (a small helper container that runs alongside the main one), and running the container as the user. The agent inherits exactly what the user has access to: not a curated subset, not a permissions clone that might drift out of sync, but the precise same footprint.
The upside is immediate: licensing is unchanged, access is never over- or under-granted, and integration with systems that resist multiple identities just works. The risk is equally immediate: an agent acting under a user’s full identity can cause full-user-level damage.
Two Guardrails That Shift the Equation
Two Sigma built two specific controls to make user-tethered agents viable in a regulated environment.
Attribution headers. Because the agent and the human share an identity, any audit trail that only captures “who did this?” conflates agent actions with human ones. The solution is a custom HTTP header — a label appended to every network request the agent makes — that propagates through all downstream systems, the same way distributed tracing (a technique for following a request across multiple services) tracks a request end to end. This does not restrict what the agent can do; it makes every agent action distinguishable, attributable, and replayable after the fact. The full chain of a multi-step operation can be reconstructed, not just the identity that initiated it.
Enterprise web grounding in place of open internet access. Open web access is the primary exfiltration and prompt-injection risk vector for enterprise agents. Prompt injection refers to malicious content embedded in a web page that attempts to hijack the agent’s instructions. Rather than block web access entirely or accept unmediated internet egress, Two Sigma replaced native web search and fetch tools with Google’s Web Grounding for Enterprise: the same web index, but accessed entirely within the customer’s own private cloud environment, with no external traffic. Data freshness lands within six to twenty-four hours depending on the site — an acceptable tradeoff given what it eliminates in access-control complexity and injection risk.
The Risk/Return Frame
What makes this approach worth examining is the reasoning behind it, not just the mechanics. Running agents as the user’s identity carries higher intrinsic risk than a restricted machine identity. Two Sigma’s judgment is that with these two controls in place, they captured most of the practical value while dramatically reducing the actual risk — and that the residual exposure is acceptable in exchange for an architecture that eliminates an entire class of ongoing maintenance problems.
That framing — not “how do we eliminate risk?” but “what is the expected return on the risk we are accepting?” — is more honest than most enterprise AI deployment guidance, which tends to default to restriction without accounting for the value lost by restricting.
Where This Points
The interesting open question is whether user-tethered agents become a default pattern or remain a specialist choice for environments that already have per-user infrastructure. Two Sigma’s approach works partly because they had per-user namespaces before agents arrived. That precondition is becoming more common as cloud-native environments mature, but it is not yet universal.
The deeper shift may be conceptual. There is a meaningful difference between an agent that acts on behalf of a user and one that runs as the user — in permissions, in auditing, in the kinds of mistakes the system is even capable of making. As agent deployments move from experiments to production, that distinction is likely to matter more, not less.
Text summarized and optimized using Anthropic’s models and reviewed by a human.