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?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
A request arrives from an interface and asks for compute.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
The user initiates work through a remote interface.
The employee identity authorizes each call, while agent metadata propagates through the trace so the initiating path remains reconstructable.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
Runs as the employee and needs current information.
Denying native tools closes the bypass; supported clients direct search and fetch through the enterprise-controlled index.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
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.
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- CIAM for AI: Authn/Authz for Agents — Michael Grinich, CEO of WorkOS
Extends the identity discussion with delegated access, signed identity chains, scoped capabilities, and human-linked auditability.
- Privacy First Enterprise AI: Building AI Agents that Never Leave Your Security Boundary
Explores the complementary pattern of operating enterprise agents inside existing identity, cloud, and security boundaries.
- Security Firewall for Agents
Examines why independent network enforcement is still needed when agents have powerful credentials and can encounter prompt-injected content.
Read the complete timestamped transcript
- 0:01
[music]
- 0:13
Great. Thanks everyone for coming. Uh
- 0:15
this talk is called Tethered. Our agents
- 0:17
are us. I'm Shu Fang from Two Sigma and
- 0:21
let's get started.
- 0:23
So just a quick explanation. Two Sigma
- 0:26
is a little quant fund. I will also take
- 0:29
the opportunity to explain that the name
- 0:31
ostensibly is not because we have two
- 0:33
co-founders who are very online but
- 0:36
because the two sigas are about the
- 0:39
volatility sigma the small sigma and the
- 0:42
large sigma sum. So by summing together
- 0:44
these individual volatilities we can uh
- 0:47
hedge the risk achieve differentiated
- 0:50
alpha.
- 0:52
Now because we are a hedge fund I have
- 0:54
to give you all this important legal
- 0:56
disclaimer. You don't have to read it.
- 0:57
It just has to be in this. And the TLDDR
- 1:00
is that I'm not trying to sell you on
- 1:02
anything. The views are mine and not
- 1:05
necessarily the companies. Any logos,
- 1:08
any other companies I mentioned here are
- 1:09
not me endorsing them or telling you to
- 1:12
buy their stocks or anything. It is
- 1:13
purely maybe coincidental.
- 1:17
But that also is meant to segue into the
- 1:20
fact that we are an old company. We're
- 1:23
25 years old and clearly we're a very
- 1:26
regulated industry, but we've managed to
- 1:30
run an ecosystem where everyone at the
- 1:32
company has a cloud agent. And not only
- 1:35
that, but these agents run as their own
- 1:36
identity. So, we're going to explain how
- 1:38
we got here and why we're actually okay
- 1:40
with this.
- 1:44
So, we're first going to do a little
- 1:45
horror movie review. If any of you have
- 1:47
seen us, you don't have to pay attention
- 1:49
to this. defend if you haven't the TLDDR
- 1:51
of the movie is that everyone has these
- 1:54
doubles and these doubles are called
- 1:57
tethered when the doubles decide to run
- 2:01
loose and cause chaos and run around
- 2:03
with these golden scissors they're
- 2:04
called untetered and this is going to
- 2:06
somehow relate into my talk
- 2:10
so back in June 2025 you know cloud code
- 2:13
GA and all that stuff people started
- 2:15
using agents through the local computer
- 2:19
your local machine and it's very
- 2:21
powerful but one it was CLI constrained
- 2:23
and two it was localized right we wanted
- 2:26
to achieve a world where people could
- 2:28
use these agents from wherever they were
- 2:31
whether it be mobile through slack
- 2:33
through browsers but still have the
- 2:36
ability to run them remote and this is
- 2:39
important not just because of the
- 2:40
capability but many many people
- 2:44
technical or not are not comfortable
- 2:45
fully operating within a CLI so the
- 2:48
question became Okay, how do we actually
- 2:50
run these in terms of what identity they
- 2:52
run as?
- 2:55
The conventional wisdom is that you run
- 2:57
these as some machine identity that is
- 3:00
attached to your user in some way. You
- 3:02
have a shoe and you have a shoe agent.
- 3:05
But this quickly collapses and we found
- 3:07
this collapsed because of all the
- 3:09
reasons that you can imagine, right?
- 3:10
It's very hard to keep permissions in
- 3:12
sync. Anytime you're dealing with
- 3:13
software licensing, now you have to deal
- 3:15
with two licenses.
- 3:17
uh there's certain systems that do not
- 3:19
support multiple identities interacting
- 3:21
with the same underlying data. You know,
- 3:23
stuff like Google Workspace, your
- 3:25
emails, etc. And then how some systems
- 3:28
are going to block as a first step. So
- 3:31
you have to you're just going over the
- 3:33
barrier of entry. And then you also have
- 3:35
to figure out how you actually manage
- 3:37
the public and private boundaries.
- 3:41
So obviously it's like why don't we just
- 3:43
run these as the user, right? How do how
- 3:45
do we run these remotely as the exact
- 3:48
same user identity? And as a result, all
- 3:50
the capabilities, all the access, all
- 3:52
those previous constraints are no longer
- 3:56
valid.
- 3:59
And we already had the info for this and
- 4:01
I imagine a lot of you do too. If you
- 4:03
don't, I would uh encourage investing in
- 4:06
it, which is that you know you could
- 4:09
have a Kubernetes cluster. You have all
- 4:11
all of your clusters, your regions, etc.
- 4:13
And you have name spaces for
- 4:15
individuals, right? And the reason we
- 4:17
had this is because we often already
- 4:19
needed this capability not for the
- 4:21
agentic purposes, but for all the
- 4:23
automated operations that we need to do
- 4:26
that did not suit confinement to
- 4:28
someone's local machine. So we'd run
- 4:30
automated jobs, you know, code
- 4:32
containers usually operate on this
- 4:33
principle, research notebooks, etc. And
- 4:36
every single user already had these
- 4:38
namespaces existing in every single
- 4:40
region and everything in it runs as the
- 4:42
user.
- 4:43
A very simplistic way of how this works.
- 4:46
Some trigger is going in to your
- 4:49
controller and it's saying, "Hey, I need
- 4:51
to spin up some compute resources. You
- 4:53
have a separate identity service that a
- 4:56
sidecar in the pod pulls down from to
- 4:59
allow your actual containers
- 5:01
to run and mount that identity and it
- 5:03
runs as you.
- 5:07
So of course there are big dangers with
- 5:09
this right and you know the first danger
- 5:12
you may imagine is an internal danger.
- 5:14
How do you actually differentiate who or
- 5:17
what took action right? You have you and
- 5:20
your U agent are now the exact same
- 5:22
identity. That's why I grew this
- 5:23
mustache so you could tell the
- 5:25
difference between us for now. But uh
- 5:27
you really want to know that
- 5:29
differentiation because certain actions
- 5:31
that can be taken. You want to audit,
- 5:34
you possibly want to block and you want
- 5:37
to just have the trace, right? You want
- 5:40
to have the attribution to determine,
- 5:41
hey, was it someone operating as the
- 5:44
human operating purely human actions or
- 5:47
was it the agent identity doing these
- 5:49
things?
- 5:53
Another danger and perhaps a bigger one
- 5:56
is we all know that for all of these
- 5:58
capabilities and LOMs in general, it's
- 6:00
essential you have access to the
- 6:02
external web. These are point in time
- 6:04
mathematical functions that cannot
- 6:07
actually update based on current data.
- 6:09
So it's like open internet access.
- 6:11
That's why it's a core capability, web
- 6:13
search, web fetch tools, right? The
- 6:15
problem is once you have that
- 6:17
capability, you leave yourself open to
- 6:19
huge vulnerability vectors. One of which
- 6:22
is exfiltration risk. This is one we are
- 6:25
deeply concerned with in terms of
- 6:26
possibly losing IP, you know, just
- 6:28
exposing our sensitive information. but
- 6:31
also certainly the possibility of
- 6:34
untrusted content flowing back in and
- 6:36
you know prompt injection just malware
- 6:39
and vulnerabilities are all big risks
- 6:41
there and then something we separately
- 6:43
deal with is just the ability to make
- 6:45
sure we don't
- 6:47
u use licensed content without the right
- 6:50
copyrights or actual licensing right you
- 6:53
can map this to the golden scissors that
- 6:56
they use and us so this is kind of our
- 6:58
biggest fear to be honest
- 7:01
So we are a finance firm and in finance
- 7:05
there's a concept of obviously risk and
- 7:07
return. So when we think about what is
- 7:11
the positioning on the risk and return
- 7:13
graph there's huge value in allowing
- 7:16
agents to run you but also there's very
- 7:18
high risk. What we generally want to do
- 7:21
is make sure we capture as much of the
- 7:23
value as possible but reduce the risk.
- 7:26
We're optimizing that ratio of return
- 7:28
over risk. Some of you may know the
- 7:30
sharp ratio. We're looking at that from
- 7:32
the perspective of how do we let agents
- 7:35
run as users and optimize that return.
- 7:38
And the ways we need to do this, right,
- 7:40
are to solve those two critical
- 7:41
problems. One, differentiating access
- 7:44
attributed to the human versus the
- 7:46
agent. And two, somehow getting safe web
- 7:50
access in place.
- 7:54
So the first thing we did is this
- 7:56
attribution step, right?
- 7:58
And how we did this is we use a header
- 8:02
and we make sure that every single agent
- 8:04
continues to append to that header. And
- 8:07
this is something we've all hopefully
- 8:10
done in some way, right? Trace IDs.
- 8:12
You've you've all done this in
- 8:13
deterministic code. Making sure that
- 8:15
your observability stack propagates
- 8:17
through a trace ID through disparate
- 8:19
systems. How we did it is very similar
- 8:22
to how you would do it for trace ID
- 8:24
except we are dealing with a certain
- 8:27
difference in the control vector which
- 8:29
is the agent itself right and you can
- 8:32
force you know using certain HP clients
- 8:35
using MCPS using skills to make sure
- 8:38
that that header initially gets
- 8:40
populated and everywhere else along the
- 8:42
way continues to be populated right you
- 8:44
have a lot more deterministic control
- 8:46
over agents and the harnesses and the
- 8:48
frameworks than you may ink and you can
- 8:50
enforce it with some of the already
- 8:53
existing primitives.
- 8:56
Now this gets very interesting because
- 8:59
this is not only giving us the proper
- 9:02
identification of who did something
- 9:05
right it actually goes beyond that and
- 9:08
no longer are we confined by just
- 9:10
knowing the act identity but we also
- 9:13
actually get the full provenence through
- 9:15
the system right as we deal with
- 9:17
multiple steps in the system we are able
- 9:20
to replay the entire chain of actions
- 9:22
that actually led to some end result. So
- 9:25
the comparison here is if we had used
- 9:28
that shoe agent identity we wouldn't
- 9:30
have this and we would just know that at
- 9:32
some point shoe agent triggered this
- 9:34
initial flow into the span but we don't
- 9:37
actually know hey those subsequent
- 9:40
actions how do we properly trace back to
- 9:42
that origination point with this header
- 9:46
this trace ID we get that full
- 9:48
propagation and the actor is still me
- 9:51
right it's still my identity
- 9:56
And the second step that we needed to
- 9:58
fix is this web access. Right? A lot of
- 10:01
web access these days uses indexes for
- 10:05
search. Right? I think cloud code's
- 10:07
native one is Brave web browser and it
- 10:09
uses a Brave index. Well, we were like,
- 10:12
hey, why don't we see what Google has,
- 10:14
right? Google is at its core hopefully
- 10:17
still a search company and they do this
- 10:20
index generation already. And it turns
- 10:22
out they actually do offer something
- 10:24
specifically for regulated industries
- 10:27
like ours that allows you to use their
- 10:29
web index but within your existing VPC
- 10:32
your you know network controls right and
- 10:34
it's called web grounding for
- 10:36
enterprise. It basically works like this
- 10:38
where it's still within the exact same
- 10:41
network boundary where you're probably
- 10:43
running your cloud agents and stuff like
- 10:44
that and offers two core capabilities
- 10:48
search and fetch. Right? So the exact
- 10:50
capabilities we want to mirror, we
- 10:53
leverage that. We have all these
- 10:54
guarantees. There's one tiny downside,
- 10:57
which is the data is obviously not going
- 10:59
to be completely fresh, right? And the
- 11:02
constraints around this last I checked,
- 11:05
it's fresh within 24 hours. And for more
- 11:07
regularly updated websites, it's fresh
- 11:09
within 6 hours. But for most use cases
- 11:12
that you may have for agents, that's
- 11:13
probably more than sufficient and
- 11:15
completely removes this external egress
- 11:17
vulnerability vector.
- 11:21
Now the second question is how do we
- 11:23
actually ensure the agents use web
- 11:24
grounding and again this is very
- 11:28
simple with the existing primitives
- 11:29
right you just need to make sure that
- 11:31
they don't get confused and you
- 11:34
certainly block the access itself but
- 11:36
just for user experience and stuff like
- 11:38
that you need to make sure those tools
- 11:40
themselves that are already existing and
- 11:42
primitive and native to these agent
- 11:44
harnesses and frameworks and such are
- 11:47
actually blocked right again here's
- 11:49
cloud code example. I think every other
- 11:50
hotness has the same thing. Web search,
- 11:52
web fetch. We just deny those tools.
- 11:54
It's like, hey, you can't even use
- 11:55
these. These are not even in your suite
- 11:57
of tools available to you. Instead, we
- 12:00
use the redirection going through, you
- 12:02
know, MCP CLI and actual client code
- 12:06
using the supported paths, uh, skills,
- 12:08
whatever to make sure that whenever
- 12:10
someone does need the capabilities of
- 12:12
web access, it goes through that web
- 12:14
grounding cache index.
- 12:21
So takeaways from this talk basically
- 12:24
make sure you ted your agents right
- 12:26
letting them run around untetered you
- 12:28
know is very dangerous we want to tar
- 12:30
them and it's much safer to do so and in
- 12:32
fact if we go back to that initial slide
- 12:34
of how we consider this relative to the
- 12:36
risk and expected return because of some
- 12:40
of the things we found while doing this
- 12:42
we actually believe we didn't lose
- 12:45
expected value while huge hugely
- 12:47
reducing the risk, right? So, the index
- 12:50
certainly lags, but we get a ton more
- 12:52
observability by just using that tagging
- 12:55
primitive versus the actual uh just pure
- 12:59
identity verification.
- 13:03
And I think this is [sighs and gasps]
- 13:06
one thing people should really consider,
- 13:08
especially people working at companies,
- 13:09
enterprises, which is that there are a
- 13:12
ton of things happening in the Genai
- 13:15
landscape that are probably scary to us
- 13:18
that make your security teams really
- 13:20
afraid that feel like, hey, they are too
- 13:23
far on the frontier, right? You you're
- 13:25
like, I wouldn't run this locally. I
- 13:26
wouldn't run a open cloud agent on my
- 13:30
local machine with full permissions,
- 13:32
right? There's all these horror stories
- 13:34
and you know various anecdotes about why
- 13:37
this is bad. But in an enterprise again
- 13:41
you can figure out how to leverage your
- 13:43
enterprise resources to actually reduce
- 13:45
those risk factors and get the real
- 13:47
value out of the capabilities and this
- 13:50
is where you should be investing that
- 13:51
time.
- 13:54
So what we ultimately shipped is this
- 13:57
entire framework, right? We have the
- 13:59
ability to run cloud agents as user
- 14:05
identities uh because of all of those
- 14:07
guard rails and vectors we put in place
- 14:10
and using different kind of interface
- 14:13
vectors to actually operate with them so
- 14:15
that people who are not comfortable with
- 14:17
CLIs can leverage them but certainly for
- 14:18
other cases as well. And as part of
- 14:20
that, we made sure to ship out just a
- 14:22
managed fleet of cloud, you know,
- 14:25
whatever agents for every single user in
- 14:28
this remote fashion that they can
- 14:30
already interact with so that we can
- 14:31
continue to deploy and improve what is
- 14:34
actually available to individual users.
- 14:37
But also the core capability itself of
- 14:39
being able for every anyone at the
- 14:41
company to deploy an agent that runs in
- 14:44
the cloud remotely with their full
- 14:46
identity is there and is something we
- 14:48
are comfortable with.
- 14:51
So to finish up, uh, everything I talked
- 14:54
about actually happened last year. So if
- 14:56
you are interested at all in wanting to
- 14:59
build and see what we're working on now,
- 15:01
or even better, if you're like, that was
- 15:04
horrible, we could do so much better. We
- 15:07
are hiring and we encourage you to
- 15:09
apply. If you have any experience in any
- 15:11
of these domains,
- 15:13
you can check that QR code, check that
- 15:16
link. Yeah, that's it. Any questions?
- 15:20
[applause]
- 15:26
>> What do you think about local connected
- 15:28
to agents for enterprises?
- 15:32
>> Uh, not the views of my company, but
- 15:36
personally I I think that is
- 15:38
>> question.
- 15:39
>> Yeah, sorry. His question was how do how
- 15:40
do I view local LLMs for enterprise
- 15:43
usage? And I think local in the sense
- 15:47
that we manage ourselves is probably
- 15:49
where we eventually want to go for a lot
- 15:51
of our token use and inference because
- 15:54
of cost because of deprecations because
- 15:56
of you know every time Frontier Lab
- 15:59
drops a new model you see some
- 16:00
degradation. It's just there's too much
- 16:03
volatility in that that we don't need to
- 16:06
risk as the openweight models kind of
- 16:08
become more advanced and sophisticated.
- 16:22
request.
- 16:31
>> Yeah. So as you can see the header is
- 16:33
not purely differentiating in itself.
- 16:36
Someone someone could certainly populate
- 16:38
that, but the actor the identity itself
- 16:40
will not be me, right? So some someone
- 16:43
could I guess write in that they're
- 16:46
using some agent, but the core previous
- 16:49
identity itself is not mimickable, not
- 16:52
like actually interceptable, right? So
- 16:54
we still we have both we have both the
- 16:57
originating identity and that you know
- 16:59
all of your identity ecosystems and
- 17:01
chains to ensure that but also the
- 17:03
header. part of the header.
- 17:05
>> Yeah, that that that is separate. The
- 17:06
header is just XSLm agent and then you
- 17:09
still have some way you you need some
- 17:12
way to actually determine the identity
- 17:13
of who's coming.
- 17:26
Yeah, I you know gen generally all of
- 17:29
our RPC in some way has an initial entry
- 17:32
point that is like
- 17:34
populatable with that header and then
- 17:35
once it actually goes downstream you
- 17:37
know you make sure that same with trace
- 17:39
ids is part of the span internally
- 17:41
within the So
- 17:45
>> can you clarify how the use of Google
- 17:48
index addresses the prompt injection
- 17:51
issue?
- 17:52
>> Yeah. So the core things about this
- 17:54
index is not only is it a cached index,
- 17:57
it is it has a lot of other controls and
- 18:00
safety guarantees around it. It is
- 18:01
specifically made for these curated
- 18:04
financial like um highly regulated
- 18:06
industries. So they themselves are doing
- 18:08
some of their own curation on top of it.
- 18:10
Now certainly I think that creation
- 18:12
could fail. It's probably done using Gen
- 18:14
AI but the prompt injection risk is much
- 18:18
far reduced because everything still
- 18:20
remains internal.
- 18:24
>> Yep.
- 18:33
>> Do you mean how they're being used?
- 18:38
>> Yeah. I I think it's critical um in the
- 18:40
sense that that behavioral data is
- 18:42
something we can further configure based
- 18:44
on right like that we we do try to
- 18:48
ensure that not everyone at the firm can
- 18:50
see what your agents are doing right
- 18:52
like there's stuff certainly work-wise
- 18:54
but also more sensitive information that
- 18:56
might be privileged to you. So your
- 18:58
session data is kind of localized. Now
- 19:00
that behavioral data in the session data
- 19:02
is very powerful because it can define
- 19:04
additional configuration that can be
- 19:06
applied to these agents for the purposes
- 19:08
of making the user experience better. So
- 19:10
we we try to leverage that to figure out
- 19:12
what to configure further not just based
- 19:15
on someone's like hierarchical persona
- 19:17
but actually based on their usage to
- 19:19
make sure that their experience
- 19:20
continues to improve actually based on
- 19:22
what they're doing.
- 19:26
Uh we're almost out of time. me and my
- 19:29
co sorry I'll take the last question
- 19:33
you're saying you have a process for
- 19:36
letting individuals create their own
- 19:38
>> yep
- 19:40
I mean how do you go about like anybody
- 19:44
there
- 19:48
is a process for like agents across the
- 19:51
company
- 19:54
>> yeah uh for building our own agents you
- 19:57
know we we use some of the existing
- 19:59
frameworks for agent building. Obviously
- 20:00
all the genai harnesses are very good at
- 20:03
using those frameworks to build agents.
- 20:04
So you have a lot of agents
- 20:05
proliferating based on that. In terms of
- 20:08
provision, everything is already
- 20:09
provision. All this is every single user
- 20:11
at the firm has all the necessary
- 20:13
infrastructure in place. So that's not
- 20:16
really a worry. They can build an agent,
- 20:18
deploy it as necessary into their
- 20:19
namespace running as their identity. the
- 20:21
the aspect of how do agents then become
- 20:24
like a universal companywide or larger
- 20:27
beyond a individual users uh agent you
- 20:31
know goes through your standard kind of
- 20:33
mechanisms right like hey is there going
- 20:35
to be proper production support is there
- 20:37
the right security it's like any
- 20:38
application you might develop
- 20:41
uh yeah so me and my colleagues will
- 20:42
stick around here if anyone wants to
- 20:44
talk further you know I guess if you're
- 20:46
sticking around I can also take more
- 20:48
questions but thanks for coming to this
- 20:51
>> [applause]