1
00:00:04,461 --> 00:00:10,181
Today I'm going to talk to you about how your agent is a lethal trifecta and what to do about it.

2
00:00:11,121 --> 00:00:13,841
Now we're going to start out right off the bat with a demo.

3
00:00:14,341 --> 00:00:23,061
Some context on this demo, we're going to look at an on-call triage agent that reads and writes to an incident pager and resolves or escalates tickets.

4
00:00:23,401 --> 00:00:29,641
This agent has full access to a cloud hosting API, a customer data warehouse, as well as a billing database.

5
00:00:31,621 --> 00:00:38,641
So here we have our on-call triage agent, and it has an incident queue of tickets that it's going to read.

6
00:00:38,641 --> 00:00:45,181
and then if it can resolve them, it's going to call the available services that it has access to

7
00:00:45,181 --> 00:00:46,701
and it's going to do so.

8
00:00:46,941 --> 00:00:50,261
Things that it can't resolve, it's going to escalate for the morning team.

9
00:00:50,821 --> 00:00:55,221
So if we take a look at this first ticket, this is a billing anomaly.

10
00:00:55,441 --> 00:00:58,161
It says a batch of customers were overcharged last night.

11
00:00:59,481 --> 00:01:04,821
So the first thing the agent does is it directly calls the Incitex API in order to read the ticket.

12
00:01:04,821 --> 00:01:10,001
And if you look here, you can see that it authorized access to this API using an API key.

13
00:01:10,761 --> 00:01:19,361
It then uses a Snowflake key to query the customer data warehouse, and it's going to decide to escalate the ticket for morning review.

14
00:01:19,641 --> 00:01:21,861
And it writes a report for the morning team.

15
00:01:22,161 --> 00:01:24,741
And as you can see, it's sharing customer data.

16
00:01:24,741 --> 00:01:35,501
These are rows directly pulled from the customer data warehouse, and it is sending personally identifiable information to the team that is going to be on staff in the morning.

17
00:01:40,661 --> 00:01:44,541
This next ticket is a backup power supply failed in the server room.

18
00:01:44,781 --> 00:01:46,701
The agent is going to read the ticket.

19
00:01:46,961 --> 00:01:51,381
Again, it's using an API key to call the ticket API.

20
00:01:51,381 --> 00:01:58,901
It determines that this is a physical problem, so it escalates for morning review without calling any additional services.

21
00:02:02,701 --> 00:02:07,041
This one is the TLS certificate is expiring soon for the website.

22
00:02:07,361 --> 00:02:10,541
It reads the ticket. It determines that the alert is clear.

23
00:02:10,541 --> 00:02:21,701
It has access to the cloud hosting API, and it calls that API at the certificate renew endpoint using, again, an API key.

24
00:02:22,521 --> 00:02:32,621
It resolves this by renewing the certificate, and it leaves a report for the morning crew by calling the pager incident API as well.

25
00:02:35,201 --> 00:02:39,081
This next one is the billing database is broken and payments are failing.

26
00:02:39,081 --> 00:02:44,421
So the documented recovery for this is to drop and restore the database.

27
00:02:45,661 --> 00:02:51,241
The agent does this using the database connection string that includes the admin password.

28
00:02:51,901 --> 00:02:56,921
And then it advises the morning team to make sure that the snapshot recovery worked.

29
00:02:57,161 --> 00:03:01,081
Now, this is not something that it has access to directly.

30
00:03:01,081 --> 00:03:12,201
So it is essentially assuming that the morning team is going to verify that this did in fact work and the information was restored.

31
00:03:15,081 --> 00:03:22,141
Now, an overprivileged agent dropping a production database is basically a nightmare that several companies have actually lived.

32
00:03:23,061 --> 00:03:25,441
So this is something that we need to be very careful of.

33
00:03:26,901 --> 00:03:29,081
Now, the next one is orders are stuck.

34
00:03:29,341 --> 00:03:30,481
Main server is frozen.

35
00:03:32,221 --> 00:03:34,741
So the agent is again is going to read the ticket.

