WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=ws9XcGGPBDk

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/ws9XcGGPBDk.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.040 --> 00:00:07.919
Today I'm going to talk to you about how your agent is a lethal trifecta and what to do about it.

s2
00:00:07.919 --> 00:00:11.120
Now we're going to start out right off the bat with a demo.

s3
00:00:11.120 --> 00:00:12.639
Some context on this demo.

s4
00:00:12.639 --> 00:00:20.160
We're going to look at an on call triage agent that reads and writes to an incident pager and resolves or escalates tickets.

s5
00:00:20.160 --> 00:00:27.840
This agent has full access to a cloud hosting API, a customer data warehouse as well as a billing database.

s6
00:00:28.320 --> 00:00:40.000
So here we have our on call triage agent and it has an incident queue of tickets that it's going to read and then if it can resolve them it's going to call the available services

s7
00:00:40.000 --> 00:00:47.520
that it has access to and it's going to do so things that it can't resolve it's going to escalate for the morning team.

s8
00:00:47.520 --> 00:00:51.760
So if we take a look at this first ticket this is a billing anomaly.

s9
00:00:51.760 --> 00:00:56.160
It says a batch of customers were overcharged last night.

s10
00:00:56.160 --> 00:01:01.840
So the first thing the agent does is it directly calls the incidex API in order to read the ticket.

s11
00:01:01.840 --> 00:01:07.520
And if you look here, you can see that it authorized access to this API using an API key.

s12
00:01:07.520 --> 00:01:16.400
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.

s13
00:01:16.400 --> 00:01:18.880
And it writes a report for the morning team.

s14
00:01:18.880 --> 00:01:21.520
And as you can see, it's sharing customer data.

s15
00:01:21.520 --> 00:01:21.759
Right?

s16
00:01:21.759 --> 00:01:25.200
These are rows directly pulled from the customer data warehouse.

s17
00:01:25.200 --> 00:01:33.840
and it is sending personally identifiable information to the team that is going to be on staff in the morning.

s18
00:01:37.360 --> 00:01:41.520
Now this next ticket is a backup power supply failed in the server room.

s19
00:01:41.520 --> 00:01:44.000
The agent is going to read the ticket again.

s20
00:01:44.000 --> 00:01:48.960
It's using an API key to call the ticket API.

s21
00:01:48.960 --> 00:01:51.439
It determines that this is a physical problem.

s22
00:01:51.439 --> 00:01:57.040
So it escalates for morning review without calling any additional services.

s23
00:01:59.680 --> 00:02:04.240
This one is the TLS certificate is expiring soon for the website.

s24
00:02:04.240 --> 00:02:05.280
It reads the ticket.

s25
00:02:05.280 --> 00:02:07.680
It determines that the alert is clear.

s26
00:02:07.680 --> 00:02:19.520
It has access to the cloud hosting API and it calls that API at the certificate renew endpoint using again an API key.

s27
00:02:19.520 --> 00:02:30.959
It resolves this by renewing the certificate and it leaves a report for the morning crew by calling the pager uh incident API as well.

s28
00:02:32.160 --> 00:02:36.160
This next one is the billing database is broken and payments are failing.

s29
00:02:36.160 --> 00:02:42.560
So the documented recovery for this is to drop and restore the database.

s30
00:02:42.640 --> 00:02:53.920
The agent does this using the database connection string that includes the admin password and then it advises the morning team to make sure that the snapshot recovery worked.

s31
00:02:53.920 --> 00:02:58.480
Now this is not something that it has access to directly.

s32
00:02:58.480 --> 00:03:10.400
So it is essentially assuming that the morning team is going to verify that this did in fact work and the information was restored.

s33
00:03:11.920 --> 00:03:19.920
Now an overprivileged agent dropping a production database is basically a nightmare that several companies have actually lived.

s34
00:03:19.920 --> 00:03:23.680
So this is something that we need to be very careful of.

