# How to Build Security and Trust in an Agent-Native Stack

## Abstract

Key takeaways Understand why securing agentic systems is a whole-stack problem—not a model-level fix. Map six failure patterns emerging in production agent deployments: unclear boundaries, standing access, data-as-control, first-call effects, cascading delegation, and late-arriving evidence. Unpack an architectural principle—above proposes, below decides and enforces—and the design rules that follow. Learn to apply concrete controls: just-in-time access, effect checking at the acting system, isolation, fast revocation, and safe-state fallback. Explore why interoperability across model providers, cloud platforms, and enterprise infrastructure requires shared open standards for agent identity, delegation, authorization, and audit. This work is happening within the Open Secure AI Alliance.

## AI Summary

- Presented the OpenShell reference architecture, a secure runtime for AI agents, emphasizing the need for a trust layer and a full-stack solution to manage agent security, safety, and governance.
- Highlighted the challenges of agent drift due to ambiguity, friction, and lack of resources, and explained how OpenShell mitigates these issues by enforcing policies and providing a zero-trust environment.
- Demonstrated how the combination of OpenShell and Sentry, running on NVIDIA BlueField 4, ensures deterministic controls and real-time memory introspection, preventing agents from exceeding global policies or falsifying logs.
- Emphasized the importance of an open and community-driven approach, with contributions from over 100 partners, to build a robust and verifiable security framework for AI agents.
- Showed a demo of how OpenShell and Anthropic's Cloud Managed Agents work together to maintain data sovereignty and ensure agents stay within their runtime boundaries.
- Discussed future plans for broader assurance, safer fleets, and portable enforcement, ensuring continuous risk assessment and trust in agent operations.

## Transcript

**[00:00:08 – 00:00:10]** Hi, everyone. Thanks for coming.

**[00:00:10 – 00:00:11]** I'm Ali.

**[00:00:11 – 00:00:12]** I'll start us off.

**[00:00:12 – 00:00:15]** So, what we're going to talk about today is OpenShell

**[00:00:15 – 00:00:16]** reference architecture.

**[00:00:16 – 00:00:18]** Those of you who saw the keynote, you probably saw

**[00:00:18 – 00:00:21]** some of the discussions that came up during the keynote.

**[00:00:21 – 00:00:24]** And what we want to really talk about here is how, over

**[00:00:24 – 00:00:27]** the last year at NVIDIA, we started thinking about agent security,

**[00:00:27 – 00:00:31]** safety, and really how this shaped our thinking around creating the

**[00:00:31 – 00:00:33]** OpenShell reference architecture.

**[00:00:33 – 00:00:37]** So maybe an analogy I'll use is that as we started to think

**[00:00:37 – 00:00:40]** about this, one of the things that became very apparent to us was

**[00:00:40 – 00:00:42]** agents really need a trust layer.

**[00:00:42 – 00:00:44]** And the way we thought about this is that very similar

**[00:00:44 – 00:00:46]** to the 90s, agents feels like that's sort of where they

**[00:00:46 – 00:00:48]** were as far as the web goes.

**[00:00:48 – 00:00:50]** In the 90s, the web was exciting, you can do a lot of stuff,

**[00:00:50 – 00:00:52]** you can have a lot of sort of websites, but they were

**[00:00:52 – 00:00:54]** all run directly on your machine.

**[00:00:54 – 00:00:56]** A lot of exposure, a lot of risk.

**[00:00:56 – 00:00:59]** It wasn't really until the 2000s when you had sort of an entire

**[00:00:59 – 00:01:00]** layer of trust come on, right?

**[00:01:00 – 00:01:02]** You could see sort of the lock showing up.

**[00:01:02 – 00:01:05]** You can see HTTPS, isolation of tabs, and what this did

**[00:01:05 – 00:01:08]** is really gave a rise to an entire new category of companies,

**[00:01:09 – 00:01:12]** commerce, transactions, and sort of safety that came about.

**[00:01:12 – 00:01:14]** And as we thought about it, we realized that one, this

**[00:01:14 – 00:01:18]** layer is missing from the agents currently and from AI.

**[00:01:18 – 00:01:21]** Two, that is actually what gives trust for commercial

**[00:01:21 – 00:01:23]** businesses to actually transact.

**[00:01:23 – 00:01:26]** And third, it really needs to be as open as possible,

**[00:01:26 – 00:01:28]** because if it's open, it's visible, you can verify it,

**[00:01:28 – 00:01:31]** you can trust it, you can extend it, and you can build on top of it.

**[00:01:31 – 00:01:33]** So that's really sort of where a lot of our thinking

**[00:01:34 – 00:01:35]** originally started.

**[00:01:35 – 00:01:38]** Now, to give you kind of a timeline of how we got here, we started

**[00:01:38 – 00:01:42]** working on OpenShell, which is the software runtime component of

**[00:01:42 – 00:01:45]** this particular OpenShell runtime architecture, about a year ago.

**[00:01:46 – 00:01:49]** At our GTC San Jose, which was in March, we released an early

**[00:01:49 – 00:01:52]** access version of this and started working with a lot of our partners.

**[00:01:52 – 00:01:55]** There's a slide at the end which we'll talk about.

**[00:01:55 – 00:01:58]** But we started building OpenShell from the very beginning open

**[00:01:58 – 00:02:00]** source, so Apache 2.0.

**[00:02:00 – 00:02:04]** It is contributed to by roughly about 100 plus community partners

**[00:02:04 – 00:02:05]** of ours, which we'll talk about.

**[00:02:06 – 00:02:09]** And everything we've done so far has been in the open.

**[00:02:09 – 00:02:11]** Over the last nine months, we've really sort of worked

**[00:02:11 – 00:02:13]** very hard to be able to get it to a point where it is

**[00:02:13 – 00:02:17]** stable, it is scalable, and is mature enough for organizations to

**[00:02:17 – 00:02:21]** actually build their own workflows and workloads on top of it.

**[00:02:21 – 00:02:25]** Roughly about a month ago, we released sort of the stable

**[00:02:25 – 00:02:27]** 0.1.0 release of OpenShell.

**[00:02:27 – 00:02:31]** At this GTC, we are announcing the OpenShell reference architecture,

**[00:02:31 – 00:02:35]** which is really how we think about a full-stack solution.

**[00:02:35 – 00:02:38]** So as we thought about agent security, and we'll talk about

**[00:02:38 – 00:02:41]** this in a later slide, is we really looked at the full-stack

**[00:02:41 – 00:02:44]** and said, How can you take controls and move them from

**[00:02:44 – 00:02:47]** application to runtime to hardware to create a full-stack solution?

**[00:02:47 – 00:02:49]** And that's really what we're going to talk about today,

**[00:02:49 – 00:02:52]** Ophir and I, and really sort of walk you through our thinking, our

**[00:02:52 – 00:02:54]** logic, and what we've done so far.

**[00:02:54 – 00:02:56]** And really what you see sort of going forward until next

**[00:02:56 – 00:02:59]** April is how we now think about taking this runtime, which is

**[00:02:59 – 00:03:03]** OpenShell, and really integrating it further into Sentry, BlueField

**[00:03:03 – 00:03:07]** 4, and making it a full-stack solution that anybody can use.

**[00:03:08 – 00:03:11]** So we've talked a lot about Agents being a new computing platform,

**[00:03:11 – 00:03:14]** but the main thing I want to sort of talk about here is that as we

**[00:03:14 – 00:03:17]** started to build this, one of the things we realized that changed was

**[00:03:17 – 00:03:19]** when you go from a retrieval-based system to a generative-based

**[00:03:19 – 00:03:22]** system, essentially a lot of the traditional

**[00:03:22 – 00:03:24]** controls end up breaking.

**[00:03:24 – 00:03:28]** And the thing that sort of made this even more of an exacerbated