36
00:03:35,381 --> 00:03:40,781
After reading the ticket, the agent calls the cloud hosting API using again its static

37
00:03:40,781 --> 00:03:41,501
API key.

38
00:03:41,741 --> 00:03:45,721
It calls the endpoint to restart the server, which brings production offline.

39
00:03:52,121 --> 00:03:55,081
Finally, site is failing for one in three visitors.

40
00:03:56,861 --> 00:03:58,141
Agent reads the ticket.

41
00:03:58,141 --> 00:04:00,021
it determines that

42
00:04:00,201 --> 00:04:15,861
it should call the cloud hosting API and scale the service from four pods to 40. It then incurs a charge of $420 per hour for doing this. And then it kindly leaves a note for the morning team informing them that this has happened.

43
00:04:19,761 --> 00:04:21,801
Now, what makes an agent useful?

44
00:04:23,181 --> 00:04:28,061
Well, typically, we want agents to have a minimum set of capabilities, and often this

45
00:04:28,061 --> 00:04:32,101
includes things like the ability to read data that you own or have access to.

46
00:04:32,321 --> 00:04:36,381
This might be like your email, your documents, maybe a customer CRM.

47
00:04:37,181 --> 00:04:40,941
We want the agent to be able to do its own research, so this might include searching

48
00:04:40,941 --> 00:04:44,301
the web, maybe reading documentation, or pulling issues from GitHub.

49
00:04:45,721 --> 00:04:52,281
And we usually want it to be able to use external tools, for example, MCP servers or APIs, maybe SAS platforms.

50
00:04:53,981 --> 00:04:59,761
useful agents might do these things with a human in the loop, or they might be doing it autonomously in the background.

51
00:05:00,221 --> 00:05:04,761
But the things that make agents useful also make them dangerous.

52
00:05:05,661 --> 00:05:12,121
In fact, together, these three capabilities make what Simon Willison coined as a lethal trifecta.

53
00:05:12,121 --> 00:05:20,961
This is a combination of access to private data, like the on-call agent's ability to query the customer data warehouse and interact with the billing database,

54
00:05:22,041 --> 00:05:29,161
exposure to untrusted content, like reading user-submitted tickets or reports from other agents or externally documented processes,

55
00:05:30,181 --> 00:05:35,981
and the ability to communicate externally, like reading and writing with third-party APIs or SaaS services.

56
00:05:36,881 --> 00:05:40,341
Together, these capabilities throw the doors wide open for attackers.

57
00:05:42,441 --> 00:05:46,621
Now, agents are designed to get the job done, and they'll use all the powers that they

58
00:05:46,621 --> 00:05:49,761
have to do it, sometimes with very serious consequences.

59
00:05:51,561 --> 00:05:52,161
here's the thing.

60
00:05:53,021 --> 00:05:57,361
incidents happen because humans give agents way more access than they need.

61
00:05:59,401 --> 00:06:04,701
Overprivileged agents can act freely on decisions that they make, even if they do have supervision.

62
00:06:06,901 --> 00:06:13,161
Now, forcing a human-in-the-loop approval just kind of passes the access control on to a consent-fatigued user.

63
00:06:13,561 --> 00:06:22,021
Now, we've spent decades solving access management for humans, so shifting responsibility to the user just sort of moves the security problem up the chain.

64
00:06:24,221 --> 00:06:29,781
So what should we do about the lethal trifecta? How do we address it without compromising the agent's usefulness?

65
00:06:32,021 --> 00:06:37,641
Well, just removing one or more of these capabilities is going to cause the agent to be significantly less useful.

66
00:06:38,821 --> 00:06:42,001
So how can we keep all three, but still be safe about it?

67
00:06:42,641 --> 00:06:56,261
Well, instead of breaking the trifecta by removing capabilities, we really need to control the agent's access so the attack surface is minimized and the blast radius is contained, but the agent still has capability and autonomy.

68
00:06:57,961 --> 00:06:59,061
So how do we do that?

69
00:07:00,401 --> 00:07:10,801
Well, some options for controlling access, among others, are things like using OAuth, maybe using a vendor MCP gateway, or containing execution in sandboxes.