s35
00:03:23.680 --> 00:03:25.840
Now the next one is orders are stuck.

s36
00:03:25.840 --> 00:03:28.720
The main server is frozen.

s37
00:03:28.959 --> 00:03:32.080
So the agent is again is going to read the ticket.

s38
00:03:32.080 --> 00:03:38.400
After reading the ticket, the agent calls the cloud hosting API using again its static API key.

s39
00:03:38.400 --> 00:03:43.760
It calls the endpoint to restart the server which brings production offline.

s40
00:03:48.799 --> 00:03:53.120
Finally, site is failing for one in three visitors.

s41
00:03:53.519 --> 00:03:55.599
Agent reads the ticket.

s42
00:03:55.599 --> 00:04:03.040
It determines that it should call the cloud hosting API and scale the service from four pods to 40.

s43
00:04:03.040 --> 00:04:08.560
It then incurs a charge of $420 per hour for doing this.

s44
00:04:08.560 --> 00:04:14.080
And then it kindly leaves a note for the morning team informing them that this has happened.

s45
00:04:16.560 --> 00:04:19.919
Now, what makes an agent useful?

s46
00:04:19.919 --> 00:04:29.040
Well, typically we want agents to have a minimum set of capabilities and often this includes things like the ability to read data that you own or have access to.

s47
00:04:29.040 --> 00:04:33.919
This might be like your email, your documents, maybe a customer CRM.

s48
00:04:33.919 --> 00:04:36.240
We want the agent to be able to do its own research.

s49
00:04:36.240 --> 00:04:42.560
So this might include searching the web, maybe reading documentation or pulling issues from GitHub.

s50
00:04:42.560 --> 00:04:50.240
And we usually want it to be able to use external tools, for example, MCP servers or APIs, maybe SAS platforms.

s51
00:04:50.240 --> 00:04:57.120
And useful agents might do these things with a human in the loop or they might be doing it autonomously in the background.

s52
00:04:57.120 --> 00:05:02.560
But the thing that makes the things that make agents useful also make them dangerous.

s53
00:05:02.560 --> 00:05:09.120
In fact, together these three capabilities make what Simon Willis coined as a lethal trifecta.

s54
00:05:09.120 --> 00:05:18.720
This is a combination of access to private data like the on call agents ability to query the customer data warehouse and interact with the billing database.

s55
00:05:18.720 --> 00:05:33.520
exposure to untrusted content like reading user submitted tickets or reports from other agents or externally documented processes and the ability to communicate externally like reading and writing with third party APIs or SAS services.

s56
00:05:33.520 --> 00:05:38.479
Now together these capabilities throw the doors wide open for attackers.

s57
00:05:39.199 --> 00:05:47.680
Now agents are designed to get the job done and they'll use all the powers that they have to do it sometimes with very serious consequences.

s58
00:05:47.840 --> 00:05:49.199
But here's the thing.

s59
00:05:49.199 --> 00:05:55.520
These incidents happen because humans give agents way more access than they need.

s60
00:05:55.520 --> 00:06:02.720
Overprivileged agents can act freely on decisions that they make, even if they do have supervision.

s61
00:06:03.680 --> 00:06:10.319
Now, forcing a human in the loop approval just kind of passes the access control on to a consent fatigued user.

s62
00:06:10.319 --> 00:06:13.840
Now, we've spent decades solving access management for humans.

s63
00:06:13.840 --> 00:06:20.240
So shifting responsibility to the user just sort of moves the security problem up the chain.

s64
00:06:21.039 --> 00:06:23.280
So what should we do about the lethal trifecta?

s65
00:06:23.280 --> 00:06:27.680
How do we address it without compromising the agents usefulness?

s66
00:06:28.720 --> 00:06:35.520
Well, just removing one or more of these capabilities is going to cause the agent to be significantly less useful.

s67
00:06:35.520 --> 00:06:39.360
So how can we keep all three but still be safe about it?