**[00:03:28 – 00:03:32]** problem is introduction of Agents, so going from really discussion

**[00:03:32 – 00:03:35]** and chats to doing, and then along the way we started to see

**[00:03:35 – 00:03:37]** sort of multiple step functions.

**[00:03:37 – 00:03:39]** One of the other step functions that we started to see was

**[00:03:39 – 00:03:41]** obviously long horizon agents.

**[00:03:41 – 00:03:43]** So the longer you run an agent, obviously the complexity,

**[00:03:43 – 00:03:45]** the entropy, and the risk grows.

**[00:03:45 – 00:03:47]** And then sort of the final stepping stone and a step

**[00:03:47 – 00:03:50]** function that we saw was really fleets of agents, right?

**[00:03:50 – 00:03:52]** Agents being able to work together.

**[00:03:52 – 00:03:54]** Agents working together create a new set of risks.

**[00:03:54 – 00:03:58]** And one of the very basic things that I'll point out is if you

**[00:03:58 – 00:04:01]** have global policies, you typically write global policies, they

**[00:04:01 – 00:04:03]** might be bound to a single agent.

**[00:04:03 – 00:04:06]** But if you have fleets of agents, their combined capabilities

**[00:04:06 – 00:04:09]** might create unintended paths that actually supersede

**[00:04:09 – 00:04:10]** your global policies.

**[00:04:10 – 00:04:14]** So these types of stack functions, long horizon, working together,

**[00:04:14 – 00:04:18]** complexity, entropy, and scale, really created a dynamic where

**[00:04:18 – 00:04:20]** we thought about it more and more, and what we realized

**[00:04:20 – 00:04:23]** is you really need to build an AI-native software stack.

**[00:04:23 – 00:04:26]** So if you rethink the software stack and think about it from

**[00:04:26 – 00:04:29]** the context of how do you control, how do you manage

**[00:04:29 – 00:04:33]** agents, AI, and how they operate versus traditional software,

**[00:04:33 – 00:04:34]** you really need to rethink it.

**[00:04:34 – 00:04:37]** And the analogy I'll use here is that, you know, when we went,

**[00:04:37 – 00:04:41]** for example, from using monolithic applications in VMs to cloud-native

**[00:04:41 – 00:04:44]** technologies, initially, we saw this a lot, right?

**[00:04:44 – 00:04:46]** Like, people would take a monolithic application, shove

**[00:04:46 – 00:04:48]** it into a container, and sort of their main question was

**[00:04:48 – 00:04:51]** like, well, why isn't the container boundary as hard as a VM?

**[00:04:51 – 00:04:53]** And eventually what we did is we redesigned, right?

**[00:04:53 – 00:04:56]** We built microservices, we built immutable, we built ephemeral.

**[00:04:56 – 00:04:59]** And as a result, that redesign ended up changing

**[00:04:59 – 00:05:00]** the security posture.

**[00:05:00 – 00:05:02]** How you deal with an ephemeral, immutable infrastructure

**[00:05:02 – 00:05:04]** from a security standpoint is very different how you

**[00:05:05 – 00:05:07]** deal with a stateful, monolithic application in a VM.

**[00:05:08 – 00:05:10]** And we are really at the same inflection points with agents,

**[00:05:10 – 00:05:14]** which is we need to think about a redesign of the system.

**[00:05:14 – 00:05:16]** So as we thought about this more and more, one natural

**[00:05:16 – 00:05:19]** thing that popped up is, over the last five years as we've

**[00:05:19 – 00:05:22]** been building models, agents, harnesses, as they've been

**[00:05:22 – 00:05:26]** working with tools, data, and other systems, all of this has

**[00:05:26 – 00:05:28]** been done at the application layer.

**[00:05:28 – 00:05:30]** So we thought about this more and more and we said, well,

**[00:05:30 – 00:05:34]** the problem you have here is, agents don't really distinguish

**[00:05:34 – 00:05:37]** what is allowed for them versus what they have open to them versus

**[00:05:37 – 00:05:38]** what is closed because of a policy.

**[00:05:38 – 00:05:41]** They just see friction versus no friction.

**[00:05:41 – 00:05:44]** So if you have controls, if you have governance, if you

**[00:05:44 – 00:05:47]** have any type of policy that lives at a layer where the

**[00:05:47 – 00:05:51]** agent can reason about it, can see it, can choose to bypass it, if

**[00:05:52 – 00:05:55]** it can choose to say, well, if this creates friction for me, I can find

**[00:05:55 – 00:05:58]** other ways around it, it doesn't create a line, basically, that an

**[00:05:58 – 00:06:02]** organization can set and be ensured that nothing can cross that.

**[00:06:02 – 00:06:04]** So as we thought about this, we sort of took the view of

**[00:06:04 – 00:06:08]** how do you put this probabilistic system in a deterministic

**[00:06:08 – 00:06:10]** environment that can control it?

**[00:06:10 – 00:06:12]** So really, where do you draw that deterministic line to

**[00:06:12 – 00:06:16]** ensure whatever you put below that is not bypassable, is

**[00:06:16 – 00:06:19]** verifiable, and it is not a choice for the agent to follow?

**[00:06:19 – 00:06:21]** And essentially, the way I think about it is how do you

**[00:06:21 – 00:06:24]** force alignment to the things you care about and not leave

**[00:06:24 – 00:06:27]** that as an option for the agent to reason about?

**[00:06:27 – 00:06:30]** So this is really the stack that we thought about, which

**[00:06:30 – 00:06:31]** is, you have the application layer.

**[00:06:31 – 00:06:34]** This is where the models run, the harnesses, the agents, the tool.

**[00:06:34 – 00:06:38]** And at this stage, what you really want to do is leave that

**[00:06:38 – 00:06:40]** layer as encumbered as possible.

**[00:06:40 – 00:06:42]** You want to remove as much friction, as much

**[00:06:42 – 00:06:45]** controls as possible, so the agents can be creative.

**[00:06:45 – 00:06:47]** They're incredibly great problem solvers, right?

**[00:06:47 – 00:06:50]** And what you really want them to do is solve business problems.

**[00:06:50 – 00:06:53]** And what we sort of thought about is, well, how do you

**[00:06:53 – 00:06:55]** take this and offload some of those controls into the

**[00:06:55 – 00:06:59]** runtime layer and create isolation and governance at that layer?

**[00:06:59 – 00:07:02]** Now, nothing existed that we could use there, and we'll talk a little

**[00:07:02 – 00:07:05]** bit about sort of traditional sandboxing in the later slides.

**[00:07:05 – 00:07:07]** But as we thought about this more and more and we saw the

**[00:07:07 – 00:07:13]** advancements in model capabilities, especially in agentic fleets, the

**[00:07:13 – 00:07:17]** sort of next natural realization we had is, well, the same controls

**[00:07:17 – 00:07:19]** that we took from the application layer, the model, or the harness

**[00:07:19 – 00:07:22]** and we offloaded into runtime really need to be offloaded further

**[00:07:23 – 00:07:26]** into hardware because a runtime and OpenShell is still software;

**[00:07:26 – 00:07:30]** so if you have a sufficiently advanced model or a potential risk,

**[00:07:30 – 00:07:32]** it can still take advantage, break out of a software environment,

**[00:07:32 – 00:07:35]** find bugs, find vulnerabilities, and basically move out.

**[00:07:35 – 00:07:38]** So how do you move that further into an environment where

**[00:07:38 – 00:07:41]** you have millisecond responses, where you have full visibility?

**[00:07:41 – 00:07:42]** If you have visibility, you can verify.

**[00:07:42 – 00:07:44]** If you can verify, you can trust.

**[00:07:44 – 00:07:46]** And that's where we came up with the full stack solution,

**[00:07:46 – 00:07:48]** which we're gonna talk about today.