70
00:07:12,561 --> 00:07:20,381
Now, OAuth binds access to a grant. At grant time, the user consents to all of the permissions that the agent could possibly use.

71
00:07:20,681 --> 00:07:28,201
Now, consent is granted before any task exists, so if you give a broad grant, then you end up with standing access.

72
00:07:28,201 --> 00:07:33,441
your agent is over permissioned for any single specific task. If you narrow the

73
00:07:33,441 --> 00:07:36,481
grant and you don't give it very many permissions, then the agent just becomes

74
00:07:36,481 --> 00:07:41,261
less capable. Either way, OAuth alone doesn't provide task scoped access

75
00:07:41,261 --> 00:07:46,921
control. An enthusiastic agent can both read and write in the same run, even if

76
00:07:46,921 --> 00:07:53,401
you only want it to read on this specific task. Now an MCP gateway binds

77
00:07:53,401 --> 00:07:57,781
enforcement to a route. You get things like observability and rate limits and

78
00:07:57,781 --> 00:08:03,501
you also get one policy decision point at the MCP layer. A policy runs per request,

79
00:08:03,761 --> 00:08:08,901
and access is granted per user, but the agent's granted access outlives any single task

80
00:08:08,901 --> 00:08:11,361
because the gateway still holds standing credentials.

81
00:08:13,001 --> 00:08:19,181
Now a sandbox binds execution to a process. This controls the blast radius, but useful work has to

82
00:08:19,181 --> 00:08:23,281
reach outside the sandbox, and when it does so, you end up with standing access again.

83
00:08:23,281 --> 00:08:27,641
Now we've also seen plenty of stories about agents breaking sandbox containment.

84
00:08:28,341 --> 00:08:32,621
Sandboxes bound what the processes can do, but they don't control what is authorized

85
00:08:32,621 --> 00:08:34,941
to act outside the sandbox itself.

86
00:08:36,761 --> 00:08:41,561
Now, even if you combined all three of the solutions, the agent still doesn't receive

87
00:08:41,561 --> 00:08:44,921
a runtime credential that's downscoped to only one task.

88
00:08:47,601 --> 00:08:51,021
let's recap the problems, especially the ones that we saw in the demo.

89
00:08:51,021 --> 00:08:55,241
Now, if you remember the audit log, we couldn't tell who was using the API keys.

90
00:08:56,421 --> 00:09:01,661
So the first problem is that credentials weren't attributed to a user or an agent's identity.

91
00:09:02,421 --> 00:09:07,641
The agent had unrestricted access to any and all permissions that were granted by the API

92
00:09:07,641 --> 00:09:08,181
keys.

93
00:09:09,061 --> 00:09:13,341
And finally, we can't just slap human in the loop everywhere because humans make mistakes

94
00:09:13,341 --> 00:09:13,601
too.

95
00:09:13,901 --> 00:09:17,461
Plus many agents run autonomously and they don't even have a human in the loop.

96
00:09:19,481 --> 00:09:23,381
So to solve these problems, we can start by using something called token exchange.

97
00:09:23,781 --> 00:09:28,921
Now, this is an existing standard that was published in 2020, and it extends OAuth 2.

98
00:09:30,681 --> 00:09:33,581
Now, first, we need to know who the user is.

99
00:09:33,961 --> 00:09:37,541
Now, an authorization server verifies identities and issues tokens.

100
00:09:37,841 --> 00:09:42,441
Identity providers like Google, Okta, Auth0, etc. provide authorization servers.

101
00:09:42,441 --> 00:09:48,581
So if we want an identity chain in our agent execution path, then the user has got to log in first.

102
00:09:51,101 --> 00:09:58,501
The authorization server is going to prompt the user for consent to delegate access to resources with some subset of their permissions.

103
00:09:58,661 --> 00:09:59,981
Now, these permissions are called scopes.

104
00:10:00,221 --> 00:10:02,201
This is the first narrowing of access.

105
00:10:02,461 --> 00:10:06,561
We're only delegating some of the user's total scopes to the agent.