s68
00:06:39.360 --> 00:06:45.280
Well, instead of breaking the trifecta by removing capabilities, we really need to control the agents access.

s69
00:06:45.280 --> 00:06:54.240
So, the attack surface is minimized and the blast radius is contained, but the agent still has capability and autonomy.

s70
00:06:54.639 --> 00:06:57.280
So, how do we do that?

s71
00:06:57.280 --> 00:07:08.479
Well, some options for controlling access among others are things like using OOTH, maybe using a vendor MCP gateway or containing execution in sandboxes.

s72
00:07:09.360 --> 00:07:12.319
Now, OOTH binds access to a grant.

s73
00:07:12.319 --> 00:07:17.280
At grant time, the user consents to all of the permissions that the agent could possibly use.

s74
00:07:17.280 --> 00:07:20.639
Now, consent is granted before any task exists.

s75
00:07:20.639 --> 00:07:25.120
So, if you give a broad grant, then you end up withstanding access.

s76
00:07:25.120 --> 00:07:28.960
Your agent is over permissioned for any single specific task.

s77
00:07:28.960 --> 00:07:34.479
If you narrow the grant and you don't give it very many permissions, then the agent just becomes less capable.

s78
00:07:34.479 --> 00:07:38.800
Either way, OOTH alone doesn't provide task scoped access control.

s79
00:07:38.800 --> 00:07:48.000
An enthusiastic agent can both read and write in the same run, even if you only want it to read on this specific task.

s80
00:07:48.240 --> 00:07:51.440
Now, an MCP gateway binds enforcement to a route.

s81
00:07:51.440 --> 00:07:58.240
You get things like observability and rate limits, and you also get one policy decision point at the MCP layer.

s82
00:07:58.240 --> 00:08:09.440
Now policy runs per request and access is granted per user but the agents granted access outlives any single task because the gateway still holds standing credentials.

s83
00:08:09.759 --> 00:08:12.319
Now a sandbox binds execution to a process.

s84
00:08:12.319 --> 00:08:20.240
This controls the blast radius but useful work has to reach outside the sandbox and when it does so you end up with standing access again.

s85
00:08:20.240 --> 00:08:24.800
Now we've also seen plenty of stories about agents breaking sandbox containment.

s86
00:08:24.800 --> 00:08:33.039
Sandboxes bound what the processes can do, but they don't control what is authorized to act outside the sandbox itself.

s87
00:08:33.599 --> 00:08:42.959
Now, even if you combine all three of the solutions, the agent still doesn't receive a runtime credential that's downscoped to only one task.

s88
00:08:43.839 --> 00:08:47.680
So, let's recap the problems, especially the ones that we saw in the demo.

s89
00:08:47.680 --> 00:08:52.959
If you remember the audit log, we couldn't tell who was using the API keys.

s90
00:08:52.959 --> 00:08:59.200
So the first problem is that credentials weren't attributed to a user or an agent's identity.

s91
00:08:59.200 --> 00:09:05.839
The agent had unrestricted access to any and all permissions that were granted by the API keys.

s92
00:09:05.839 --> 00:09:10.560
And finally, we can't just slap human in the loop everywhere because humans make mistakes, too.

s93
00:09:10.560 --> 00:09:15.839
Plus, many agents run autonomously and they don't even have a human in the loop.

s94
00:09:16.240 --> 00:09:20.399
So to solve these problems, we can start by using something called token exchange.

s95
00:09:20.399 --> 00:09:30.560
Now this is an existing standard that was published in 2020 and it extends OOTH 2. Now first we need to know who the user is.

s96
00:09:30.560 --> 00:09:34.320
Now an authorization server verifies identities and issues tokens.

s97
00:09:34.320 --> 00:09:39.519
Identity providers like Google, Octa, Ozero etc provide authorization servers.

s98
00:09:39.519 --> 00:09:46.880
So if we want an identity chain in our agent execution path then the user has got to log in first.