**[00:07:48 – 00:07:50]** And as part of this, a lot of our thinking was really

**[00:07:50 – 00:07:54]** around the fact that this needs to be as open as possible.

**[00:07:54 – 00:07:57]** So the first part of this is really the OpenShell environment

**[00:07:57 – 00:07:58]** that we talked about.

**[00:07:58 – 00:08:01]** OpenShell is a secure runtime for agents.

**[00:08:01 – 00:08:04]** It is completely agnostic and unopinionated about what you run

**[00:08:04 – 00:08:07]** in it and where you run it, meaning you can run any agent, any harness,

**[00:08:07 – 00:08:12]** any tooling inside it, and we don't really care how you run it.

**[00:08:12 – 00:08:15]** All we care about is how it is configured and how it comes up.

**[00:08:15 – 00:08:17]** And I'll sort of get into that a little bit later.

**[00:08:17 – 00:08:19]** And as we did this, we realized that there needs

**[00:08:19 – 00:08:20]** to be further offloads.

**[00:08:21 – 00:08:23]** So this is where Sentry comes in that Ophir is going to talk

**[00:08:23 – 00:08:26]** about, which is Sentry is really the part that allows us to be

**[00:08:26 – 00:08:31]** able to do out-of-band enforcement, visibility, and introspection.

**[00:08:31 – 00:08:33]** So think of it as really a two-box solution, right?

**[00:08:33 – 00:08:36]** Where the controls, the enforcement, is completely

**[00:08:36 – 00:08:40]** outside the reach of the agent or the environment

**[00:08:40 – 00:08:41]** that this compute is being done.

**[00:08:41 – 00:08:45]** And then further, how do you actually run LLMs on top of

**[00:08:45 – 00:08:47]** an infrastructure where you can have further visibility

**[00:08:47 – 00:08:50]** into their thinking, into their logic, into their reasoning?

**[00:08:50 – 00:08:52]** So this is the reference architecture that we refer

**[00:08:52 – 00:08:55]** to when we're talking about it at this particular GTC,

**[00:08:55 – 00:08:58]** which is how do you build this layered defense system, right?

**[00:08:58 – 00:09:01]** Like those of us who have been in security have always known

**[00:09:01 – 00:09:03]** this, that what you really talk about and what you really want is

**[00:09:03 – 00:09:05]** a layered defense approach, right?

**[00:09:05 – 00:09:09]** Like redundancies, offloading, and basically having redundancies

**[00:09:09 – 00:09:13]** in the system that can anticipate and be able to be put into place

**[00:09:13 – 00:09:14]** if there are escalating attacks.

**[00:09:14 – 00:09:18]** And this is really where OpenShell and Sentry fit together.

**[00:09:18 – 00:09:22]** So on that, let's talk a little bit about the types of threats

**[00:09:22 – 00:09:24]** and risks that we've learned about over the last year as

**[00:09:24 – 00:09:26]** we've been building Sentry, as we've been building OpenShell,

**[00:09:26 – 00:09:29]** and experimenting with agents.

**[00:09:29 – 00:09:31]** And there are a few things we're going to talk about,

**[00:09:31 – 00:09:36]** which is we think a lot about what causes an agent to drift, right?

**[00:09:36 – 00:09:39]** And drift can be many things, but ultimately what we are looking

**[00:09:39 – 00:09:44]** for are, what are environmental conditions that, if presented,

**[00:09:44 – 00:09:47]** cause the agent to basically break away from the original intent,

**[00:09:48 – 00:09:51]** because rather than trying to focus on the problem you gave it, it has

**[00:09:51 – 00:09:55]** ran into some sort of a blocker, and it is now causing it to reason

**[00:09:55 – 00:09:57]** or trying to solve a different problem, and that gradually

**[00:09:57 – 00:09:59]** starts to cause it to shift.

**[00:09:59 – 00:10:02]** So, ambiguity was one of the first things we came up and

**[00:10:02 – 00:10:05]** we realized, which is, if you tell an agent to go solve a problem,

**[00:10:05 – 00:10:08]** but you are not incredibly specific and deliberate about how you

**[00:10:08 – 00:10:12]** want it to solve that problem, it will go off and eventually start to

**[00:10:12 – 00:10:16]** drift and try to solve that problem in any shape or form it can.

**[00:10:16 – 00:10:18]** And some of the good examples we saw are some of the breaches

**[00:10:18 – 00:10:21]** or some of the incidents we saw the labs announce, which some of that

**[00:10:21 – 00:10:25]** was actually rooted in the lack of clarity or specificity as how

**[00:10:25 – 00:10:28]** they wanted the agent to operate.

**[00:10:28 – 00:10:29]** Another one that we saw is friction.

**[00:10:29 – 00:10:32]** Now, this is actually the original intent and the reason

**[00:10:32 – 00:10:36]** why we built OpenShell, because what we saw was the more and more

**[00:10:36 – 00:10:39]** controls, policies, governance, and blockage you put in the

**[00:10:39 – 00:10:43]** runtime in the application layer where the agent had to figure

**[00:10:43 – 00:10:47]** out how to get around it, it would eventually really cause it to drift

**[00:10:47 – 00:10:49]** significantly and quite quickly.

**[00:10:49 – 00:10:53]** So this was one of the real reasons we thought about OpenShell

**[00:10:53 – 00:10:56]** and to how do you take some of those controls, offload them

**[00:10:56 – 00:10:59]** into the runtime, and allow the agent to be able to operate on the

**[00:10:59 – 00:11:02]** original path rather than trying to solve for all these blockers

**[00:11:02 – 00:11:04]** that are coming up in its way.

**[00:11:04 – 00:11:07]** And this is one of the friction, the friction point is one

**[00:11:07 – 00:11:09]** of the main things that we've also worked with a lot of our

**[00:11:09 – 00:11:13]** cybersecurity partners, because as we started to see this, we realized

**[00:11:13 – 00:11:17]** that a lot of the environments where agents are operating

**[00:11:17 – 00:11:20]** and at the application layer because they're not designed for

**[00:11:20 – 00:11:23]** the agent, they don't distinguish their response to the agent

**[00:11:23 – 00:11:24]** versus, for example, to a human.

**[00:11:24 – 00:11:27]** So when an agent gets a blockage, all they see that

**[00:11:27 – 00:11:28]** as a problem, right?

**[00:11:28 – 00:11:29]** They're like, oh, I have a problem.

**[00:11:29 – 00:11:31]** I have to go figure out a different way around this.

**[00:11:31 – 00:11:35]** If I can't do, for example, a git commit, I might use curl or wget.

**[00:11:35 – 00:11:38]** Now the agent realizes I have other tools at my disposal.

**[00:11:38 – 00:11:40]** And that eventually starts to create a cascading effect

**[00:11:40 – 00:11:44]** and it basically ripples down how they solve the rest of the problem.

**[00:11:44 – 00:11:46]** The other problem is really lack of resources.

**[00:11:46 – 00:11:50]** So what we saw is that when you train, you know, pre-train,

**[00:11:50 – 00:11:52]** post-train RL models, you typically do it with a lot

**[00:11:52 – 00:11:53]** of tools around them.

**[00:11:53 – 00:11:55]** But when you deploy these agents or models, they are

**[00:11:56 – 00:11:58]** not preppy to some of the tools they were actually trained with.

**[00:11:58 – 00:12:01]** So when they run in an environment without them, for example,

**[00:12:01 – 00:12:03]** when you start them in a sandbox, or if you start them in OpenShell,

**[00:12:03 – 00:12:05]** or if you just run them on incumbent, typically some of

**[00:12:05 – 00:12:08]** those things that they were trained with is not available to them.

**[00:12:08 – 00:12:11]** So missing tools or resources was another real sort of