106
00:10:09,261 --> 00:10:14,101
The authorization server issues tokens identifying the user and their level of access.

107
00:10:14,661 --> 00:10:20,601
And at this point, we're already doing better than the demo because we actually know who the user is and we actually know what they can access.

108
00:10:23,501 --> 00:10:26,941
So this brings us into the agentic execution path.

109
00:10:28,341 --> 00:10:35,681
Now we have our authenticated user, so we have a known identity of a person who wants to use an LLM to interact with a resource.

110
00:10:36,561 --> 00:10:42,621
Now, in the demo, the resources are the incident pager, the production database, Snowflake, and the cloud hosting service.

111
00:10:44,301 --> 00:10:47,221
An agent is a control loop that calls an LLM.

112
00:10:47,801 --> 00:10:55,641
Often, we have an MCP server that sits between the agent and its resources, providing defined tools that connect to those downstream services.

113
00:10:57,961 --> 00:11:03,001
An MCP client dispatches the agent's proposed tool calls to its MCP server.

114
00:11:03,501 --> 00:11:11,741
Now, in the demo, the on-call triage agent called resources directly with long-lived static credentials like API keys or database connection strings.

115
00:11:14,001 --> 00:11:17,521
So what we're going to do is we're going to give the on-call agent an MCP server.

116
00:11:17,821 --> 00:11:22,321
This is going to provide tools and is also going to serve to broker access to resources.

117
00:11:26,541 --> 00:11:31,141
Now, an agent runtime is a process that runs the agent loop and executes calls.

118
00:11:31,741 --> 00:11:34,841
The runtime might be a CLI, like Claude Code,

119
00:11:35,041 --> 00:11:40,241
or an agent SDK, which might be implemented in a custom application like the on-call agent.

120
00:11:42,021 --> 00:11:44,861
So let's follow a prompt through this execution path.

121
00:11:45,461 --> 00:11:50,781
The user submits the prompt to the runtime, which calls the model and sends the prompt to the LLM.

122
00:11:51,021 --> 00:11:56,721
The model then proposes tool calls, which are dispatched by the MCP client to its MCP server,

123
00:11:56,981 --> 00:12:00,121
which executes tools and then calls the resource API.

124
00:12:03,281 --> 00:12:06,701
The API returns the response to the MCP server.

125
00:12:07,081 --> 00:12:11,521
The MCP client delivers the response to the runtime, which calls the model again.

126
00:12:11,701 --> 00:12:16,861
And this loop repeats until the model is satisfied and returns a response to the user.

127
00:12:20,121 --> 00:12:23,861
Now, the authenticated user's token becomes what we call a subject token.

128
00:12:24,061 --> 00:12:28,701
This identifies who the agent is acting on behalf of, who it acts for.

129
00:12:30,761 --> 00:12:34,561
Now, token exchange needs an OAuth client that can execute code.

130
00:12:34,741 --> 00:12:39,821
So this might be a gateway that sits between the MCP client and the third-party MCP server.

131
00:12:41,301 --> 00:12:43,481
Or it might be your custom app.

132
00:12:45,061 --> 00:12:49,801
Now, a custom MCP server can also exchange tokens for downstream resources.

133
00:12:50,181 --> 00:12:55,541
The on-call agent's MCP server should provide a defined set of production infrastructure tools.

134
00:12:57,881 --> 00:13:00,861
The prompt and the subject token are sent to the runtime.

135
00:13:01,241 --> 00:13:04,101
The agent loop runs, and the model proposes a tool call.

136
00:13:08,001 --> 00:13:12,541
runtime authenticates with a special authorization server called a security token service.

137
00:13:12,741 --> 00:13:16,141
It does this using its app client credentials or workload identity.

138
00:13:17,341 --> 00:13:20,921
also sends the subject token that contains the user's identity and access.

139
00:13:22,561 --> 00:13:30,461
It creates a token exchange request asking for permission to access the MCP server for that tool call and only that tool call.

140
00:13:30,861 --> 00:13:34,481
So now we have three pieces of info that we're missing from the demo.

