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

.

Great. Thanks, everyone, for coming. This talk is called Tethered, Our Agents Are Us. I'm Xu Feng from Two Sigma, and let's get started. So, just a quick explanation. Two Sigma is a little quant fund. I will also take the opportunity to explain that the name ostensibly is not because we have two co-founders who are very online, but because the two sigmas are about the volatility sigma, the small sigma, and the large sigma sum. So by summing together these individual volatilities, we can hedge the risk, achieve differentiated alpha. Now, because we are a hedge fund, I have to give you all this important legal disclaimer.

You don't have to read it. It just has to be in this. And the TLDR is that I'm not trying to sell you on anything. The views are mine and not necessarily the company's. Any logos, any other companies I mention here are not me endorsing them or telling you to buy their stocks or anything. It is purely maybe coincidental. But that also is meant to segue into the fact that we are an old company. We're 25 years old, and clearly we're a very regulated industry. But we've managed to run an ecosystem where everyone at the company has a cloud agent. And not only that, but these agents run as their own identity.

So we're going to explain how we got here and why we're actually okay with this. So we're first going to do a little horror movie review.

If any of you have seen Us, you don't have to pay attention to this. If any of you haven't, the TLDR of the movie is that everyone has these doubles. And these doubles are called tethered. When the doubles decide to run loose and cause chaos and run around with these golden scissors, they're called untethered. And this is going to somehow relate to my talk. So back in June 2025, Cloud Code GA and all that stuff, people started using agents through the local computer, your local machine. And it's very powerful, but one, it was CLI-constrained, and two, it was localized, right?

We wanted to achieve a world where people could use these agents from wherever they were, whether it be mobile, through Slack, through browsers, but still have the ability to run them remote. And this is important not just because of the capability, but many people, technical or not, are not comfortable fully operating within a CLI. So the question became, how do we actually run these in terms of what identity they run as? The conventional wisdom is that you run these as some machine identity that is attached to your user in some way. You have a Xu, and you have a Xu agent.

But this quickly collapses, and we found this collapsed because of all the reasons that you can imagine, right? It's very hard to keep permissions in sync. Anytime you're dealing with software licensing, now you have to deal with two licenses. There are certain systems that do not support multiple identities interacting with the same underlying data, stuff like Google Workspace, your emails, et cetera. And then some systems are going to block as a first step. So you're just going over the barrier of entry, and then you also have to figure out how you actually manage the public and private boundaries. So obviously, it's like, why don't we just run these as the user, right?

How do we run these remotely as the exact same user identity? And as a result, all the capabilities, all the access, all those previous constraints are no longer valid. And we already had infra for this, and I imagine a lot of you do too. If you don't, I would encourage investing in it, which is that you can have a Kubernetes cluster. You have all of your clusters, your regions, et cetera, and you have namespaces for individuals, right? And the reason we had this is because we often already needed this capability, not for the agentic purposes, but for all the automated operations that we need to do that did not suit confinement to someone's local machine.

So we'd run automated jobs. Code containers usually operate on this principle, research notebooks, et cetera.

And every single user already had these namespaces existing in every single region, and everything in it runs as the user. A very simplistic way of how this works: some trigger is going into your controller, and it's saying, hey, I need to spin up some compute resources. You have a separate identity service that a sidecar in the pod pulls down from to allow your actual containers to run and mount that identity, and it runs as you. So, of course, there are big dangers with this, right? And the first danger you may imagine is an internal danger. How do you actually differentiate who or what took action, right? You and your Xu agent are now the exact same identity.

That's why I grew this mustache so you could tell the difference between us for now. But you really want to know that differentiation because certain actions that can be taken, you want to audit, you possibly want to block, and you want to just have the trace, right? You want to have the attribution to determine, hey, was it someone operating as the human, operating purely human actions, or was it the agent identity doing these things? Another danger, and perhaps a bigger one, is we all know that for all of these capabilities, and LLMs in general, it's essential you have access to the external web.

These are point-in-time mathematical functions that cannot actually update based on current data. So it's open internet access. That's why it's a core capability: web search, web fetch tools, right? The problem is once you have that capability, you leave yourself open to huge vulnerability vectors, one of which is exfiltration risk. This is one we are deeply concerned with in terms of possibly losing IP, exposing our sensitive information, but also certainly the possibility of untrusted content flowing back in. And prompt injection, malware, and vulnerabilities are all big risks there.