**[00:12:11 – 00:12:14]** significant reason we saw agents starting to drift.

**[00:12:14 – 00:12:17]** And as we put a lot of these things together, we realize

**[00:12:17 – 00:12:22]** basically that the culmination of these effects, friction, ambiguity,

**[00:12:22 – 00:12:25]** lack of tooling and resourcing because you're trying to limit

**[00:12:25 – 00:12:29]** the reach and the blast radius of that agent, ultimately all cascade

**[00:12:29 – 00:12:31]** into these constant failures.

**[00:12:31 – 00:12:34]** And these constant failures is what we found is when agents

**[00:12:34 – 00:12:38]** not only drift, but the fleets of agents start to collaborate

**[00:12:38 – 00:12:40]** to solve problems that one or the other couldn't solve.

**[00:12:40 – 00:12:45]** So failures ultimately actually create a fleet drift because

**[00:12:45 – 00:12:47]** they try to collaborate and solve for these particular problems.

**[00:12:47 – 00:12:50]** And one of the common failures that we see that causes fleets

**[00:12:50 – 00:12:53]** of agents to drift and sort of try to problem-solve together

**[00:12:53 – 00:12:55]** is internet access.

**[00:12:55 – 00:12:57]** If one can't access, how do you actually go about and,

**[00:12:57 – 00:12:59]** for example, work with other agents and solve for that?

**[00:12:59 – 00:13:03]** And we've seen that in some of the more recent, obviously, news.

**[00:13:03 – 00:13:08]** So in traditional sandboxing, we've seen a number of failures,

**[00:13:08 – 00:13:11]** and I think it's probably worthwhile highlighting why,

**[00:13:11 – 00:13:14]** when we think about OpenShell, we don't really think about

**[00:13:14 – 00:13:15]** it in the context of sandboxing.

**[00:13:15 – 00:13:18]** Because sandboxing in its traditional terms really has

**[00:13:18 – 00:13:19]** a couple of objectives.

**[00:13:19 – 00:13:21]** Sandboxing is meant to keep things in or out.

**[00:13:21 – 00:13:25]** That level of sort of boundary is actually not designed for

**[00:13:25 – 00:13:28]** agents because agents need to be able to bring things in and need

**[00:13:28 – 00:13:31]** to be able to sort of communicate and go out of that environment.

**[00:13:31 – 00:13:35]** So the typical isolation format that a sandbox presents is

**[00:13:35 – 00:13:39]** really not suitable for what modern agents, and especially

**[00:13:39 – 00:13:41]** fleets of agents, need to do.

**[00:13:41 – 00:13:44]** And the other way to think about sandboxing is sandboxing

**[00:13:44 – 00:13:47]** is a really good environment for a single agent to do a

**[00:13:47 – 00:13:49]** single unit of compute or work.

**[00:13:49 – 00:13:52]** It is not a place where you want fleets of agents to work together,

**[00:13:52 – 00:13:55]** because then you naturally have to start opening things more

**[00:13:55 – 00:13:58]** and more, or you have to take a more sort of a blacklisted approach

**[00:13:58 – 00:13:59]** and start locking things down.

**[00:14:00 – 00:14:03]** So ultimately what we saw is this sort of went to really sort

**[00:14:03 – 00:14:07]** of confirm that existing legacy and traditional infrastructure and

**[00:14:07 – 00:14:09]** tooling was not enough for agents.

**[00:14:09 – 00:14:11]** And majority of the things we talked about, right, whether

**[00:14:11 – 00:14:14]** you talk about friction, whether you talk about resourcing,

**[00:14:14 – 00:14:19]** ambiguity, ultimately all these things are a microcosm of the fact

**[00:14:19 – 00:14:22]** that you are taking an extremely advanced piece of technology

**[00:14:22 – 00:14:24]** and you're trying to force it to operate in an environment

**[00:14:24 – 00:14:26]** that was just not designed for it.

**[00:14:26 – 00:14:29]** Most of the infrastructure, environment, tooling that

**[00:14:29 – 00:14:32]** we have was just simply not designed for agents.

**[00:14:32 – 00:14:36]** So we took this stack, we started to configure it, build policies,

**[00:14:36 – 00:14:38]** runtime controls, instrument, and say, well, we're gonna

**[00:14:38 – 00:14:41]** lock this down as much as possible.

**[00:14:41 – 00:14:43]** I mean, locking down doesn't work, we all know that, and

**[00:14:43 – 00:14:45]** this is where we started to see a lot of misbehavior,

**[00:14:45 – 00:14:47]** especially over the recent months.

**[00:14:47 – 00:14:50]** So this is where OpenShell enforces new boundaries, and

**[00:14:50 – 00:14:53]** let me sort of highlight really what is in OpenShell.

**[00:14:53 – 00:14:56]** So OpenShell as a secure runtime has a few different primitives,

**[00:14:56 – 00:14:59]** and it's all built around first principles.

**[00:14:59 – 00:15:02]** One is, as we thought about an agent-native software stack, our

**[00:15:02 – 00:15:05]** view was that at the lowest level, an agent should never be able to

**[00:15:05 – 00:15:08]** talk directly to your host, to your network, to your infrastructure.

**[00:15:08 – 00:15:11]** So it should start in an isolated environment.

**[00:15:11 – 00:15:13]** We can sort of call it a sandbox, but we really think

**[00:15:13 – 00:15:15]** about it in OpenShell as looking at an independent

**[00:15:15 – 00:15:17]** boundary for every agent.

**[00:15:17 – 00:15:19]** When an agent starts in that environment, in this sandbox

**[00:15:19 – 00:15:23]** in OpenShell, it starts with a zero-trust model, so it's

**[00:15:23 – 00:15:25]** actually given no permissions.

**[00:15:25 – 00:15:28]** And what ends up happening is the global policies your

**[00:15:28 – 00:15:31]** organization has gets actually condensed down, and the agent

**[00:15:31 – 00:15:35]** can see those and reason about which one of these does it

**[00:15:35 – 00:15:37]** actually need to do its job.

**[00:15:37 – 00:15:41]** When it selects those policies, then OpenShell's policy prover,

**[00:15:41 – 00:15:44]** which is actually based on formal method, so it's a mathematical

**[00:15:44 – 00:15:47]** verification, it's an SMT solver, goes through that policy and

**[00:15:48 – 00:15:53]** confirms that this policy does not somehow exceed your global intent

**[00:15:53 – 00:15:56]** as to what is allowed or disallowed for that particular agent.

**[00:15:56 – 00:15:59]** The reason we do this is, one, it's not an LLM as a judge.

**[00:15:59 – 00:16:00]** It's not a probabilistic system.

**[00:16:00 – 00:16:03]** It's not recommending policies.

**[00:16:03 – 00:16:06]** All it's doing is verifying that the policies that this agent

**[00:16:06 – 00:16:10]** requested does not exceed or break the intent of your organization.

**[00:16:10 – 00:16:13]** And the reason this is important is, running things like formal

**[00:16:13 – 00:16:15]** methods is roughly three orders of magnitude more performant

**[00:16:15 – 00:16:18]** than running something like an LLM as a judge.

**[00:16:18 – 00:16:21]** The reason this is incredibly important is this allows us

**[00:16:21 – 00:16:24]** to run agent in a least privilege mode all the time.

**[00:16:24 – 00:16:27]** And once one unit of compute is done, we can revoke everything

**[00:16:27 – 00:16:29]** and reset it for the next one.

**[00:16:29 – 00:16:32]** So this ultimately ensures that as an agent progresses

**[00:16:32 – 00:16:36]** in a long horizon mode, it is not compounding risk by credentials,

**[00:16:36 – 00:16:39]** state, sessions, access.

**[00:16:39 – 00:16:42]** The other part of it is you naturally want to be able