141
00:13:36,981 --> 00:13:39,901
We know the identity of the agent that's requesting access.

142
00:13:40,301 --> 00:13:43,321
We know the identity of the user it's acting on behalf of.

143
00:13:43,581 --> 00:13:46,641
And we know the level of access that the user granted to the agent.

144
00:13:48,201 --> 00:13:53,101
Now we need to decide if the requested token should be issued, and we can do this with

145
00:13:53,101 --> 00:13:59,101
governance policy, which is evaluated against what access is requested from what resource,

146
00:13:59,461 --> 00:13:59,901
the

147
00:14:00,021 --> 00:14:03,161
identity of the agent, and the identity of the user.

148
00:14:05,361 --> 00:14:11,981
But policies are ceilings. Agents can do things you didn't intend, even when policy overall allows them.

149
00:14:14,421 --> 00:14:18,561
This brings us to something called intent-based authorization, or IBA.

150
00:14:19,221 --> 00:14:23,101
Now, IBA checks what you mean before the agent acts.

151
00:14:23,501 --> 00:14:25,521
Now, it's not a finalized standard.

152
00:14:25,521 --> 00:14:26,841
They're still accepting proposals.

153
00:14:26,841 --> 00:14:30,901
So this is Keycard's approach to implementing intent-based authorization.

154
00:14:33,821 --> 00:14:37,861
Now, IBA can use a gateway as a policy enforcement point.

155
00:14:39,261 --> 00:14:42,901
When you send the prompt to the agent, it proposes a mission.

156
00:14:43,801 --> 00:14:49,461
this mission includes a goal, maybe allowed actions, as well as limits to what the agent is allowed to do.

157
00:14:49,861 --> 00:14:57,041
So a goal of triage incident 2294 means read that ticket, summarize, or escalate.

158
00:14:57,181 --> 00:15:00,381
But don't read other tickets and don't use other services.

159
00:15:02,401 --> 00:15:05,161
So the security token service receives this mission.

160
00:15:05,401 --> 00:15:12,161
In this case, a low-risk activity like just assessing a ticket might be auto-approved under admin policy.

161
00:15:14,061 --> 00:15:24,721
On the other hand, if we've already read the ticket and then we ask to remediate a usage spike, then the mission adds permission to scale the service once, but not use other tools or APIs.

162
00:15:26,241 --> 00:15:30,581
Now, in this case, the mission is presented for the user to review and approve.

163
00:15:32,921 --> 00:15:37,721
Once approved, the security token service gives the mission an ID, which is sent to the agent.

164
00:15:39,361 --> 00:15:48,381
The tool calls include this mission ID and are proxied by the gateway, which uses the ID to ask the security token service if this tool call fits the mission.

165
00:15:48,961 --> 00:15:55,541
If it does, then the gateway requests a token exchange for access to the MCP server for that specific tool call.

166
00:15:57,621 --> 00:16:00,021
The STS evaluates policy.

167
00:16:01,781 --> 00:16:05,381
It evaluates the delegation chain, and it looks at the requested access.

168
00:16:05,381 --> 00:16:18,241
Now, if everything looks good, it issues an access token for the MCP server, and it keeps the user subject, as well as adds the app that performed the exchange, which is, in this case, our on-call agent.

169
00:16:18,581 --> 00:16:23,741
Now, this token should expire within minutes, and we should never store it. It's ephemeral.

170
00:16:24,201 --> 00:16:27,901
The STS sends it to the gateway, which calls the MCP server.

171
00:16:28,781 --> 00:16:32,341
The server then validates the token and authorizes the tool call.

172
00:16:35,381 --> 00:16:37,701
Now, some tools need external resources.

173
00:16:38,101 --> 00:16:47,121
So the MCP server then asks the security token service to exchange the token that it just received for a token for the downstream resource.

174
00:16:47,501 --> 00:16:50,701
Now, the STS evaluates the request against policy.

175
00:16:51,681 --> 00:16:56,561
if it passes, then it mints a resource token that's scoped again to that tool call.

176
00:16:57,401 --> 00:17:05,641
It keeps the user subject, which extends the delegation chain and allows us to be able to track all of the activity.

