AI Agent Security for Enterprises: Lessons From Two Sigma
- Bryan Downing
- 2 minutes ago
- 8 min read
What happens when an AI agent can access the same systems, documents, and tools as the employee using it?
That question sits at the center of AI agent security for enterprises. A useful assistant needs access to business resources. But when software can act on someone’s behalf, organizations must decide how to identify it, constrain its actions, and investigate mistakes.
In the supplied talk, “Tethered: Our Agents Are Us,” Two Sigma’s Shu Fang describes an approach: cloud agents that operate under employees’ user identities, supported by attribution controls and restricted web access.
The central idea is not unrestricted autonomy. It is keeping agents connected to an accountable person and an enforceable security framework.
This article examines the architecture described in the talk, its trade-offs, and the lessons enterprise teams can apply. Details about Two Sigma’s implementation come from the transcript; additional recommendations are distinguished from the speaker’s account.
What Is AI Agent Security for Enterprises?
AI agent security for enterprises means controlling how AI-powered systems authenticate, access information, use tools, and perform actions across business environments.
For an agent, security extends beyond the quality of its answers. An incorrect response becomes more consequential when the system can modify records, execute commands, or send messages. OWASP describes excessive functionality, permissions, and autonomy as underlying causes of “excessive agency.” (genai.owasp.org)
A practical evaluation should answer four questions:
Identity: Whose authority does the agent use?
Authorization: Which actions are permitted?
Attribution: Can investigators distinguish automated activity from human activity?
Containment: What prevents a mistake from spreading?
Two Sigma’s talk concentrates on two particularly difficult problems: distinguishing human actions from agent actions and providing useful web access without unrestricted outbound connectivity.
Why Two Sigma Moved Agents Beyond Local Computers
According to Fang, the motivation for remote agents was partly accessibility.
Local agents were powerful, but tying them to an employee’s computer limited where and how people could use them. Command-line interfaces also created friction for employees who preferred other ways of interacting with software.
The team wanted agents that employees could reach through browsers, Slack, and mobile-friendly interfaces while computation happened remotely.
That ambition raised an architectural question: Which identity should a remote agent use?
Fang describes two possibilities:
Give the agent a separate machine identity associated with the employee.
Run the agent under the employee’s existing identity.
The team chose the second approach. Understanding why requires looking at the operational difficulties they encountered with the first.
The Identity Problem: Separate Accounts or User Authority?
In the transcript, Fang explains that separate agent identities introduced several complications.
Permissions needed synchronization between the person and the agent. Some software created licensing questions. Other applications did not easily support two identities working with the same personal resources, such as an employee’s mailbox.
For Two Sigma’s environment, these obstacles made separate identities difficult to manage.
Running an agent as the user allowed it to work within existing access relationships instead of recreating those relationships for a second account.
However, this is a case-specific architectural choice—not evidence that separate agent identities always fail. Microsoft, for example, explicitly supports specialized agent identities designed to distinguish agents from human users and apply agent-specific controls. (learn.microsoft.com)
The lesson for AI agent security for enterprises is to evaluate identity models against actual workflows.
Ask whether an agent needs the employee’s personal context, whether delegated access is available, and whether the agent must be independently suspended or restricted.
User-linked authority should not automatically mean unrestricted use of every user permission. OWASP recommends minimizing permissions and enforcing authorization in downstream systems rather than letting the model decide what is allowed. (genai.owasp.org)
Reusing Existing Cloud Infrastructure
Two Sigma did not build its agent platform on an entirely new foundation.
Fang describes existing Kubernetes infrastructure with individual employee namespaces across regions. These environments already supported remote automated jobs, research notebooks, and container-based workloads.
The agent deployment followed a similar pattern:
A request triggered a controller.
The controller provisioned computing resources.
A sidecar interacted with an identity service.
The workload obtained the identity context needed to operate as the employee.
This existing foundation helped the team extend an established operating model to agents.
For other organizations, the useful question is: Which parts of our current platform already solve provisioning, authentication, isolation, and operational support?
There is an important qualification. A Kubernetes namespace does not automatically provide complete isolation. Kubernetes documentation explains that namespace-based separation requires additional controls, including authorization and network policies. (kubernetes.io)
Treat namespaces as organizational building blocks, not a complete security boundary by themselves.
Building AI Agent Audit Trails Without Losing User Context
When humans and agents use the same underlying identity, ordinary access records may not explain who actually initiated an action.
Did an employee modify a document directly? Did an agent perform the modification? Did one agent invoke another service that made the change?
Fang describes adding an agent-attribution header and propagating that information through subsequent operations.
The approach resembles distributed tracing. OpenTelemetry explains that propagating trace and span context lets teams connect activity across service boundaries and reconstruct the flow of a request. (opentelemetry.io)
In Two Sigma’s account, this provided more than a simple human-versus-agent label. It helped establish the chain of activity leading to an outcome.
For example, consider this hypothetical workflow:
An employee requests a research summary. An agent retrieves internal documents, calls an approved search service, produces a draft, and saves it to a workspace.
An effective investigation should connect those operations rather than leave them as unrelated events.
Still, identity and tracing solve different problems. A separate agent identity can also carry distributed tracing context. The broader lesson is that neither identity model removes the need for end-to-end provenance. (learn.microsoft.com)
Why an Attribution Header Is Not Authentication
A header saying “agent activity” is not, by itself, proof of who made a request.
Fang acknowledges this distinction during the questions: the underlying identity remains independently authenticated.
Enterprise implementations should also consider forged or missing attribution metadata. OpenTelemetry warns that incoming trace context from untrusted sources can be manipulated and may need sanitizing or rejection. (opentelemetry.io)
A sensible design review should therefore ask:
Which trusted component adds attribution?
Can an agent remove or replace it?
What happens when metadata is missing?
Can investigators verify the authenticated actor separately?
Attribution should be enforced by the platform, not depend solely on the model remembering an instruction.
Safe Web Access: Useful Information Without Unrestricted Browsing
The second major challenge in the talk is external information access.
Fang identifies several concerns: sensitive information leaving the organization, malicious content entering through retrieved material, and inappropriate use of licensed content.
These risks need different controls. Restricting outbound connections addresses a different problem from deciding whether retrieved text contains malicious instructions.
OWASP describes indirect prompt injection as instructions embedded in external material, including websites and files, that change model behavior in unintended ways. (genai.owasp.org)
A hypothetical example illustrates the distinction.
An agent retrieves a page for a legitimate research task. Hidden in that page is an instruction to locate an internal document and transmit its contents elsewhere.
The organization needs controls over both:
Whether the agent treats the page as instructions.
Whether any tool can carry out the requested transmission.
Two Sigma’s response, as described by Fang, was to replace unrestricted web access with an approved search-and-retrieval path.
How Web Grounding Fits Into the Architecture
The talk identifies Google’s Web Grounding for Enterprise as the service used for this controlled information-access path.
Google documents the product as using a selected web index suitable for highly regulated industries. It supports VPC Service Controls and does not log customer data. Its index is narrower than general Google Search. (docs.cloud.google.com)
Those properties matter, but they require careful interpretation.
Support for a service perimeter does not mean the entire public web has been moved into an organization’s private network. Nor does using the service automatically establish compliance for the complete agent application.
Freshness is another trade-off. Google states that update schedules can vary, with fast-changing content updated every six hours and the whole index every 24 hours. (docs.cloud.google.com)
For implementation planning, classify workflows by freshness requirements.
A background explainer may tolerate indexed information. A task requiring an immediately updated operational fact may need a different approved source.
The right question is not simply whether the agent has web access. It is whether the approved information path meets the task’s requirements.
Why Controlled Retrieval Does Not Eliminate Prompt Injection
One claim in the talk deserves qualification: keeping retrieval within a controlled environment does not make all retrieved content trustworthy.
Malicious instructions can appear in cached pages, internal documents, or repositories. OWASP specifically notes that retrieval-augmented generation does not fully mitigate prompt injection. (genai.owasp.org)
Controlled retrieval can support a safer architecture, but it should not be presented as a complete prompt-injection defense.
For AI agent security for enterprises, use multiple layers:
Treat retrieved material as data, not governing instructions.
Validate proposed actions outside the model.
Limit the tools available for each workflow.
Require approval for consequential operations.
Test malicious content in realistic task sequences.
These measures align with OWASP’s recommendations to constrain behavior, validate outputs, enforce least privilege, and involve humans in high-risk actions. (genai.owasp.org)
The goal is to reduce both the likelihood of manipulation and the damage it could cause.
Blocking Native Tools Is Only Part of Enforcement
Fang explains that the team denied native web search and fetch tools, then directed agents toward approved alternatives through supported integrations.
This helped make the intended workflow clear: use the sanctioned retrieval path rather than the agent framework’s default browsing tools.
However, tool restrictions and network restrictions are not interchangeable.
Claude Code’s documentation explicitly warns that controlling WebFetch alone does not prevent network access when shell tools can still use utilities such as curl or wget. It describes permissions and sandboxing as complementary controls. (code.claude.com)
A practical deployment review should therefore examine alternative paths:
Shell commands.
Custom scripts.
Browser automation.
Third-party integrations.
Agent-created subprocesses.
Do not stop at hiding an unwanted tool. Verify that the runtime cannot reach prohibited destinations through another mechanism.
This is where enterprise infrastructure can make the approved workflow enforceable rather than merely suggested.
A Practical Rollout Plan for Secure Cloud Agents
The following rollout plan is an editorial recommendation inspired by the talk, not a description of Two Sigma’s complete internal process.
1. Start With a Narrow Workflow
Choose a task with clear inputs, outputs, and ownership.
For example, begin with drafting a document for review rather than publishing it automatically. Define success before expanding permissions.
2. Document the Authority Model
Record which identity the agent uses, what resources it needs, and which actions remain prohibited.
Make the distinction between employee access and agent-approved access explicit.
3. Test Attribution Across the Full Workflow
Trace a request through every service it touches.
Include failure cases: missing metadata, retries, background jobs, and calls between agents. Ask whether an investigator could reconstruct the result without guessing.
4. Test the Boundaries
Attempt prohibited actions in a controlled environment.
Check whether denied browsing can reappear through a shell, whether retrieved instructions influence tool use, and whether restricted data reaches an unauthorized destination.
5. Define the Stop Procedure
Before rollout, decide who can suspend an agent, revoke its access, and investigate an incident.
Give the operating team a clear owner and a documented recovery process.
6. Expand Based on Evidence
Evaluate completed tasks, corrections, blocked actions, latency, and operating cost.
Use those observations to decide whether broader access creates enough value to justify the additional exposure.
Scaling From Personal Agents to Shared Services
The transcript distinguishes personal agents from agents intended for wider organizational use.
Fang says individual employees could deploy agents into already provisioned environments. Moving an agent beyond personal use, however, followed the organization’s standard application processes, including security and production-support considerations.
That distinction is worth preserving.
An experimental personal assistant and a shared operational service should not automatically receive the same deployment treatment.
The talk also highlights privacy within observability. Fang describes keeping session information restricted rather than making every employee’s agent activity visible companywide.
For your own rollout, decide who needs access to operational metrics, detailed traces, prompts, and retrieved content. Avoid treating “more visibility” as permission to expose everything.
A useful audit system should support investigation while respecting the sensitivity of the work being observed.
Conclusion: Keep Enterprise Agents Accountable and Constrained
Two Sigma’s account offers a practical perspective on AI agent security for enterprises: start with the infrastructure and controls the organization already knows how to operate.
Its reported approach combines user-linked authority, propagated attribution, controlled retrieval, and managed remote deployment.
The lesson is not that every company should copy the same identity model. It is that useful autonomy needs explicit boundaries and evidence that those boundaries work.
Before expanding an agent’s responsibilities, ask:
Can we identify its authority, explain its actions, constrain its tools, and stop it when necessary?
Comments