**[00:16:42 – 00:16:45]** to keep all credentials, secrets, tokens out of the agent's path.

**[00:16:45 – 00:16:48]** You do not want an agent to have access to those.

**[00:16:48 – 00:16:50]** So every time OpenShell brings up an agent in a sandbox,

**[00:16:50 – 00:16:53]** there's a gateway, there's a supervisor, and the gateway and the

**[00:16:53 – 00:16:58]** supervisor are really responsible for injecting credentials

**[00:16:58 – 00:17:01]** and access to the outside world and acting as a control plane.

**[00:17:01 – 00:17:04]** So if an agent, for example, gets a prompt injection, it

**[00:17:04 – 00:17:06]** has no secrets to leak.

**[00:17:06 – 00:17:07]** The blast radius is a sandbox.

**[00:17:07 – 00:17:10]** And from a primitive and an operational standpoint, it

**[00:17:10 – 00:17:13]** takes us a little bit back to the formats we're used to running

**[00:17:13 – 00:17:15]** microservices on top of Kubernetes, treating agents a little bit

**[00:17:15 – 00:17:20]** more like cattle than pets, with the fact that if you run it on this

**[00:17:20 – 00:17:23]** full stack solution, you still get full telemetry, you get visibility,

**[00:17:23 – 00:17:27]** you get logging, and you get all of that in an immutable, trusted way.

**[00:17:28 – 00:17:31]** And then ultimately, what we saw is is that this control layer

**[00:17:31 – 00:17:34]** and this trust layer gave more and more confidence to our partners

**[00:17:34 – 00:17:36]** to be able to run things at scale.

**[00:17:37 – 00:17:41]** So this is really what OpenShell looks at when we talk about

**[00:17:41 – 00:17:44]** what are the things that it controls from a policy standpoint

**[00:17:44 – 00:17:46]** and what are the things you can write from a granular

**[00:17:46 – 00:17:49]** policy standpoint inside OpenShell.

**[00:17:49 – 00:17:52]** So file and process, network, credentials, inference, and

**[00:17:53 – 00:17:54]** then obviously policy changes.

**[00:17:54 – 00:17:57]** And the reason the policy changes, I'll focus on a little

**[00:17:57 – 00:18:00]** bit on this sort of whole category, is important is,

**[00:18:00 – 00:18:03]** I'll use a simple example, which we actually have a public demo that we

**[00:18:03 – 00:18:07]** did about three months ago around, which is, policies are extremely

**[00:18:07 – 00:18:11]** difficult to craft for an agent, and the last thing you really

**[00:18:11 – 00:18:16]** want is having a human responsible for writing agent policies,

**[00:18:16 – 00:18:19]** having to think about it in a holistic way, and then constantly

**[00:18:19 – 00:18:22]** approving or updating them if you have long horizon agents,

**[00:18:22 – 00:18:24]** especially if you get into fleets.

**[00:18:24 – 00:18:27]** What we have seen is, even if you get into a few thousand,

**[00:18:27 – 00:18:30]** you still get into hundreds of policy approvals a day,

**[00:18:30 – 00:18:33]** let alone if you get to 10,000, that actually compounds and grows

**[00:18:33 – 00:18:35]** in sort of an exponential way.

**[00:18:35 – 00:18:38]** So the reason the policy changes became, policy management

**[00:18:38 – 00:18:41]** became very important for us was we wanted to make sure

**[00:18:41 – 00:18:45]** that if you write a policy, like as an example, my agent who has access

**[00:18:46 – 00:18:49]** to my GitHub should never have access to the web because you don't

**[00:18:49 – 00:18:51]** want that agent to obviously read your GitHub code and potentially

**[00:18:51 – 00:18:53]** go post it on the web somewhere.

**[00:18:53 – 00:18:56]** However, if you write that policy and give it to a long-horizon

**[00:18:56 – 00:18:59]** agent and that agent, let's as an example say it's meant

**[00:18:59 – 00:19:02]** to solve a particular problem on a coding side and it's trying

**[00:19:02 – 00:19:04]** to get verification as to whether what it produced is right or

**[00:19:04 – 00:19:07]** not, it's gonna try to access the web, it's gonna try to collaborate,

**[00:19:07 – 00:19:10]** read from some website, and if it can't produce that, what

**[00:19:10 – 00:19:14]** we saw is that this agent actually has a tendency to spawn sub-agents.

**[00:19:14 – 00:19:17]** One sub-agent with a read-only access to GitHub, it will

**[00:19:17 – 00:19:19]** create tunneling for them, give access to another agent that

**[00:19:19 – 00:19:22]** is only allowed to post on the web.

**[00:19:22 – 00:19:24]** Now, you have a policy that says no agent is allowed to

**[00:19:24 – 00:19:26]** read or write to the web.

**[00:19:26 – 00:19:29]** However, you have three agents that their collective capabilities

**[00:19:29 – 00:19:31]** now exceed your global policy.

**[00:19:31 – 00:19:34]** How do you verify these unintended exfiltration paths, right?

**[00:19:34 – 00:19:38]** And then further, as this grows and they run longer,

**[00:19:38 – 00:19:39]** how do you maintain that?

**[00:19:39 – 00:19:42]** So some of the credential management and least privileges

**[00:19:42 – 00:19:44]** is really about how do you maintain that least privilege for these

**[00:19:44 – 00:19:46]** entire agent fleets over time.

**[00:19:46 – 00:19:49]** But the policy proving and verification using SMT solvers

**[00:19:49 – 00:19:53]** and formal methodology is really to catch that main point,

**[00:19:53 – 00:19:57]** which is that, do these collective agents exceed my global policy?

**[00:19:57 – 00:20:00]** So when I write the intent of my policy, when I actually

**[00:20:00 – 00:20:03]** write my business logic, you want that somehow to be enforced

**[00:20:03 – 00:20:07]** and essentially act as a way to force the agent to align with your

**[00:20:07 – 00:20:09]** intent and your business needs.

**[00:20:09 – 00:20:14]** And that is a way to be able to verify and enforce it.

**[00:20:14 – 00:20:16]** There's a lot of great work we've done with some of our partners,

**[00:20:16 – 00:20:19]** which we want to really talk about.

**[00:20:19 – 00:20:21]** We have Anthropic, Red Hat, and SAP.

**[00:20:21 – 00:20:23]** We want to highlight that I've done some really

**[00:20:23 – 00:20:25]** tremendous work with us.

**[00:20:25 – 00:20:29]** In the case of SAP, SAP was one of our first partners.

**[00:20:29 – 00:20:32]** Actually, when we launched OpenShell at EA, they were

**[00:20:32 – 00:20:35]** early, they contributed to the open source project, their security

**[00:20:35 – 00:20:39]** teams even helped us identify bugs, vulnerabilities, and they've

**[00:20:39 – 00:20:43]** started to build very significant internal workflows, applications,

**[00:20:43 – 00:20:44]** and services on top of OpenShell.

**[00:20:44 – 00:20:48]** So SAP is a really great testament to a phenomenal partner who

**[00:20:48 – 00:20:51]** not only built their own operation and business on top of OpenShell,

**[00:20:51 – 00:20:55]** but they really helped us shape the community as well

**[00:20:55 – 00:20:57]** as the open repo and the projects.

**[00:20:57 – 00:21:00]** Red Hat is another one that has been incredibly

**[00:21:00 – 00:21:01]** active in OpenShell.

**[00:21:01 – 00:21:05]** So OpenShell has a number of different primitives.

**[00:21:05 – 00:21:07]** One of them is how you run it from a compute standpoint.

**[00:21:07 – 00:21:08]** So it's called DRIVERS.

**[00:21:08 – 00:21:10]** What do you want to be able to plug in under the hood?

**[00:21:10 – 00:21:11]** Do you want to run it on Kubernetes?

