# Balancing Acceleration and Safety for AI Agents — John Feminella — session 2026-10-13T13:36:00.000Z → 2026-10-13T13:54:00.000Z _64 transcript lines · 35 slides_ ## Transcript Layer two, we built skills. We built a plug in that is available on GitHub that builds eight skills and workflows that an advisor can take out of the box Use today and amend for tomorrow. Layer four, approval. The advisor approves everything that comes out of Claude. Nothing is saved or sent without the advisor, and that trust principle holds here too. And so you can see here on the diagram on the left, CRM, market data, custodians, all the tools and foundations and advisor needs brought into Claude. So let's go through layer one, the connectors. We brought in 25 platforms across custody, portfolio, planning, data, and CRM. Names such as Schwab, Adapa, Salesforce, and more. And there's more connectors that you can find on the Claude marketplace. This is where the industry builds once, the advisor can integrate once, and this is what compounding looks like. Layer two skills. These are the workflows we built for the advisor that they can start with and adjust and amend to their own firm. For example, pre meeting prep allows an adviser to bring a full family plan into one brief across multiple systems. The follow-up Allows the advisor to bring those meeting notes, enter them into the CRM system, and actually follow through the existing systems and tools. Nothing goes out until the advisor approves it. And this skill foundation is a baseline of which we imagine advisors will start to innovate and bring Claude into more and more of their workflows, allowing them to drive impact in their business. So, in closing, with twenty eight seconds on the clock, three questions to take to your firm today. The first one is the work Hello. How are you applying the Frontier Intelligence to your firm? How are you gaining edge and alpha from the Frontier models today? The second is the foundation. Do you all have a foundation that you trust for building and scaling agents for the future as things become more and more specialized. One connector. How are you actually building the foundations that others can use? Are you building connectors and skills for your users, for your firm, and for the industry? With that, thank you so much for having us. Enjoy the rest of the conference. Alright. And now, to explore how serious organizations can accelerate innovation without compromising trust, please welcome John Feminella, SVP of architecture at Two Sigma. Hey, everyone. All right. I precariously balanced my water over there. My name is John Feminella. I work on AI architecture and engineering at Two Sigma, which is a hedge fund here in New York. Before I get too far into things, I have a legal disclaimer. Slide that I have to show you that says two things. One, I promise not to sell or market or offer you any securities at any point in this talk. And two, everything, and this is my own opinion and not the opinion of Two Sigma. Thanks for indulging me. If I don't say those magic words, the five g microchips implanted in me will explode. So that slide is a good example, actually, of how our industry is regulated. And as a regulated company with lots of controls, I think one thing that's always To explore what happens when controls fail because that gives you a good idea about why the controls were there in the first place. And so I'd like to tell you a story about that by showing you another legal slide. After August 2020, a very interesting contract clause suddenly started showing up in a bunch of commercial loan agreements. And this clause essentially tries to prevent a certain scenario from happening. And it's complicated, but I'll explain it like this. Let's say that you're a lemonade stand business, and you borrow money from a lender to Capitalize your lemonade stand. And the bank that's overseeing that transaction that's in the middle between the borrower and the lender sends the lender all of the money that you owe in a catastrophic mistake. You'd probably be mad and want the money back, but the lender might also say, no thanks. You paid us back and we're all good, so we'd rather keep the money. Something like this happened in August 2020. Revlon, the cosmetics company, had borrowed money under a big 2016. Term loan. And that loan was split up into a bunch of pieces across 300 plus lenders, hedge funds, credit funds, CLOs, other banks. And in the middle is Citibank, the administrative agent. Being the agent in this kind of transaction means that you're performing the plumbing that connects the borrowers with the lenders and managing the life cycle of the loan. So in this transaction, Revlon pays Citi, and then Citi pays the lenders. And Citi is not lending its own money. It's just in the middle of moving people's money around. So here's the plan. And for 08/11/2020, Revlon would pay about $8,000,000 of accrued interest to both groups, and the lender's principal would roll into this new facility. That's an exchange of paper, not cash. So the remaining lender's principal would stay put. And the idea here is that only interest should be going out. Principal should not be moving at all. And the bank had a piece of internal processing software called FlexCube. Isn't that a fun enterprise software name? So in FlexCube, the easy Way to do this kind of transaction is to pretend to record it like Revlon we're paying off the entire loan. And that triggers the correct interest payment calculations to everyone. You can probably guess what's about to happen next. So you're supposed to send the principal portion to an internal wash account that you own as the bank so that it's booked and recorded correctly, but it never leaves the bank's perimeter. So keep your eye on that wash account. What was supposed to happen is that the boxes labeled, front and Fund and principal should all include the wash account number and should all have a checkbox checked next to them. So unfortunately, it turned out that was what needed to happen, but for various arcane reasons, the boxes were not checked. Checked. And although FlexCube pops up a warning notification that says, uh-oh. Money's about to leave the bank. Are you sure you wanna do this? That was correct. Money was supposed to leave the bank because they were making the interest payments. So the three approvers who were supposed to approve that looked at it and said, yep. That's the right thing that's supposed to And although that morning notification popped up, the human operators carrying out the transaction overrode that. Remember, Revlon was making that interest payment. So the principal never went to the wash account. And instead, FlexCube sent the entire outstanding principal of the loan to all of the 300 lenders, about $900,000,000 instead of $8,000,000. So every lender got the amount that they would have been owed if Revlon had paid the loan in full, but Revlon didn't wanna pay off the loan. It wanted to hold on to its money. That was a great Over the lenders because remember, Revlon was in trouble at the time, so its loans weren't trading at face value. And getting all your money back on a deal that you thought was only worth 60¢ on a dollar is a great deal for you. So they didn't wanna give the money back even after Citi called them and said, please that was a mistake. Give us the money back. And their argument was, we shouldn't have to give the money back because you paid us in full, and that's how loans work. You eventually pay them back. And just because you paid it back at a different time than you were supposed to doesn't mean that we should have to give it back now. And so to prevent that from happen Commercial loan agreements everywhere started including including a clause like that one. So what does a payment error at a bank have to do with AI agents? Well, the bank had this procedure, had these controls, and everybody did what they thought the right thing to do was. That's the problem I wanna talk about for the rest of this talk. Every day, we're giving real agents real autonomy over systems like FlexCube. And how do we prevent accidents like that one from either from happening without locking everything down or just hoping we'll get lucky that they won't happen? So here's the crux of the issue. You can't really know in advance what an agent will do. Right? They're these nondeterministic systems. And that sounds scary until you remember that humans are also nondeterministic systems, and they're gonna make mistakes too. And so most firms don't choose to say, well, in order to reduce the risk of humans making a mistake, we're gonna, like, lock them in rooms and prevent them from talking to each other, and they're all gonna double check everybody else's work. Right? We allow them a certain amount of autonomy along with a certain amount of controls. So we give them boundaries, visibility, and we equip them With systems and controls that let them do their jobs effectively. So in this sort of model, safety and innovation are not opposite ends of a spectrum that you must trade off on. There are things that you can have at the same time. So I think you can have your cake and eat it too. And And when we were thinking about what controls we wanted to apply to agents, we also looked at some approaches that didn't work for us. You don't want a sandbox or lock down everything because a sandbox with no real access to systems is not... Is safe, but it's not very interesting or useful. If you let agents go wild and do whatever they want, that's You know, maybe powerful and freeing from a cognitive perspective, but the isolation is very weak there and their... That approach is generally not suitable for highly regulated enterprises. And then if you just have policy documents that agents look at or that are part of your, specification for the prompts, that's also not very enforceable at run time. You can't guarantee that that will be part of the enforcement controls. So what did work for us was thinking about what mix of controls would get us both safety and innovation. The same time. So how do we provide boundaries and stop problems, but don't hinder folks from operating correctly? So we have a number of these controls, but today I'll talk about five of them. And when I say controls here, what I mean are the guardrails and shared capabilities that let teams move in ways that don't hinder what they're trying to do. And we want to... We don't wanna reach some chasm that we need to cross to to let people get their work done before... And then make everyone wait while we build a bridge to get there. So these controls are composable. Each one does one job. And then together, they let us run agents with real autonomy at an appropriate level of safety. So the first problem is that agents were showing up everywhere. We have big teams with lots of agents running. We have small teams of the few. We have individual people running stuff in an uncontrolled way. And these come in every shape. Could be random chat bots. It could be MPC servers glued together in this Frankenstein hot podge. It could be Well, notebook experiments could be really useful web tools for folks. But it's hard to answer when you look at that, a few simple questions like who owns this, what tools does it have access to, what should it be doing, what should it not be doing? And if you can't answer those kinds of questions, if you can't govern them, then you can't really also reuse that. So you're tempted to build multiple solutions to the same problem if you don't know about what exists already. I mean, the firm can't also govern those in any kind of legible way. So one thing that firms sometimes do here is add some kind of gate. Like don't let anything run until everything is registered and approved and has gone through this very onerous process. And that sounds safe, but if you look at what it does to the work, every idea, even some simple notebook experiment is gonna wait in line behind something that's really risky. And we don't, you know, we don't wanna subject everybody who's given the diversity of agents to exactly the same process. So most people are gonna give up or they'll just get pushed to some shadow IT. Less governed path that is, less visible, and then we don't get to see anything at all. So that's what motivated the first control is an agent registry. You can't govern it. You can't see. So the agent registry makes agents legible, And it registers, retrieves, and discovers the key facts about agents that we want to know for any agent. So those are things like which tools it declares, what endpoints it's gonna talk to, which product does it belong to, who owns it. And humans, other programs, other agents can then use the agent Registry to decide what's available at the firm, whether that's useful for them, and to go use that as a source of truth for other questions. So this doesn't require extra effort on your part. It just happens when you use one of the firm's approved agent building frameworks. It's automatically registered. All that information is recorded there for you. And if you wanna do a manual registration, you can certainly do that. So the second problem we have is that now that we've got all these agents doing all these things, we quickly notice that what they're doing is Really different. And that means our agents carry really different risks. Right? So a thing that summarizes Jira or linear tickets is really different than a production deployment agent that can touch a running system. And if we can use the same... If we try to use the same review process to cover all of these agents, then every agent is waiting in the same queue for weeks for human review. And if people are gonna route around slow processes, then we wind up in the same situation that we had before. So again, you might be tempted to say the answer is something Like, really detailed heavy manual review by all of these different constituencies. Again, that feels safe, but now we've got a trivial summarizer waiting two months for the same sign offs as an agent that is touching production systems. And and most of the good agent ideas, most of the ones that have value right away start out as small experiments, and you don't want those people to wait in the same line as the stuff that's touching production right away. So the reviewers are drowning in these, like, low risk requests, and the high risk ones Have to share that attention pool. So we don't wanna trade away that speed if we can help it. So again, because not every agent needs the same review and because most agents are purpose built rather than open ended... And when I say open ended here, you can imagine coding agents like Pie or Claude Code. When you open them and you start typing, Cloud Code or Py doesn't know what you're about to ask. It doesn't it doesn't circumscribe its purpose in any particular way. But most of the agents that are deployed in enterprises do have very specific purposes. When you're engaged With that agent, it's to do something specific that's well known and well understood. So they have a very specific reason for existing and a very circumscribed purpose. And you can tell these agents apart from each other by looking at what they declare upfront, their tools, the endpoints they access, the controls that are applied to them, etcetera. So the third problem is that if you know about your agents and what they're doing, you'll quickly notice that many agents don't talk to each other. Or sorry, they don't talk to just one Or in just one capacity. The more open ended the agent is, the more it looks like a cloud code or pie, the more it can do a variety and a diversity of different things. Call an internal API, run a tool like a web search, that sort of thing. And each one of those is a different... Opening a different door to a different kind of risk. And if you give an agent an entitlement for a role account, then it can do a lot more damage than something that's just going to read a public web page, for example. So the question is not, can this agent do X. But what's the granularity that we need to solve for for the agent to act successfully? And again, one tempting answer is to kinda be heavy handed here or to give every agent the same short allow list of stuff that's safe to do and then block everything else. That's safe, but it's also useless. An agent that can't, that can't search or can't call an API or can't do any of those things without asking somebody first can't really do the work that it was intended for. And then teams either give up on those agents or Find a way around the wall, and both outcomes are costly. So a wide kind of blanket block on everything trades away the innovation that we wanna preserve and avoids making a real decision about risk. And as author John Shett wrote, a ship in harbor is safe, but that is not what ships are for. So the fix here is to let agents declare their purpose upfront and say what tools they're going to use or what tools they need access to. So in the second column here We might say that a research summarizer is going to be allowed to use a web tool to access research. But for a release deployer agent, we're not going to allow them to do that because they have no reason to use that tool. And so if they try to ask for it, they won't get it by default. So we don't need to make this kind of decision for every tool. The agents just have to say which tools they want. And you're, as the agent author, you're in the best position to say, I need these four things out of the five. 500 that are available. So the way we need to enforce that is that when agents run-in our managed environments, they look at the registry that we talked about before to look up what policies apply to it at initialization time. And that policy gets translated into enforceable statements, like which endpoints are you allowed to access, which hosts are you allowed to access, what other types of resources are available or not available to you. And in this way, nobody's writing a ticket every time they need to change the app. Nobody's going to talk to IT or some other group outside of your team. As long as you conform to the risk score that we talked about before and you're in the agent registry, you're you're governed. You're approved. So this is how we keep the cost to teams really low for deploying, building, running agents. And this same control architecture works in a variety of settings. The next thing we noticed was the teams were building a ton of different ways to evaluate agents, and every stack looks different. And some teams don't build Anything at all. Sometimes you build like this really detailed stack for how your models work. Sometimes, it's... Sometimes there's nothing. And I think in general, we'd be upset if teams were not writing unit tests, right? ## Slides ### 00:00:20 # Claude for Financial Advisors: the orchestrator across the stack <20% of an advisor's time is spent with clients. The rest goes to 10+ disconnected tools. ## LAYER 1 - CONNECTORS **Partner tools calculate** Deterministic numbers from the systems you trust. ## LAYER 2 - SKILLS **Claude orchestrates** Runs each workflow end to end across the tools. ## LAYER 4 ### 00:00:53 # Claude for Financial Advisors: the orchestrator across the stack <20% of an advisor's time is spent with clients. The rest goes to 10+ disconnected tools. ### 00:01:21 # Layer 2 • Skills: eight workflows give time back - Pre-meeting prep - Meeting follow-up - Rebalance review - Alternatives brief - Estate and tax brief ### 00:01:53 # Layer 2 · Skills: eight workflows give time back - Pre-meeting prep - Meeting follow-up - Rebalance review - Alternatives brief - Estate and tax brief - Prospect intake - Advisor onboarding - Compliance review The eight skills that ship with Claude for Financial Advisors. Use them as they come, or adapt them to your firm. ### Keynote **Belinda Neal** Managing Director, Financial Services **Keon Shahab** Applied AI Architect ANTHROPIC [Grid of eight boxes, each with an icon and a workflow title] ### 00:02:20 # Take the frontier to your firm 1. **THE FRONTIER OF INTELLIGENCE** ### One workflow Which use case are you applying the frontier models to? 2. **THE FRONTIER OF ADOPTION** ### One foundation How are you building the agent foundation to scale from a few to many? 3. **APPLIED TO FINANCIAL SERVICES** ### One connector How are you publishing connectors and skills for your users to build on? ### 00:02:50 # AI Engineer ## NEW YORK PRESENTED BY arize [Stylized graphic of a cityscape] [Arize logo] ### 00:03:56 # Important disclosure and disclaimer information This document is being distributed for informational and educational purposes only and is not an offer to sell or the solicitation of an offer to buy any securities or other instruments. ### 00:04:19 # Boring paragraph from a loan agreement ### Section 9.21 Erroneous Payments. If the Agent notifies a Lender that a payment was made in error, the Lender shall return it within two Business Days, with interest at the Federal Funds Rate. Each Lender waives any defense of "**discharge for value**" or any similar doctrine. An erroneous payment does not discharge any Obligation of the Borrower. If a Lender does not return it, the Agent may set off the amount and is subrogated to that Lender's rights. This Section survives the Agent's resignation and the termination of this Agreement. ### 00:04:57 # Boring paragraph from a loan agreement [Screenshot of a legal document section titled "Section 9.21 Erroneous Payments", with the phrase "discharge for value" highlighted.] ### 00:05:25 # Failure of controls: - **Revlon** (Borrower) - **Citibank** (Agent) - **Primary lender group** - **Remaining lenders** ### Balancing ### 00:05:52 # August 11, 2020: the plan Pay everyone their interest. Move no principal. - **Revlon Borrower** - **Citibank Agent: plumbing** - **Primary lender group**: Principal rolls into new facility - **Remaining lenders**: Principal stays in 2016 loan - **Wash account**: Goal: send principal here, disburse interest [Diagram illustrating a financial flow: Revlon (borrower) sends $7.8M interest to Citibank (agent). Citibank then disburses interest to a primary lender group and remaining lenders ### 00:06:24 # The screen [Screenshot of an enterprise software interface displaying financial details and General Ledger (GL) components, with "FRONT", "FUND", and "PRINCIPAL" rows highlighted.] ### 00:06:55 # What the screen needed Three fields needed wash account. Only one set. [Diagram showing three input fields: **FRONT** and **FUND** are marked with a red 'X' for overwrite ### 00:07:25 # One of the biggest blunders in banking history - **Revlon**: Borrower - **Citibank**: Agent (plumbing) - **$893.9M Citi's own money** was sent to the **Primary lender group** (Principal rolls into new facility). - The **Remaining lenders** (Principal stays in 2016 loan) did not receive this money ### 00:07:53 # "One of the biggest blunders in banking history" - Please give the money back - Citibank - Agent: plumbing - Lenders [Diagram showing a request from a speech bubble to Citibank, Citibank responding with a "NO" speech bubble (featuring Bugs Bunny), and Lenders as the recipient of the "NO" response.] ### 00:08:20 # The problem ### 00:08:53 # Is safety a Innovate without permission slips > Too little safety: existential risk. Too little innovation: slow death. ### Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture TWO SIGMA [Diagram showing an "agent" with three question marks, above a balance scale. One side of the scale has a lock icon labeled "Safety", and the other has a lightning bolt icon labeled "Innovation".] ### 00:09:25 # What usually doesn't work - **Sandbox everything** Safer, but an agent's value often comes from what it can touch and combine - **Lock everything down** Very safe but also not very useful; encourages shadow agents you can't see - **Let agents go wild** Gas Town-alikes have poor containerization out of the box, aren't suitable for enterprise use - **Policy docs alone** Helpful for staking a claim, but not enforceable at runtime by themselves [Icon of a sandbox] [Icon of a padlock] [Icon of stacked containers] [Icon of a ### 00:09:52 # What usually doesn't work **Sandbox everything** Safer, but an agent's value often comes from what it can touch and combine **Lock everything down** Very safe but ### 00:10:20 # Five controls ## Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture TWO SIGMA ### 00:10:49 # Problem 1: agent sprawl ### Team A - Robot icon - Terminal icon - Gear icon - Document icon - Chat bubble icon - Flowchart icon - Bug icon - Robot icon ### Team B - Terminal icon - Flowchart icon - Chat bubble icon ### Team C - Document icon ### no team - Bug icon - **Who owns?** - **What tools?** - **What access?** ### Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture TWO SIGMA [Diagram showing three teams (A, B, C) and a 'no team' category, each associated with various icons representing agents, tools, or documents, with questions 'Who owns?', 'What tools?', and 'What access?' below.] ### 00:11:19 # Problem 1: agent sprawl - **Team A** - **Team B** - **Team C** - **no team** - Who owns? - What tools? - What access? [Diagram illustrating agent sprawl, with icons representing different agents or tools grouped under "Team A", "Team B", "Team C", and "no team". Below the groups are three questions: "Who owns?", "What tools?", "What access?"] ### 00:11:46 # Wrong control: register every agent up front - Every idea, even prototypes - Ideas abandoned - Register first - Review queue - Runtime - Few ship, late ### Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture TWO SIGMA [Flowchart showing a process where many ideas (represented by various icons) go into a "Register first" review queue, leading to "Ideas abandoned" or a "Runtime" with "Few ship, late"] ### 00:12:21 # Control: Agent Registry, automatic front door - Agent Registry - Risk Factor Scoring - Activity Controls - Evaluations - Auto Mode Classifiers An **Agent** provides: - bound endpoints - declared tools - metadata The **Agent Registry** registers, retrieves, and discovers key information about agents, tools, and dependencies. The **Product Catalog** ties agents to related products. The system is usable interactively, programmatically, and agentically by humans and other agents. --- ### Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture 2σ TWO SIGMA [Flow diagram illustrating an Agent Registry system, showing inputs from an Agent (bound endpoints, declared tools, metadata) flowing into the Agent Registry, which then connects to a Product Catalog. The Agent Registry is also depicted as interacting with humans (person icon) and other agents (robot icon).] ### 00:12:48 # Control: Agent Registry, automatic front door Key components: Agent Registry, Risk Factor Scoring, Activity Controls, Evaluations, Auto Mode Classifiers An **Agent** is defined by: ### 00:13:23 ## Problem 2: one-size review risk - summarizer - doc-drafter - prod-deployer - weeks - Review - Production - route around [Flowchart illustrating a "one-size review" process where three components (summarizer, doc-drafter, prod-deployer) with varying risk levels feed into a "Review" stage taking weeks before going to "Production", with a "route around" bypassing review for the prod-deployer.] ### 00:13:51 # Wrong control: committee review for every agent ## Trivial Agent Process Flow A "trivial agent" (summarizer) goes through the following stages: - **summarizer** - **Security** (adds 2 weeks) - **Legal** (adds 2 weeks) - **Risk** (adds 2 weeks) - **Committee** (adds 2 weeks) - **Production** Total time to ship: **8+ weeks** [Flowchart showing a sequential review process for a "trivial agent" (summarizer) through Security, Legal, Risk, and Committee stages, each adding 2 weeks, before reaching Production, totaling 8+ weeks.] ### 00:14:20 # Control: Risk scoring applies differentiated scrutiny - Agent Registry - **Risk Factor Scoring** - Activity Controls - Evaluations - Auto Mode Classifiers - Agents auto-registered on creation - Scored at registration and on each update, by tools requested, purpose, and systems touched - Very high-risk agents may be flagged before publishing Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture TWO SIGMA [Diagram illustrating a risk scoring workflow for AI agents. A group of people "register or update" an "Agent Registry" which contains a "Risk Assessor" with a "Scoring" component. This scoring interacts with a database. After scoring, a "Validate risk score" step occurs, which also interacts with the database. Finally, the agents are "publish"ed.] ### 00:14:53 ## Control: Risk scoring applies differentiated scrutiny - Agent Registry - **Risk Factor Scoring** - Activity Controls - Evaluations - Auto Mode Classifiers - Agents auto-registered on creation ### 00:15:18 # Problem 3: differentiated access - **Agent** connects to: - **Role account**: `svc-reports`, `svc-trading`, `svc-etl`, ... - **API endpoint**: `GET /orders`, `POST /trades`, ... - **Agent tool**: `web_search`, `run_sql`, ... - **Other agent**: `summarizer`, `planner`, ... - **Data store**: `orders_db`, `research_lake`, ... - **External web**: `*.example.com`, `api.vendor.io`, ... [Diagram showing a central "Agent" box with arrows pointing to six different types of external resources or services, each with an icon and example names.] ### 00:15:50 ## Wrong control: block all outbound access - Role account: `svc-reports, svc-trading, svc-etl, ...` - API endpoint: `GET /orders, POST /trades, ...` - Agent tool: `web_search, run_sql, ...` - Other agent: `summarizer, planner, ...` - Data store: `orders_db, research_lake, ...` - External web: `*.example.com, api.vendor.io, ...` [Diagram showing an "Agent" within a "Block all outbound" boundary, with all attempted connections to external services (Role account, API endpoint, Agent tool, Other agent, Data store, External web) being blocked by red 'X' marks. The boundary is labeled "Safe, but useless".] ### 00:16:19 # Wrong control: block all outbound access - **Agent** (blocked all outbound access) - Role account: `svc-reports`, `svc-trading`, `svc-etl`, ... - API endpoint: `GET /orders`, `POST /trades`, ... - Agent tool: `web_search`, `run_sql`, ... - Other agent: `summarizer`, `planner`, ... - Data store: `orders_db`, `research_lake`, ... - External web: `*.example.com`, `api.vendor.io`, ... [Diagram showing an 'Agent' box with all outbound connections to various external resources (Role account, API endpoint, Agent tool, Other agent, Data store, External web) blocked by red 'X' marks. The agent box is labeled "Block all outbound" and "Safe, but useless".] ### 00:16:49 # Fix: access depends on resource and agent purpose - **summarizer** - purpose: research - **deployer** - purpose: release ops Same tool, different answer [Diagram showing a matrix of permissions. Rows are agent types: "summarizer" and "deployer". Columns are resource types: "Agent tool", "External web", "Data store", "API endpoint", "Other agent", "Role account". Cells indicate access as "Allow", "Deny", or "Gated".] ### 00:17:19 # Control: Activity controls - Agent Registry - Risk Factor Scoring - **Activity Controls** - Evaluations - Auto Mode Classifiers ### Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture, TWO SIGMA [Diagram illustrating a system architecture with components: Agent Registry, Compute Platform, Agent Instance, and Egress Proxy within a container environment. The Egress Proxy routes traffic to either a Blocked Destination (with a "Blocked!" label) or an Approved Destination.] ### 00:17:49 # Control: Activity controls - Agent Registry - Risk Factor Scoring - **Activity Controls** - Evaluations - Auto Mode Classifiers Balancing Acceleration and Safety for AI Agents John Feminella / SVP Architecture TWO SIGMA [Diagram illustrating a system architecture with components like Agent Registry, Compute Platform, Agent Instance, and Egress Proxy, showing how the Egress Proxy blocks traffic to a "Blocked Destination" and allows it to an "Approved Destination" within a container environment.]