s99
00:09:47.920 --> 00:09:55.040
The authorization server is going to prompt the user for consent to delegate access to resources with some subset of their permissions.

s100
00:09:55.040 --> 00:09:56.959
Now, these permissions are called scopes.

s101
00:09:56.959 --> 00:09:59.040
This is the first narrowing of access.

s102
00:09:59.040 --> 00:10:04.720
We're only delegating some of the user's total scopes to the agent.

s103
00:10:05.920 --> 00:10:11.360
The authorization server issues tokens identifying the user and their level of access.

s104
00:10:11.360 --> 00:10:18.880
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.

s105
00:10:20.240 --> 00:10:25.040
So this brings us into the agentic execution path.

s106
00:10:25.040 --> 00:10:27.040
Now we have our authenticated user.

s107
00:10:27.040 --> 00:10:33.120
So we have a known identity of a person who wants to use an LLM to interact with a resource.

s108
00:10:33.120 --> 00:10:40.800
Now in the demo the resources are the incident pager, the production database, snowflake and the cloud hosting service.

s109
00:10:41.200 --> 00:10:44.560
An agent is a control loop that calls an LM.

s110
00:10:44.560 --> 00:10:53.760
Often we have an MCP server that sits between the agent and its resources, providing defined tools that connect to those downstream services.

s111
00:10:54.800 --> 00:11:00.000
An MCP client dispatches the agent's proposed tool calls to its MCP server.

s112
00:11:00.000 --> 00:11:09.920
Now, in the demo, the on call triage agent called resources directly with long live static credentials like API keys or database connection strings.

s113
00:11:10.720 --> 00:11:14.399
So what we're going to do is we're going to give the on call agent an MCP server.

s114
00:11:14.399 --> 00:11:20.399
This is going to provide tools and is also going to serve to broker access to resources.

s115
00:11:23.279 --> 00:11:28.560
Now an agent runtime is a process that runs the agent loop and executes calls.

s116
00:11:28.560 --> 00:11:38.399
The runtime might be a CLI like clouded code or an agent SDK which might be implemented in a custom application like the on call agent.

s117
00:11:38.800 --> 00:11:42.240
So let's follow a prompt through this execution path.

s118
00:11:42.240 --> 00:11:47.760
The user submits the prompt to the runtime which calls the model and sends the prompt to the LLM.

s119
00:11:47.760 --> 00:11:58.240
The model then proposes tool calls which are dispatched by the MCP client to its MCP server which executes tools and then calls the resource API.

s120
00:12:00.079 --> 00:12:03.839
The API returns the response to the MCP server.

s121
00:12:03.839 --> 00:12:08.160
The MCP client delivers the response to the runtime which calls the model again.

s122
00:12:08.160 --> 00:12:15.120
And this loop repeats until the model is satisfied and returns a response to the user.

s123
00:12:16.880 --> 00:12:20.800
Now the authenticated user's token becomes what we call a subject token.

s124
00:12:20.800 --> 00:12:26.880
This identifies who the agent is acting on behalf of, who it acts for.

s125
00:12:27.600 --> 00:12:31.440
Now token exchange needs an ooth client that can execute code.

s126
00:12:31.440 --> 00:12:41.760
So this might be a gateway that sits between the MCP client and the third party MCP server or it might be your custom app.

s127
00:12:41.920 --> 00:12:46.800
Now a custom MCP server can also exchange tokens for downstream resources.

s128
00:12:46.800 --> 00:12:53.760
The on call agents MCP server should provide a defined set of production infrastructure tools.

s129
00:12:54.720 --> 00:12:57.839
The prompt and the subject token are sent to the runtime.

s130
00:12:57.839 --> 00:13:02.399
The agent loop runs and the model proposes a tool call.

s131
00:13:04.240 --> 00:13:09.120
The runtime authenticates with a special authorization server called a security token service.

s132
00:13:09.120 --> 00:13:13.600
It does this using its app client credentials or workload identity.