**[00:21:11 – 00:21:14]** Do you want to run it, for example, for sandboxing using micro VMs?

**[00:21:14 – 00:21:16]** Do you want to use Docker, Podman?

**[00:21:16 – 00:21:17]** We are unopinionated.

**[00:21:17 – 00:21:20]** We work sort of very agnostic across the board.

**[00:21:20 – 00:21:23]** Red Hat did a lot of the heavy lift, helping us basically

**[00:21:23 – 00:21:24]** build these integrations.

**[00:21:24 – 00:21:27]** They are naturally, obviously, very much experts in distributed

**[00:21:27 – 00:21:30]** systems, in Kubernetes with OpenShift, and a lot of

**[00:21:30 – 00:21:34]** the work they've done around identity and scalability.

**[00:21:34 – 00:21:36]** So, phenomenal partner from the very beginning.

**[00:21:36 – 00:21:38]** And then more recently, we started to work with Anthropic,

**[00:21:38 – 00:21:41]** because one of the things we really wanted to make sure is, we

**[00:21:41 – 00:21:46]** do not have a world where you have frontier models, and then basically

**[00:21:46 – 00:21:47]** a runtime that is running behind.

**[00:21:47 – 00:21:50]** So our thinking was, how do you create a runtime that

**[00:21:50 – 00:21:51]** is for frontier models?

**[00:21:52 – 00:21:53]** And this is a lot of the joint work that we've been

**[00:21:53 – 00:21:55]** doing with Anthropic.

**[00:21:55 – 00:21:57]** And the work we've been doing is really about this notion

**[00:21:57 – 00:21:58]** of least privilege.

**[00:21:59 – 00:22:01]** How do you actually use a frontier model to help you

**[00:22:01 – 00:22:03]** do some of the sanity checks?

**[00:22:03 – 00:22:06]** Now, this is one of the implementations that we

**[00:22:07 – 00:22:09]** currently have with Anthropic.

**[00:22:09 – 00:22:11]** They have published a blog about this.

**[00:22:11 – 00:22:13]** This is public, so you can all take pictures of it, or you can

**[00:22:13 – 00:22:16]** also go look at it on their blog, which is much more informative.

**[00:22:16 – 00:22:20]** And ultimately, what they have done is... the implementation

**[00:22:20 – 00:22:24]** they have used for OpenShell and Cloud Managed Agents is about

**[00:22:24 – 00:22:28]** how do you create data sovereignty while leveraging a frontier model.

**[00:22:28 – 00:22:31]** So in short, and I'll go to the next slide, which is going to be

**[00:22:31 – 00:22:33]** a video of how this actually works.

**[00:22:33 – 00:22:38]** But in this particular format, Anthropic Cloud Orchestrator,

**[00:22:38 – 00:22:42]** which is really their harness,

**[00:22:42 – 00:22:45]** communicates with OpenShell that runs all the workers.

**[00:22:45 – 00:22:49]** The workers are really where the agent is touching and working with

**[00:22:49 – 00:22:54]** sensitive data, content, tools, or services inside your organization.

**[00:22:54 – 00:22:57]** So this is a way for us to be able to draw a line in the sand

**[00:22:57 – 00:23:00]** for an organization to set policies around where they want sovereignty,

**[00:23:00 – 00:23:03]** where they want deterministic controls, and what they want

**[00:23:03 – 00:23:07]** the boundary to be around their organization versus the use of

**[00:23:07 – 00:23:11]** services that is outside and still have access to frontier services.

**[00:23:11 – 00:23:12]** So this has been quite exciting.

**[00:23:12 – 00:23:14]** We're going to keep talking about this.

**[00:23:14 – 00:23:15]** We're doing a lot of work here.

**[00:23:15 – 00:23:18]** Another area of work that we are doing with Anthropic

**[00:23:18 – 00:23:21]** is also to try to understand that as frontier models are coming

**[00:23:21 – 00:23:24]** out, what are their capabilities to break out an environment?

**[00:23:24 – 00:23:27]** What are they susceptible to as far as being drifted from?

**[00:23:27 – 00:23:30]** And then understanding what is the alignment work they're doing

**[00:23:30 – 00:23:33]** and what is the alignment work that we have to do from a deterministic

**[00:23:33 – 00:23:35]** enforcement in OpenShell itself.

**[00:23:35 – 00:23:37]** So to make it a little bit more exciting, I'm going to

**[00:23:37 – 00:23:42]** actually show you the demo of what they're doing.

**[00:23:46 – 00:23:49]** It's made possible by OpenShell, the agent runtime

**[00:23:49 – 00:23:53]** from NVIDIA, and Clawed Managed Agents from Anthropic.

**[00:23:53 – 00:23:58]** The use case, Meridian Financial, a fictitious financial institution

**[00:23:58 – 00:23:59]** managing a fleet of agents.

**[00:24:00 – 00:24:03]** Meridian has one rule, confidential filing text

**[00:24:03 – 00:24:05]** never leaves its environment.

**[00:24:05 – 00:24:09]** The report is written by Clawed Agents on Managed Agents.

**[00:24:09 – 00:24:13]** The analyst's tool call runs on-prem in a worker inside

**[00:24:13 – 00:24:15]** the OpenShell agent runtime.

**[00:24:15 – 00:24:18]** The worker reads the documents where they live.

**[00:24:18 – 00:24:22]** Nemotron, on a local GPU, reads the text.

**[00:24:22 – 00:24:24]** Claude never touches the documents.

**[00:24:24 – 00:24:27]** It sees the analysis from the worker agent that is working

**[00:24:27 – 00:24:30]** directly with the data.

**[00:24:30 – 00:24:34]** A person signs a ceiling, the most this agent may ever hold.

**[00:24:34 – 00:24:36]** Each session starts with nothing.

**[00:24:36 – 00:24:39]** The agent asks for one narrow rule.

**[00:24:39 – 00:24:43]** OpenShell's prover checks it fits the ceiling, and a person approves.

**[00:24:44 – 00:24:47]** Rule by rule, it earns exactly what the task needs.

**[00:24:47 – 00:24:51]** If the agent tries to reach the open internet or an unapproved

**[00:24:51 – 00:24:55]** endpoint, the name doesn't resolve, and the prover rejects the rule.

**[00:24:56 – 00:24:59]** Used grants become the next session's starting point.

**[00:24:59 – 00:25:04]** A handwritten policy is cut to what sessions used, each change proved.

**[00:25:04 – 00:25:06]** This example followed one agent.

**[00:25:06 – 00:25:10]** The same applies to every agent in the fleet, its own runtime,

**[00:25:10 – 00:25:13]** assigned ceiling, the same proof.

**[00:25:13 – 00:25:16]** Clawed Managed Agents is the orchestration

**[00:25:16 – 00:25:18]** engine above the fleet.

**[00:25:18 – 00:25:21]** Agents spin up and direct other agents, so hundreds

**[00:25:21 – 00:25:22]** work in parallel.

**[00:25:22 – 00:25:24]** Sessions run for hours.

**[00:25:24 – 00:25:27]** Credentials stay in a vault the agents never see, and

**[00:25:27 – 00:25:30]** every action is recorded.

**[00:25:30 – 00:25:33]** Managed Agents does the work and directs the fleet.

**[00:25:33 – 00:25:37]** OpenShell sets what each agent can reach and proves it.

**[00:25:37 – 00:25:41]** Together, a company can limit what every agent does, review

**[00:25:41 – 00:25:45]** what it did, and confirm the limits are in place.

**[00:25:45 – 00:25:49]** With OpenShell and Claude managed agents, companies can verify

**[00:25:49 – 00:25:54]** deterministically that an agent has stayed inside its runtime.

**[00:25:54 – 00:25:57]** That lets them keep their IP secure while running fleets