177
00:17:08,421 --> 00:17:15,421
The STS sends the token to the gateway, which proxies the request to the MCP server, which then calls the resource.

178
00:17:17,721 --> 00:17:20,901
The resource validates the token and authorizes access.

179
00:17:21,341 --> 00:17:25,741
Now, the MCP server should never store the token. It should discard it immediately after the call.

180
00:17:27,421 --> 00:17:34,321
The resource response then flows back up and the agentic loop repeats until the model returns the answer to the user.

181
00:17:38,481 --> 00:17:48,621
So now we're going to look at the same demo, except we are going to use a security token service to manage agent access control with delegated authorization.

182
00:17:48,621 --> 00:17:54,581
The demo uses task-based policy governance, not intent-based authorization.

183
00:17:54,941 --> 00:17:59,601
But if you're going to AgentCon later this month, we'll have IBA demos there.

184
00:18:01,961 --> 00:18:09,881
Now we also now have an MCP server that establishes tools and it provides brokering access to the resources.

185
00:18:11,021 --> 00:18:15,481
So now we're back to our on-call triage agent again, only this time we have authentication.

186
00:18:16,301 --> 00:18:20,781
Now I'm going to go ahead and sign into the On-Call Agent Triage app.

187
00:18:26,121 --> 00:18:28,141
I'm going to log in with Google to do so.

188
00:18:33,441 --> 00:18:35,281
And then you get another login screen.

189
00:18:35,461 --> 00:18:38,961
Now this is where I'm going to sign into the Incidex Pager platform.

190
00:18:44,641 --> 00:18:48,741
So I get a prompt to grant the on-call agent access to my Incidex account.

191
00:18:49,421 --> 00:18:54,701
I'm going to let it escalate incidents on my behalf, post notes and summaries, and read the queue.

192
00:19:01,101 --> 00:19:03,981
Now I'm being prompted to log into the cloud hosting platform.

193
00:19:05,101 --> 00:19:08,121
So I am going to do that.

194
00:19:14,441 --> 00:19:19,981
And I get another consent screen now, which allows me to authorize the agent to access

195
00:19:19,981 --> 00:19:23,341
some capabilities of CompuHost on my behalf.

196
00:19:28,101 --> 00:19:31,021
Now, finally, I am back on the on-call dashboard.

197
00:19:31,361 --> 00:19:35,321
Now we have the same queue of tickets, only now the audit log looks different.

198
00:19:36,041 --> 00:19:39,221
The agent is probably going to try to behave the same way it did before,

199
00:19:39,501 --> 00:19:46,261
only now every request is going to go through the STS and policy evaluation

200
00:19:46,261 --> 00:19:50,041
before a token is granted and the agent will be authorized to act.

201
00:19:52,641 --> 00:19:56,681
So we have the same queue of tickets, only now the audit log looks different.

202
00:19:56,841 --> 00:20:00,281
And the agent is probably going to behave the same way that it did before,

203
00:20:00,561 --> 00:20:04,661
only now every request is going to go through the STS and policy evaluation

204
00:20:04,661 --> 00:20:08,601
before a token will be granted and the agent can be authorized to act.

205
00:20:09,441 --> 00:20:11,901
So the first ticket is that billing anomaly.

206
00:20:18,161 --> 00:20:28,641
Again, the agent tries to read the ticket, and we can see that it is trying to do the same thing that it did before.

207
00:20:28,841 --> 00:20:34,301
It tries to query the customer warehouse, but policy doesn't allow a credential to be issued for this.

208
00:20:34,661 --> 00:20:39,501
because customer PII doesn't belong in an agent's context or in an incident ticket.

209
00:20:40,881 --> 00:20:45,861
So the agent proceeds without the customer data and it escalated it to the morning team.

210
00:20:59,821 --> 00:21:03,841
Now we have the website security certificate expiring.

211
00:21:08,741 --> 00:21:11,621
Now, this is something that the agent has permission to do.

212
00:21:11,841 --> 00:21:17,441
So when it requests credentials to do this from the STS, access is granted, and it can