s133
00:13:13.600 --> 00:13:19.120
It also sends the subject token that contains the user's identity and access.

s134
00:13:19.360 --> 00:13:27.600
It creates a token exchange request asking for permission to access the MCP server for that tool call and only that tool call.

s135
00:13:27.600 --> 00:13:32.800
So now we have three pieces of info that we're missing from the demo.

s136
00:13:33.760 --> 00:13:37.040
We know the identity of the agent that's requesting access.

s137
00:13:37.040 --> 00:13:40.320
We know the identity of the user it's acting on behalf of.

s138
00:13:40.320 --> 00:13:44.880
And we know the level of access that the user granted to the agent.

s139
00:13:44.959 --> 00:13:48.560
Now we need to decide if the requested token should be issued.

s140
00:13:48.560 --> 00:14:01.360
And we can do this with governance policy which is evaluated against what access is requested from what resource, the identity of the agent and the identity of the user.

s141
00:14:02.160 --> 00:14:03.680
But policies are ceilings.

s142
00:14:03.680 --> 00:14:10.240
Agents can do things you didn't intend even when policy overall allows them.

s143
00:14:11.279 --> 00:14:15.760
This brings us to something called intentbased authorization or IBA.

s144
00:14:15.760 --> 00:14:20.320
Now, IBA checks what you mean before the agent acts.

s145
00:14:20.320 --> 00:14:22.160
Now, it's not a finalized standard.

s146
00:14:22.160 --> 00:14:23.519
They're still accepting proposals.

s147
00:14:23.519 --> 00:14:28.959
So, this is Keycard's approach to implementing intentbased authorization.

s148
00:14:30.639 --> 00:14:36.079
Now, IBA can use a gateway as a policy enforcement point.

s149
00:14:36.079 --> 00:14:39.920
When you send the prompt to the agent, it proposes a mission.

s150
00:14:39.920 --> 00:14:46.720
Now, this mission includes a goal, maybe allowed actions as well as limits to what the agent is allowed to do.

s151
00:14:46.720 --> 00:14:58.480
So, a goal of triage incident 2294 means read that ticket, summarize or escalate, but don't read other tickets and don't use other services.

s152
00:14:59.199 --> 00:15:02.320
So, the security token service receives this mission.

s153
00:15:02.320 --> 00:15:10.240
In this case, a low-risk activity like just assessing a ticket might be auto approved under admin policy.

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

s155
00:15:22.959 --> 00:15:28.720
Now, in this case, the mission is presented for the user to review and approve.

s156
00:15:29.600 --> 00:15:36.000
Once approved, the security token service gives the mission an ID which is sent to the agent.

s157
00:15:36.160 --> 00:15:45.760
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.

s158
00:15:45.760 --> 00:15:53.920
If it does, then the gateway requests a token exchange for access to the MCP server for that specific tool call.

s159
00:15:54.399 --> 00:15:58.000
The STS evaluates policy.

s160
00:15:58.560 --> 00:16:02.560
It evaluates the delegation chain and it looks at the requested access.

s161
00:16:02.560 --> 00:16:15.360
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.

s162
00:16:15.360 --> 00:16:19.519
Now, this token should expire within minutes and we should never store it.

s163
00:16:19.519 --> 00:16:20.720
It's ephemeral.

s164
00:16:20.720 --> 00:16:25.519
The STS sends it to the gateway, which calls the MCP server.

s165
00:16:25.519 --> 00:16:30.639
The server then validates the token and authorizes the tool call.

s166
00:16:31.759 --> 00:16:34.959
Now, some tools need external resources.

s167
00:16:34.959 --> 00:16:44.160
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.

s168
00:16:44.160 --> 00:16:54.160
Now, the STS evaluates the request against policy and if it passes, then it mints a resource token that's scoped again to that tool call.

s169
00:16:54.160 --> 00:17:03.680
It keeps the user subject which extends the delegation chain and allows us to be able to track all of the activity.