**[00:25:57 – 00:26:00]** of agents at the frontier.

**[00:26:04 – 00:26:05]** The last thing I'll add here before handing it over to

**[00:26:05 – 00:26:08]** my colleague Ophir is that one of the really interesting pieces of

**[00:26:08 – 00:26:11]** work we've recently done, which you can actually find on OpenShell's

**[00:26:11 – 00:26:15]** dev notes on our GitHub repo, is how do you actually put that policy

**[00:26:15 – 00:26:17]** prover into what we call auto mode?

**[00:26:17 – 00:26:21]** So if your CISO organization or your IT organizations writes these

**[00:26:21 – 00:26:24]** global policies that says this is the ceiling for what is allowed,

**[00:26:24 – 00:26:27]** you can actually put OpenShell in an auto mode, so as long as

**[00:26:27 – 00:26:31]** the thing the agent is asking for and as long as their combination of

**[00:26:31 – 00:26:34]** access does not exceed that, it can basically tip into an auto mode.

**[00:26:34 – 00:26:36]** Think of it as sort of the same mode you operate with

**[00:26:36 – 00:26:37]** a coding agent with.

**[00:26:37 – 00:26:40]** Now, you can put a human in the loop to authorize that.

**[00:26:40 – 00:26:43]** And a human that is authorizing that can never authorize

**[00:26:43 – 00:26:46]** anything above your ceiling that your company has set.

**[00:26:46 – 00:26:49]** But it is a way to avoid hundreds of manual approvals a day and

**[00:26:49 – 00:26:52]** ensure you're still staying within the boundaries of governance and

**[00:26:52 – 00:26:55]** compliance of your organization.

**[00:26:55 – 00:26:58]** From here, I'm just going to touch a little bit about the next steps.

**[00:26:58 – 00:27:01]** So these are some of the next areas that we are focusing on OpenShell.

**[00:27:01 – 00:27:05]** We are focusing on broader assurance, safer fleets, and the

**[00:27:05 – 00:27:08]** one thing I want to really touch on is really portable enforcement,

**[00:27:08 – 00:27:12]** which is going to be what Ophir is going to talk a little bit about.

**[00:27:20 – 00:27:21]** So, thank you.

**[00:27:21 – 00:27:26]** I will be talking about Sentry and explaining what we've

**[00:27:26 – 00:27:28]** done with Sentry.

**[00:27:28 – 00:27:33]** So, Docker Sentry is really a unified security software framework

**[00:27:33 – 00:27:39]** that is built on NVIDIA Docker and running on NVIDIA Bluefield 4.

**[00:27:39 – 00:27:45]** BlueField 4 offloads, accelerates, and isolates infrastructure

**[00:27:45 – 00:27:52]** functions, and while it provides with high-performance connectivity

**[00:27:52 – 00:27:58]** for AI infrastructure, it really combines between NVIDIA Grace CPUs

**[00:27:58 – 00:28:08]** for high-performance computing with NVIDIA ConnectX 9 for networking.

**[00:28:08 – 00:28:11]** When we designed BlueField, we really wanted to

**[00:28:11 – 00:28:16]** tackle a long-standing conundrum with security.

**[00:28:16 – 00:28:21]** The conundrum is that when security software shares the same

**[00:28:21 – 00:28:28]** trust domain with malicious code, it risks being disabled, blinded,

**[00:28:28 – 00:28:31]** or report false information.

**[00:28:31 – 00:28:38]** Therefore, we purposely built BlueField to be completely

**[00:28:38 – 00:28:40]** isolated from the host.

**[00:28:40 – 00:28:47]** We also made sure that it operates on its own separate trust domain.

**[00:28:47 – 00:28:53]** So the security controls are operating separately from the host

**[00:28:53 – 00:28:57]** with no agents, no integration, no performance overhead on the host

**[00:28:57 – 00:29:03]** CPU or GPU, while the host-based software cannot alter the way

**[00:29:03 – 00:29:07]** that security policies are applied.

**[00:29:08 – 00:29:11]** Actually, if you think about it, those security controls

**[00:29:11 – 00:29:14]** are also applied in a complete transparent manner.

**[00:29:14 – 00:29:19]** So whatever host software runs on that machine, whether

**[00:29:19 – 00:29:23]** agents or other workloads, it doesn't really know that those

**[00:29:23 – 00:29:26]** security controls are applied.

**[00:29:26 – 00:29:27]** I'll show you in a second why.

**[00:29:27 – 00:29:34]** So it's not just that agents cannot reach the security policies,

**[00:29:34 – 00:29:40]** cannot alter them, they don't have even knowledge that they exist.

**[00:29:40 – 00:29:45]** In that sense, if you think about it, Sentry is trusted

**[00:29:46 – 00:29:50]** when host resources cannot be trusted, because of the

**[00:29:50 – 00:29:56]** isolation and because of the ability to run those security

**[00:29:56 – 00:30:01]** controls without the ability of the host to reach them and change them.

**[00:30:01 – 00:30:05]** Other important items that we want to highlight is that

**[00:30:05 – 00:30:12]** when we integrated with OpenShell, we took the network access policy

**[00:30:12 – 00:30:15]** and we offloaded it to silicon.

**[00:30:15 – 00:30:19]** So your access policy, where are you going, what are you

**[00:30:19 – 00:30:25]** doing, which resources are you allowed to reach, your

**[00:30:25 – 00:30:32]** identity controls, they are all now enforced in silicon and offloaded

**[00:30:32 – 00:30:35]** to BlueField and to Sentry.

**[00:30:35 – 00:30:39]** This way you can think about the disintegration as an onion

**[00:30:39 – 00:30:41]** approach to security.

**[00:30:41 – 00:30:44]** There are some capabilities that we run on the host itself.

**[00:30:44 – 00:30:48]** We validate the integrity of those controls and the

**[00:30:48 – 00:30:52]** agent, and in any case that there is an issue with something

**[00:30:52 – 00:30:57]** that we observe on that machine, we have the ability basically

**[00:30:57 – 00:31:03]** to use hardware as a safety belt that does not allow that

**[00:31:03 – 00:31:07]** harm to spread away, and we're able to respond to it in millisecond

**[00:31:07 – 00:31:09]** and provide that containment.

**[00:31:09 – 00:31:14]** Where we are really headed is to provide with the ability

**[00:31:14 – 00:31:18]** to continuously assess the risk and the trust, in the sense

**[00:31:18 – 00:31:26]** that we look both on the security of agents, and on the other hand,

**[00:31:26 – 00:31:31]** we also make sure that we measure their integrity at the same time.

**[00:31:31 – 00:31:35]** So continuously make sure that that agent is secured

**[00:31:35 – 00:31:37]** and at the same time make sure the agent maintains its

**[00:31:37 – 00:31:40]** integrity and does not go a-wire.

**[00:31:40 – 00:31:45]** There are some things that we can do on the card directly

**[00:31:45 – 00:31:48]** and get to those conclusions.

**[00:31:48 – 00:31:52]** There are some things that you would like to use, something

**[00:31:52 – 00:31:56]** like an XDR or a SIM to correlate the signals coming

**[00:31:56 – 00:32:00]** from multiple deployments.

**[00:32:00 – 00:32:04]** You know, looking at one of the recent incidents, you would

**[00:32:04 – 00:32:09]** really like to know whether your agents are touching the same file

**[00:32:09 – 00:32:12]** on an artifactory, for example.

**[00:32:12 – 00:32:17]** They're all using the same text file rather than binary.

**[00:32:17 – 00:32:23]** Last but not least, at the same incident, we saw that

**[00:32:23 – 00:32:27]** we cannot really trust agents when they go AWire.

**[00:32:27 – 00:32:32]** Those agents falsified their own logs, which actually is a different

**[00:32:32 – 00:32:37]** level of a problem, especially for anything that is leveraging