And then something we separately deal with is just the ability to make sure we don't use licensed content without the right copyrights or actual licensing, right? You can map this to the golden scissors that they use in Us. So this is kind of our biggest fear, to be honest. So we are a finance firm, and in finance, there's a concept of risk and return. So when we think about what is the positioning on the risk and return graph, there's huge value in allowing agents to run as you, but also there's very high risk. What we generally want to do is make sure we capture as much of the value as possible, but reduce the risk. We're optimizing that ratio of return over risk.

Some of you may know the Sharpe ratio. We're looking at that from the perspective of how do we let agents run as users and optimize that return. And the ways we need to do this are to solve those two critical problems. One, differentiating access attributed to the human versus the agent. And two, somehow getting safe web access in place. So the first thing we did is this attribution step, right? And how we did this is we use a header, and we make sure that every single agent continues to append to that header. And this is something we've all hopefully done in some way, right? Trace IDs.

You've all done this in deterministic code, making sure that your observability stack propagates through a trace ID through disparate systems. How we did it is very similar to how you would do it for a trace ID, except we are dealing with a certain difference in the control vector, which is the agent itself, right? And you can force, using certain HTTP clients, using MCPs, using skills, to make sure that that header initially gets populated, and everywhere else along the way continues to be populated, right? You have a lot more deterministic control over agents and the harnesses and the frameworks than you may think.

And you can enforce it with some of the already existing primitives. Now, this gets very interesting because this is not only giving us the proper identification of who did something, right? It actually goes beyond that. And no longer are we confined by just knowing the act identity, but we also actually get the full provenance through the system, right? And as we deal with multiple steps in the system, we are able to replay the entire chain of actions that actually led to some end result. So the comparison here is if we had used that Xu agent identity, we wouldn't have this, and we would just know that at some point,

Xu agent triggered this initial flow into the span, but we don't actually know, hey, those subsequent actions, how do we properly trace back to the origination point? With this header, this trace ID, we get that full propagation, and the actor is still me, right? It's still my identity. And the second step that we needed to fix is this web access, right? A lot of web access these days uses indexes for search, right? I think Cloud Code's native one is Brave Web Browser, and it uses the Brave index. Well, we were like, hey, why don't we see what Google has, right? Google is at its core, hopefully, still a search company, and they do this index generation already.

And it turns out they actually do offer something specifically for regulated industries like ours that allows you to use their web index, but within your existing VPC, your network controls, right? And it's called Web Grounding for Enterprise. It basically works like this, where it's still within the exact same network boundary where you're probably running your cloud agents and stuff like that. And it offers two core capabilities: search and fetch, right? So those exact capabilities we want to mirror, we leverage that, we have all these guarantees. There's one tiny downside, which is the data is obviously not going to be completely fresh, right?

And the constraints around this, last I checked, it's fresh within 24 hours, and for more regularly updated websites, it's fresh within six hours. But for most use cases that you may have for agents, that's probably more than sufficient and completely removes this external egress vulnerability vector. Now, the second question is how do we actually ensure the agents use Web Grounding? And again, this is very simple with the existing primitives, right? You just need to make sure that they don't get confused, and you certainly block the access itself, but just for user experience and stuff like that, you need to make sure those tools themselves

that are already existing and primitive and native to these agent harnesses and frameworks and such are actually blocked, right?

Again, here's a Cloud Code example. I think every other harness has the same thing: Web Search, Web Fetch. We just deny those tools. It's like, hey, you can't even use these. These are not even in your suite of tools available to you. Instead, we use the redirection going through MCP CLI and actual client code using the supported paths, skills, whatever, to make sure that whenever someone does need the capabilities of web access, it goes through that Web Grounding cached index. So, takeaways from this talk: make sure you tether your agents, right? Letting them run around untethered is very dangerous. We want to tether them, and it's much safer to do so.

And in fact, if we go back to that initial slide of how we consider this relative to the risk and expected return, because of some of the things we found while doing this, we actually believe we didn't lose expected value while hugely reducing the risk, right? So the index certainly lags, but we get a ton more observability by just using that tagging primitive versus the actual pure identity verification. And I think this is one thing people should really consider, especially people working at companies, enterprises, which is that there are a ton of things happening in the GenAI landscape that are probably scary to us,

that make your security teams really afraid, that feel like, hey, they are too far on the frontier, right? You're like, I wouldn't run this locally. I wouldn't run an open cloud agent on my local machine with full permissions, right?