s170
00:17:05.120 --> 00:17:13.600
The STS sends the token to the gateway which proxies the request to the MCP server which then calls the resource.

s171
00:17:14.480 --> 00:17:17.919
The resource validates the token and authorizes access.

s172
00:17:17.919 --> 00:17:20.160
Now the MCP server should never store the token.

s173
00:17:20.160 --> 00:17:24.000
It should discard it immediately after the call.

s174
00:17:24.319 --> 00:17:32.559
The resource response then flows back up and the agentic loop repeats until the model returns the answer to the user.

s175
00:17:35.360 --> 00:17:46.000
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.

s176
00:17:46.000 --> 00:17:57.840
The demo uses task based policy governance, not intentbased authorization, but if you're going to Agent Con later this month, we'll have IBA demos there.

s177
00:17:58.880 --> 00:18:07.919
Now, we also now have an MCP server that establishes tools and it provides brokering access to the resources.

s178
00:18:07.919 --> 00:18:13.039
So, now we're back to our on call triage agent again, only this time we have authentication.

s179
00:18:13.039 --> 00:18:18.880
Now I'm going to go ahead and sign into the on call agent triage app.

s180
00:18:22.799 --> 00:18:26.400
I'm going to log in with Google to do so.

s181
00:18:30.160 --> 00:18:31.919
And then I get another login screen.

s182
00:18:31.919 --> 00:18:37.039
Now this is where I'm going to sign into the Incidex pager platform.

s183
00:18:41.280 --> 00:18:46.080
So, I get a prompt to grant the on call agent access to my Incidex account.

s184
00:18:46.080 --> 00:18:53.039
I'm going to let it escalate incidents on my behalf, post notes and summaries, and read the queue.

s185
00:18:57.760 --> 00:19:01.919
Now, I'm being prompted to log into the cloud hosting platform.

s186
00:19:01.919 --> 00:19:06.160
So, I am going to do that.

s187
00:19:11.120 --> 00:19:21.520
And I get another consent screen now which allows me to authorize the agent to access some capabilities of compost on my behalf.

s188
00:19:24.880 --> 00:19:28.080
Now finally I am back on the on call dashboard.

s189
00:19:28.080 --> 00:19:32.559
Now we have the same queue of tickets only now the audit log looks different.

s190
00:19:32.559 --> 00:19:36.320
The agent is probably going to try to behave the same way it did before.

s191
00:19:36.320 --> 00:19:48.240
Only now every request is going to go through the STS and policy valuation before a token is granted and the agent will be authorized to act.

s192
00:19:49.360 --> 00:19:59.840
So we have the same queue of tickets only now the audit log looks different and the agent is probably going to behave the same way that it did before only now every request is going to go through the STS

s193
00:19:59.840 --> 00:20:06.240
and policy evaluation before a token will be granted and the agent can be authorized to act.

s194
00:20:06.240 --> 00:20:10.000
So the first ticket is that billing anomaly.

s195
00:20:14.880 --> 00:20:25.600
Again the agent tries to read the so the agent is reading the ticket and we can see that it is trying to do the same thing that it did before.

s196
00:20:25.600 --> 00:20:37.760
It tries to query the customer warehouse but policy doesn't allow a credential to be issued for this because customer PII doesn't belong in an agent's context or in an incident ticket.

s197
00:20:37.840 --> 00:20:44.159
So the agent proceeds without the customer data and it escalated it to the morning team.

s198
00:20:56.720 --> 00:21:01.840
Now we have the website security certificate expiring.

s199
00:21:05.520 --> 00:21:08.480
Now this is something that the agent has permission to do.

s200
00:21:08.480 --> 00:21:18.400
So when it requests credentials to do this from the STS access is granted and it can call the cloud hosting API and resolve this ticket.

s201
00:21:21.280 --> 00:21:26.320
Now you can see all of the calls that it's making and who is making them.