**[00:32:37 – 00:32:40]** logs in order to understand what those agents are doing.

**[00:32:40 – 00:32:44]** So one of the more important features and capabilities

**[00:32:44 – 00:32:48]** that we support is the ability to provide with a temper-evident

**[00:32:48 – 00:32:49]** agent traceability.

**[00:32:49 – 00:32:53]** Now, this traceability comes from the fact that BlueField

**[00:32:53 – 00:32:58]** sits on the only path of the agent to the outer world, which means the

**[00:32:58 – 00:33:01]** models, the tools, anything else.

**[00:33:01 – 00:33:05]** So we are basically terminating the traffic.

**[00:33:05 – 00:33:12]** We do TLS termination, we look into the traffic, and we apply not

**[00:33:12 – 00:33:16]** just visibility but also control over that information and provide

**[00:33:16 – 00:33:20]** with temporary evident traceability from the networking side.

**[00:33:20 – 00:33:26]** And we also have a technology that I will talk about in a second

**[00:33:26 – 00:33:31]** a bit more that provides with real-time Memory introspection,

**[00:33:31 – 00:33:34]** so we are able to look in real time and understand what the agent is

**[00:33:35 – 00:33:38]** doing in its execution environment.

**[00:33:38 – 00:33:40]** And it also contributes to the traceability because there

**[00:33:40 – 00:33:45]** are going to be signs coming from there that will be important

**[00:33:45 – 00:33:48]** to understand as well.

**[00:33:48 – 00:33:54]** So, to provide some information about the NVIDIA sentry

**[00:33:55 – 00:34:00]** capabilities, as I said, we control the agent's only path to the model.

**[00:34:00 – 00:34:06]** We actually create a wall garden for the traffic in silicon.

**[00:34:06 – 00:34:12]** We terminate the traffic in silicon, and we basically controls

**[00:34:12 – 00:34:16]** where the agent can go, where the harness can go in this case.

**[00:34:16 – 00:34:21]** And it means that there is no bypassing these controls;

**[00:34:21 – 00:34:26]** think of it as a virtual internet code that is connected between

**[00:34:26 – 00:34:30]** the harness and the silicone, and there are no ways to bypass it.

**[00:34:30 – 00:34:34]** And that wall garden allows us to control all the resource

**[00:34:34 – 00:34:39]** access and apply visibility and control by using a transparent

**[00:34:39 – 00:34:45]** proxy that we have on the... on Sentry, running on BlueField,

**[00:34:45 – 00:34:50]** and that provides us that control and visibility into that traffic.

**[00:34:50 – 00:34:55]** Most importantly, we have a technology that does real-time

**[00:34:55 – 00:34:56]** memory introspection.

**[00:34:56 – 00:35:02]** As I mentioned earlier on, it looks into the volatile memory

**[00:35:02 – 00:35:07]** and analyzes specific snippets of memory to understand how the agent

**[00:35:07 – 00:35:11]** is operating and what is happening in its execution environment.

**[00:35:11 – 00:35:12]** Why is this so important?

**[00:35:12 – 00:35:18]** Because first, we use the information like an EDR sensor, and

**[00:35:18 – 00:35:20]** I assume you know what EDR does.

**[00:35:20 – 00:35:24]** So a lot of our partners are using this information in

**[00:35:24 – 00:35:30]** order to detect security issues with the execution environment.

**[00:35:30 – 00:35:34]** On the other hand, you can also watch for the agents

**[00:35:34 – 00:35:40]** or processes that are interacting with threads, files, the memory,

**[00:35:40 – 00:35:41]** and other resources.

**[00:35:41 – 00:35:45]** And based on that information, you can conclude, for example,

**[00:35:45 – 00:35:52]** if a container escape is being attempted or any other detection

**[00:35:52 – 00:35:57]** has been found to happen there, and act on it accordingly.

**[00:35:58 – 00:36:02]** So the traceability comes from looking at the network traffic

**[00:36:02 – 00:36:08]** and for observing the situational awareness that we provide by having

**[00:36:08 – 00:36:11]** the real-time memory introspection.

**[00:36:11 – 00:36:15]** The fact that we opened the traffic also allows us to allow

**[00:36:15 – 00:36:20]** our partners to extend different capabilities and introduce

**[00:36:20 – 00:36:23]** their logic into the flow.

**[00:36:23 – 00:36:26]** One of the interesting things that we did, and this is kind

**[00:36:26 – 00:36:32]** of in the future, the way that we look at this, is to use specialized

**[00:36:32 – 00:36:36]** models to analyze the traffic that goes between the agent and the LLM.

**[00:36:36 – 00:36:40]** There is an interesting demo in our booth, as well as an

**[00:36:40 – 00:36:45]** OpenShell demo in the booth, that actually showcases such an example.

**[00:36:45 – 00:36:53]** So using it inline in order to protect from potentially malicious

**[00:36:53 – 00:37:00]** content that would basically go from the LLM back to the agent.

**[00:37:05 – 00:37:09]** We would like to thank our partners that support the

**[00:37:09 – 00:37:13]** OpenShell reference architecture.

**[00:37:14 – 00:37:19]** And we also would like to invite you to attend the other

**[00:37:19 – 00:37:22]** talks in our security track.

**[00:37:22 – 00:37:27]** You can use the QR code to have a full understanding

**[00:37:27 – 00:37:31]** of a list of all of the tracks

**[00:37:31 – 00:37:35]** and to basically get more information about the technologies

**[00:37:35 – 00:37:40]** that we have presented here today.

**[00:37:40 – 00:37:44]** So closing exactly on time, we would like to thank you

**[00:37:44 – 00:37:47]** for attending GTC Berlin.

**[00:37:47 – 00:37:50]** We will be outside in the hall answering any questions.

**[00:37:50 – 00:37:51]** Thank you, Ali.

**[00:37:51 – 00:37:55]** Thank you all, and have a great GTC.

**[00:38:00 – 00:38:02]** Thank you, Ophir and Ali.

**[00:38:02 – 00:38:05]** If you have a few minutes, we have, I have a couple of

**[00:38:05 – 00:38:05]** trivia questions.

**[00:38:05 – 00:38:07]** We have some prizes to give out.

**[00:38:07 – 00:38:11]** We have socks or hats; you can have your pick.

**[00:38:12 – 00:38:14]** Everybody ready?

**[00:38:15 – 00:38:19]** First question, I'll go for the hard question first.

**[00:38:20 – 00:38:25]** In order to keep your agents safe, you need a really safe

**[00:38:25 – 00:38:28]** model and you need to put... A true or false question, okay?

**[00:38:28 – 00:38:31]** And you need to say please in front of your prompts.

**[00:38:31 – 00:38:33]** True or false?

**[00:38:34 – 00:38:35]** False, okay.

**[00:38:35 – 00:38:38]** Raise your hand and say.

**[00:38:38 – 00:38:41]** Okay, you're the first one I saw, so you get it.

**[00:38:41 – 00:38:44]** You can stop by after.

**[00:38:45 – 00:38:48]** So second question, this is the easy one, okay.

**[00:38:48 – 00:38:51]** In the reference architecture described, the Vera, BlueField,

**[00:38:51 – 00:38:55]** Vera Rubin reference architecture that Ali and Ophir described,

**[00:38:56 – 00:39:02]** where does OpenShell run and where does Sentry run?

**[00:39:05 – 00:39:09]** Name the products in the reference architecture.

**[00:39:12 – 00:39:13]** Okay, yeah.

**[00:39:13 – 00:39:17]** So runs on the Vera, OpenShell runs on the Vera CPU, and

**[00:39:17 – 00:39:21]** Sentry runs on the BlueField CPU.

**[00:39:21 – 00:39:24]** Thank you, thank you for staying back and playing trivia with us.