There are all these horror stories and various anecdotes about why this is bad. But in an enterprise, again, you can figure out how to leverage your enterprise resources to actually reduce those risk vectors and get the real value out of the capabilities, and this is where you should be investing that time. So, what we ultimately shipped is this entire framework, right? We have the ability to run cloud agents as user identities because of all of those guardrails and vectors we put in place, and using different interface vectors to actually operate with them so that people who are not comfortable with CLIs can leverage them, but certainly for other cases as well.

And as part of that, we made sure to ship out just a managed fleet of cloud agents for every single user in this remote fashion that they can already interact with, so that we can continue to deploy and improve what is actually available to individual users. But also the core capability itself of being able for anyone at the company to deploy an agent that runs in the cloud remotely with their full identity is there, and is something we are comfortable with. So, to finish up, everything I talked about actually happened last year. So if you are interested at all in wanting to build and see what we're working on now,

or even better, if you're like, that was horrible, we could do so much better, we are hiring, and we encourage you to apply. If you have any experience in any of these domains, you can check that QR code, check that link. Yeah, that's it.

Any questions? What do you think about local LLMs connected to new agents or enterprise? Not the views of my company, but personally I think that is. Is this a question? Yeah, sorry. His question was how do I view local LLMs for enterprise usage?

And I think local in the sense that we manage ourselves is probably where we eventually want to go for a lot of our token use and inference.

Because of cost, because of deprecations, because every time a frontier lab drops a new model, you see some degradation. There's too much volatility in that that we don't need to risk as the open-weight models become more advanced and sophisticated. Yeah, so as you can see, the header is not purely differentiating in itself. Someone could certainly populate that, but the actor, the identity itself, will not be me, right? So someone could, I guess, write in that they're using some agent, but the core previous identity itself is not mimicable, not actually interceptable, right?

So we still have both the originating identity, and all of your identity ecosystems and chains ensure that, but also the header. It's not part of the header thing.

Yeah, that is separate. The header is just the XCSLM agent, and then you still have some way, you need some way, to actually determine the identity of who's coming. Second part, are you using that in single headers or any other identification that have, or not, if you're writing a single header property? Yeah, generally all of our RPC in some way has an initial entry point that is populatable with that header, and then once it actually goes downstream, same with trace IDs, it's part of the span internally within the system. Can you clarify how the use of Google Cache Index addresses the prompt injection issue?

Yeah, so the core thing about this index is not only is it a cached index, it has a lot of other controls and safety guarantees around it. It is specifically made for these curated financial, highly regulated industries. So they themselves are doing some of their own curation on top of it. Now, certainly, I think that curation could fail. It's probably done using GenAI. But the prompt injection risk is far reduced because everything still remains internal. Yeah? How important is behavioral data for these pages? And so what are the sources of your acquired data? Do you mean how they're being used? The behavioral data for people that are using it?

Yeah, I think it's critical in the sense that that behavioral data is something we can further configure based on, right?

We do try to ensure that not everyone at the firm can see what your agents are doing, right? There's stuff certainly work-wise, but also more sensitive information that might be privileged to you. So your session data is kind of localized. Now that behavioral data in the session data is very powerful because it can define additional configuration that can be applied to these agents for the purposes of making the user experience better. So we try to leverage that to figure out what to configure further, not just based on someone's hierarchical persona, but actually based on their usage to make sure that their experience continues to improve based on what they're doing.

Almost out of time. Me and my, sorry, I'll take the last question. I was just going to ask, you were saying you have a process for letting individuals create their own agents. Yep. How do you go about that? Can anybody create their own agents?

Is there a process for provisioning certain individuals? Is there a process for promoting agents to be used across the company versus individual teams? Yeah, for building our own agents, we use some of the existing frameworks for agent building. Obviously, all the GenAI harnesses are very good at using those frameworks to build agents. So you have a lot of agents proliferating based on that. In terms of provision, everything is already provisioned. All this is, every single user at the firm has all the necessary infrastructure in place. So that's not really a worry. They can build an agent, deploy as necessary into their namespace running as their identity.

The aspect of how do agents then become a universal company-wide or larger beyond individual users agent goes through your standard kind of mechanisms, right? Like, hey, is there going to be proper production support? Is there the right security? It's like any application you might develop. Yeah, so me and my colleagues will stick around here if anyone wants to talk further. I guess if you're sticking around, I can also take more questions, but thanks for coming to this talk. Thank you. Thank you. Is there the right security? It's like any application you might develop. Yeah, so me and my colleagues will stick around here if anyone wants to talk further.

You know, I guess if you're sticking around, I can also take more questions, but thanks for coming to this talk. Thank you. Thank you.