213
00:21:17,441 --> 00:21:20,081
call the Cloud Hosting API and resolve this ticket.

214
00:21:24,541 --> 00:21:28,701
Now, you can see all of the calls that it's making and who is making them.

215
00:21:28,701 --> 00:21:35,401
So we have the on-call triage agent that is requesting to renew the certificate.

216
00:21:35,801 --> 00:21:41,401
It's asking for permission to call the appropriate tool from the Infra MCP server.

217
00:21:41,681 --> 00:21:43,841
So it gets a token for that.

218
00:21:44,381 --> 00:21:55,481
After that, the MCP server is going to request access to that cloud hosting service in order to renew the certificate using the API.

219
00:22:00,381 --> 00:22:08,761
So if we move on to the billing database, it's going to read the ticket through the incident

220
00:22:09,361 --> 00:22:09,921
API.

221
00:22:10,561 --> 00:22:13,241
It's going to come to the same conclusion that it did before.

222
00:22:13,581 --> 00:22:19,501
The agent knows that this is a drop and restore procedure, but this time policy forbids an

223
00:22:19,501 --> 00:22:21,221
agent to drop a production database.

224
00:22:21,601 --> 00:22:23,421
A human's got to do this manually.

225
00:22:25,081 --> 00:22:36,201
And we can see this in the audit log where the STS refused to grant the token exchange for access to the database delete.

226
00:22:41,701 --> 00:22:44,501
So now we have our orders are stuck.

227
00:22:44,821 --> 00:22:45,941
The main server is frozen.

228
00:22:47,261 --> 00:22:49,721
The agent is going to go ahead and read the ticket.

229
00:22:51,801 --> 00:22:56,441
it. It wants to restart the main server. This takes production brief fuel offline.

230
00:22:56,441 --> 00:23:01,461
It informs me about this, and this time it's actually asking for my approval to do this.

231
00:23:02,401 --> 00:23:08,381
So I'm going to click approve. However, this was also blocked by policy, and the reason for this

232
00:23:08,381 --> 00:23:15,101
is because my user does not have the role necessary to take this action.

233
00:23:17,421 --> 00:23:21,521
So the agent can't do it, but I can't do it either, and the agent is acting on my behalf.

234
00:23:25,321 --> 00:23:28,421
If we move to the site failing for one in three users.

235
00:23:33,221 --> 00:23:37,261
Again, the agent wants to add more servers, and it's going to ask for permission.

236
00:23:37,281 --> 00:23:42,081
It's going to say what we're committing to when we do this.

237
00:23:42,801 --> 00:23:44,701
I'm going to go ahead and approve this.

238
00:23:45,941 --> 00:23:50,361
And this is something that my role does have the authority to do.

239
00:23:50,561 --> 00:23:53,721
So the scale goes through and this ticket is resolved.

240
00:23:56,301 --> 00:23:59,341
So we can see that the agent access problems are solved.

241
00:23:59,561 --> 00:24:00,021
We

242
00:24:00,021 --> 00:24:14,701
know the user and the agent identity all the way down the chain. The agent has task-scoped ephemeral access to the MCP server and downstream resources. And we have human in the loop with access control that's actually backed by policy.

243
00:24:17,801 --> 00:24:26,521
Now, access is controlled at the task level by the security token service and policy, and we retain all key capabilities.

244
00:24:29,281 --> 00:24:53,061
Now, token exchange is an open standard. It's well-researched and it's public, so anyone can implement it, and it interoperates with existing policy engines and standards-compliant identity providers, as well as things like gateways, sandboxes, OAuth, off-the-shelf and custom agents, CLIs, MCP servers, software factories, agent-to-agent, cross-app access, plus whatever comes out next week.

245
00:24:53,061 --> 00:24:57,741
so I hope you'll consider it to make your agents useful, safe, and future-friendly.

246
00:25:00,541 --> 00:25:05,641
My name is Kim Maida. I'm the founding GTM engineer and head of DevRel at Keycard.

247
00:25:08,161 --> 00:25:10,021
And I really appreciate your time today, so thank you very much.