s202
00:21:26.320 --> 00:21:32.720
So we have the on call triage agent that is requesting to renew the certificate.

s203
00:21:32.720 --> 00:21:38.559
It's asking for permission to call the appropriate tool from the prod infra MCP server.

s204
00:21:38.559 --> 00:21:40.799
So it gets a token for that.

s205
00:21:40.799 --> 00:21:53.600
After that, the MCP server is going to request access to that cloud hosting service in order to renew the certificate using the API.

s206
00:21:57.120 --> 00:22:07.280
So, if we move on to the billing database, it's going to read the ticket through the incident API.

s207
00:22:07.280 --> 00:22:10.000
It's going to come to the same conclusion that it did before.

s208
00:22:10.000 --> 00:22:18.240
The agent knows that this is a drop and restore procedure, but this time policy forbids an agent to drop a production database.

s209
00:22:18.240 --> 00:22:21.520
A human's got to do this manually.

s210
00:22:22.000 --> 00:22:34.480
And we can see this in the audit log where the STS refused to grant the token exchange for access to the database delete.

s211
00:22:38.559 --> 00:22:41.120
So now we have our orders are stuck.

s212
00:22:41.120 --> 00:22:44.080
The main server is frozen.

s213
00:22:44.080 --> 00:22:48.000
The agent's going to go ahead and read the ticket.

s214
00:22:49.200 --> 00:22:51.120
It wants to restart the main server.

s215
00:22:51.120 --> 00:22:53.280
This takes production briefly offline.

s216
00:22:53.280 --> 00:22:59.200
It informs me about this and this time it's actually asking for my approval to do this.

s217
00:22:59.200 --> 00:23:01.120
So I'm going to click approve.

s218
00:23:01.120 --> 00:23:12.240
However, this was also blocked by policy and the reason for this is because my user does not have the role necessary to take this action.

s219
00:23:12.240 --> 00:23:14.080
Right?

s220
00:23:14.080 --> 00:23:19.679
So the agent can't do it but I can't do it either and the agent is acting on my behalf.

s221
00:23:22.000 --> 00:23:34.000
If we move to the site failing for one in three users again, the agent wants to add more servers and it's going to ask for permission.

s222
00:23:34.000 --> 00:23:39.360
It's going to say what we're committing to when we do this.

s223
00:23:39.360 --> 00:23:42.720
I'm going to go ahead and approve this.

s224
00:23:42.720 --> 00:23:47.200
And this is something that my role does have the authority to do.

s225
00:23:47.200 --> 00:23:51.760
So the scale goes through and this ticket is resolved.

s226
00:23:53.039 --> 00:23:56.240
So we can see that the agent access problems are solved.

s227
00:23:56.240 --> 00:24:00.320
We know the user and the agent identity all the way down the chain.

s228
00:24:00.320 --> 00:24:06.799
The agent has task scoped ephemeral access to the MCP server and downstream resources.

s229
00:24:06.799 --> 00:24:12.799
And we have human in the loop with access control that's actually backed by policy.

s230
00:24:14.720 --> 00:24:24.400
Now access is controlled at the task level by the security token service and policy and we retain all key capabilities.

s231
00:24:26.000 --> 00:24:28.159
Now token exchange is an open standard.

s232
00:24:28.159 --> 00:24:40.559
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

s233
00:24:40.559 --> 00:24:56.000
ooth offtheshelf and custom agents CLIs MCP servers software factories agent to agent crossapp access plus whatever comes out next week so I hope you'll consider it to make your agents useful safe and future friendly

s234
00:24:57.120 --> 00:24:58.559
now my name is Kim Maida.

s235
00:24:58.559 --> 00:25:03.600
I'm the founding GTM engineer and head of Devril at Keycard.

s236
00:25:04.880 --> 00:25:06.480
And I really appreciate your time today.

s237
00:25:06.480 --> 00:25:09.120
So, thank you very much.