WEBVTT

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

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

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.440 --> 00:00:13.440
Uh hi everybody.

s3
00:00:13.440 --> 00:00:14.760
My name is Kamil.

s4
00:00:14.760 --> 00:00:17.120
I work at Key Card in a product team.

s5
00:00:17.120 --> 00:00:21.320
I'll be talking to you today about agent authentication authorization requirements.

s6
00:00:21.320 --> 00:00:23.480
We have around 18 minutes ish.

s7
00:00:23.480 --> 00:00:25.840
That's nowhere close to be able to cover this topic.

s8
00:00:25.840 --> 00:00:35.600
So, my goal today is to give you kind of high-level overview of what's required to do this, how to kind of solve these problems, and give you context to come and ask us questions at the booth.

s9
00:00:35.600 --> 00:00:36.320
We downstairs.

s10
00:00:36.320 --> 00:00:41.080
So, just whatever questions you have, feel free to grab me at the end or go find Peter.

s11
00:00:41.080 --> 00:00:43.640
He has all the answers.

s12
00:00:43.880 --> 00:00:46.880
We're going to start with this fairly simple diagram.

s13
00:00:46.880 --> 00:00:53.640
You're probably familiar with this in any of the talks you have about agents and how they communicate with MCP servers and other agents around.

s14
00:00:53.640 --> 00:01:01.280
But, what usually people don't talk about is how are these agents and users communicate with each other, how do they authorize and make requests.

s15
00:01:01.280 --> 00:01:08.160
So, what we come across and what we see often is that users obtain some sort of access credential.

s16
00:01:08.160 --> 00:01:12.640
They they might be called personal access tokens or just tokens.

s17
00:01:12.640 --> 00:01:19.520
And they kind of represent opaque credential identifying these users and letting the agent decide if they're going to perform this action or not.

s18
00:01:19.520 --> 00:01:24.120
If your agent is running locally, sometimes this step is skipped and nothing else happens.

s19
00:01:24.120 --> 00:01:28.600
When a request comes to the agents, they need to credentials of their own to even perform the actions, right?

s20
00:01:28.600 --> 00:01:33.920
Like the common thing that they need is an API key to talk to the model provider that allows them to kind of do the reasoning.

s21
00:01:33.920 --> 00:01:41.240
So, whenever the kind of LLM model decides to do some actions, they often call tools.

s22
00:01:41.240 --> 00:01:46.960
When we need to do those tool calls, often we use remote MCP servers to perform them.

s23
00:01:46.960 --> 00:01:50.760
And in order to communicate with them, hopefully, we need another credentials to do that.

s24
00:01:50.760 --> 00:01:54.600
And we have couple of options that we've seen in the industry.

s25
00:01:54.600 --> 00:01:59.480
Sometimes the agents will just use Alice's or like users PAT tokens and pass them through.

s26
00:01:59.480 --> 00:02:06.692
Sometimes they will have their own static keys and luckily enough uh uh we see more and more use of all of kind of dynamic credentialing that happens there.

s27
00:02:06.692 --> 00:02:12.412
But whenever MCP server receives that token they usually just kind of see the user as the identity that acts with it.

s28
00:02:12.412 --> 00:02:20.012
So MCP server doesn't really know if it's like an agent running it, is it like Alice's CLI or is it like any other tool that does it?

s29
00:02:20.012 --> 00:02:24.812
MCP servers are often used to kind of enclose existing infrastructure.

s30
00:02:24.812 --> 00:02:35.572
So if you have like internal APIs, databases, even external systems that are not kind of agent friendly, we can use MCP servers to represent that communication and optimize that interaction.

s31
00:02:35.572 --> 00:02:43.692
But in order to do that these MCP servers often need to have access to these back-end services and act kind of act for multiple users.

s32
00:02:43.692 --> 00:02:48.212
So they cannot just use one user's bot token because that will be limited to that scope.

s33
00:02:48.212 --> 00:02:56.652
They they often use service accounts and those service accounts kind of become aggregator of permissions so that these servers can communicate.

s34
00:02:56.652 --> 00:02:58.572
Um And this is nothing new.

s35
00:02:58.572 --> 00:03:03.372
We've seen this pattern in the past in kind of service-to-service communication in your traditional SaaS software.

s36
00:03:03.372 --> 00:03:06.852
However, what's what's different about agents?

s37
00:03:06.852 --> 00:03:08.812
They're not deterministic software, right?

s38
00:03:08.812 --> 00:03:17.612
So whenever the request comes back to the agent and it sees them some data, it will send it back to the model and it will decide to to do what it wants to do to do with it next.

s39
00:03:17.612 --> 00:03:21.532
In this case we're using an abstract example of invoicing service.

s40
00:03:21.532 --> 00:03:26.372
So imagine the agent receives a request to go and look at the recent invoice.

s41
00:03:26.372 --> 00:03:29.332
It gets it back an invoice says I'm pending, it should be sent to the user.

s42
00:03:29.332 --> 00:03:36.012
An agent either maliciously or is just too helpful decides to go and send this invoice to a user.

s43
00:03:36.012 --> 00:03:38.612
Now the question becomes who is making this request?

s44
00:03:38.612 --> 00:03:41.212
Was this Alice or was this the agent?

s45
00:03:41.212 --> 00:03:41.732
We don't know.

s46
00:03:41.732 --> 00:03:44.772
There's nothing to determine that in reality.

s47
00:03:44.772 --> 00:03:49.292
Um So what else is wrong with this picture?

s48
00:03:49.292 --> 00:03:53.212
there's a lot of issues with having all of these credentials laying around.

s49
00:03:53.212 --> 00:03:58.452
So whenever users use these access tokens, they're not really attributed to anything.

s50
00:03:58.452 --> 00:04:09.014
So Alice can quite easily take this uh token and put it on her own personal machine uh and then you kind of lose all of that uh corporate infrastructure that might protect it from abuse.

s51
00:04:09.014 --> 00:04:13.654
Um there is no easy way to revoke these credentials, so they kind of lay there and can be abused.

s52
00:04:13.654 --> 00:04:18.974
Um agents as uh they want to do more things, we give them more credentials and they start aggregating them.

s53
00:04:18.974 --> 00:04:22.774
And again, because they kind of non-deterministic, we don't really know what they're going to do with those access keys.

s54
00:04:22.774 --> 00:04:25.894
And finally, we arrive at the old problem of service accounts.

s55
00:04:25.894 --> 00:04:39.054
Again, they're just over-privileged bucket of permissions um and uh re- reality is like we've been okay with the status quo uh in the industry before agents because we kind of relied on the software being released in a secure way.

s56
00:04:39.054 --> 00:04:41.534
We thought about it as something that developers take care of.

s57
00:04:41.534 --> 00:04:43.254
So, we kind of accepted the risk.

s58
00:04:43.254 --> 00:04:48.854
Agent changed all of that because now we live in a world where there is this other actor that can behave on behalf of you.

s59
00:04:48.854 --> 00:04:59.734
I always use this analogy uh like in almost every company I worked at, uh we have this thing when we would walk around and see if one of your colleagues left the laptop unlocked and we would go to the Slack and be like, "I'm buying donuts for everybody today."

s60
00:04:59.734 --> 00:05:02.614
And back then we knew that that is not a good thing.

s61
00:05:02.614 --> 00:05:03.774
So, that we we played this game.

s62
00:05:03.774 --> 00:05:07.134
We would lock the machine down uh and then we would never do it again.

s63
00:05:07.134 --> 00:05:09.294
But agents are basically doing this all the time.

s64
00:05:09.294 --> 00:05:12.574
We just let them run rampant with our credentials and do this all the time.

s65
00:05:12.574 --> 00:05:15.334
So, um we need a better solution to do this.

s66
00:05:15.334 --> 00:05:20.574
And uh funnily enough, technology to solve some of these problems existed for many, many years.

s67
00:05:20.574 --> 00:05:25.214
We just didn't have incentive to kind of um spend time how to implement this properly.

s68
00:05:25.214 --> 00:05:32.134
Um so, instead of Alice uh going trying to figure out where to get access tokens, uh which is also terrible user experience.

s69
00:05:32.134 --> 00:05:35.614
You can kind of think like, "Why why do I need to go and fetch these credentials?"

s70
00:05:35.614 --> 00:05:46.254
Um why wouldn't we have agents um that basically can advertise how to get access to them and then embed into the client's ability to go and request that authorization from some external system.

s71
00:05:46.254 --> 00:05:53.494
And then we can issue this kind of dynamic uh credentials that are scoped to that specific interactions, that limited to the tool that was using it.

s72
00:05:53.494 --> 00:05:55.014
Uh and whenever it's done, it's finished.

s73
00:05:55.014 --> 00:05:57.694
And OAuth as a technology allows us to do this.

s74
00:05:57.694 --> 00:06:07.135
Um and when you think about this, um we kind of solved authentication for users um a long time ago, but then for software, we decided that that's not really a requirement.

s75
00:06:07.135 --> 00:06:14.495
Um but we need to change this and we need to also use technologies that we have available to us to make agents authenticate before we issue them any credentials.

s76
00:06:14.495 --> 00:06:17.255
So, we can use things like workload identity federation.

s77
00:06:17.255 --> 00:06:23.735
There's other mechanism, you can use private key authentication, you can use certificates, you can you can use URL based authorization.

s78
00:06:23.735 --> 00:06:28.615
The mechanism doesn't really matter as long as you use it and make agents authenticate to the systems.

s79
00:06:28.615 --> 00:06:32.895
And funnily enough, once you do that, then you can just kind of repeat the same pattern.

s80
00:06:32.895 --> 00:06:46.135
Instead of giving these agents kind of service accounts and adding like persistent permissions to the service accounts, why don't they just every single time they want to talk to some remote server kind of determine what authorization is required,

s81
00:06:46.135 --> 00:06:49.655
go to this remote service, obtain the token, and go forth.

s82
00:06:49.655 --> 00:06:50.034
And

s83
00:06:50.034 --> 00:06:50.695
[snorts]

s84
00:06:50.695 --> 00:06:56.095
um the only difference between agents and traditional software that we have that I mentioned is that reasoning loop.

s85
00:06:56.095 --> 00:07:00.455
If you take that out of equation, both the legacy software and agent is just software.

s86
00:07:00.455 --> 00:07:10.615
So, again, you can just reuse the same pattern for the application that you're writing now, and nothing changes, and you can kind of go and re-implement the entire stack this way.

s87
00:07:10.615 --> 00:07:12.215
So, that sounds easy.

s88
00:07:12.215 --> 00:07:14.215
So, why we didn't do this before?

s89
00:07:14.215 --> 00:07:20.975
Well, all of this kind of becomes way way way tricky to do when we think about this problem at scale.

s90
00:07:20.975 --> 00:07:27.615
There isn't like one API that we have, there's like hundreds of APIs that we have, and they use different ways to authenticate users.

s91
00:07:27.615 --> 00:07:31.975
Behind those APIs, there's always some sort of authorization server that needs to authenticate the user.

s92
00:07:31.975 --> 00:07:36.415
So, in a previous picture we had we had like one block that we would have to authorize against.

s93
00:07:36.415 --> 00:07:40.495
Now you have clients who need to do this across like hundreds of these services.

s94
00:07:40.495 --> 00:07:42.775
And there isn't like one agent type.

s95
00:07:42.775 --> 00:07:48.215
We're going to have like uh agents that you buy, so your cloud code, agent that you build.

s96
00:07:48.215 --> 00:07:52.975
Sometimes you won't be able to like change that software, so we need to find a way to how we're going to do this.

s97
00:07:52.975 --> 00:07:54.775
And and there isn't like one hop.

s98
00:07:54.775 --> 00:08:03.255
So, now we need to process this kind of delegation flow and verify how all these agents going to talk to other agents and how many hops there can be in that loop.

s99
00:08:03.255 --> 00:08:08.857
And finally, like the biggest problem that we have is the attribution of like who decided to make this action.

s100
00:08:08.857 --> 00:08:14.537
So, we now have like thousands of users who need to consent to these arbitrary actions that agents are doing.

s101
00:08:14.537 --> 00:08:21.577
So, at scale, now we have to solve all of these problems all together in order to make something useful um for us.

s102
00:08:21.577 --> 00:08:28.097
So, in summary, um if we want to have a proper agent authentication system, what do we need to deliver?

s103
00:08:28.097 --> 00:08:30.057
So, first of all, we need agent identities.

s104
00:08:30.057 --> 00:08:33.137
We need a system that's going to issue these identities per agent.

s105
00:08:33.137 --> 00:08:35.297
Uh then that might be even be per session.

s106
00:08:35.297 --> 00:08:38.017
Um but that must be separate from whoever launched it.

s107
00:08:38.017 --> 00:08:41.137
Then we need to be able to express this delegation uh semantics.

s108
00:08:41.137 --> 00:08:47.737
So, we need to be able to say which users are authorized to perform actions with these agents, which agents can act on behalf of other users.

s109
00:08:47.737 --> 00:08:53.577
We need to have a system that can uh issue scoped and short-lived credentials for everything that we do.

s110
00:08:53.577 --> 00:08:57.937
Um and there cannot be like any master key that allows us to do this.

s111
00:08:57.937 --> 00:09:02.417
Um Second, as I mentioned, there's like 100 different systems that we already have.

s112
00:09:02.417 --> 00:09:04.937
We cannot magically hope we can rewrite them all.

s113
00:09:04.937 --> 00:09:06.697
LM are fast, but not that fast.

s114
00:09:06.697 --> 00:09:14.697
Uh so, we need to be able to build a federated trust of identities across them and allow to trust each other when they exchange these systems.

s115
00:09:14.697 --> 00:09:17.897
And again, we're going to have legacy software forever.

s116
00:09:17.897 --> 00:09:22.417
Um you won't be able to kind of go and hope that they will be supporting OAuth anytime soon.

s117
00:09:22.417 --> 00:09:29.937
So, we need to be able to kind of have an adaptive layer, a broker, that allows us to securely exchange those legacy credentials just in time.

s118
00:09:29.937 --> 00:09:33.097
Um and finally, you need to be able to express this with policies.

s119
00:09:33.097 --> 00:09:39.817
Um someone needs to be able to write which uh actions need human approval, which agents can run automatically.

s120
00:09:39.817 --> 00:09:41.977
Um and things will go wrong.

s121
00:09:41.977 --> 00:09:45.857
So, um in order for us to learn uh how to improve things, we need audit.

s122
00:09:45.857 --> 00:09:50.897
Um we need to be able to say who authorized this request and who made this possible.

s123
00:09:50.897 --> 00:09:56.297
Um So, um there's a lot of steps to actually get this right.

s124
00:09:56.297 --> 00:10:06.977
So, um what I want to show you here is just like if you take one interaction between agent and MCP server just to get this working, um you will have a client and a server.

s125
00:10:06.977 --> 00:10:09.257
Um server needs to be be to publish this information.

s126
00:10:09.257 --> 00:10:11.338
Cli- clients need to be able to discover it.

s127
00:10:11.338 --> 00:10:15.178
Then the agents need to be able to obtain these credentials.

s128
00:10:15.178 --> 00:10:18.778
They need to be able to authenticate themselves to this remote server.

s129
00:10:18.778 --> 00:10:25.618
Um then when that happens, uh the MCP server has to be able to validate if those credentials been been correctly signed.

s130
00:10:25.618 --> 00:10:27.538
They need to check if the issue is trusted.

s131
00:10:27.538 --> 00:10:29.458
They need to verify those tokens.

s132
00:10:29.458 --> 00:10:32.138
Um then there is some policy that needs to come into action.

s133
00:10:32.138 --> 00:10:36.058
They need to enforce if the latest rules uh are in play.

s134
00:10:36.058 --> 00:10:42.218
Um once that happens, and they communicate to external system, uh they might need to obtain additional credentials to talk to it.

s135
00:10:42.218 --> 00:10:46.978
Uh and finally, we need to make sure that every single one of these actions is captured in the audit log.

s136
00:10:46.978 --> 00:10:53.778
Um Raise of hands, who thinks LLMs can do this uh every single time perfectly?

s137
00:10:54.458 --> 00:10:55.098
All right.

s138
00:10:55.098 --> 00:10:56.578
Uh I think we're all in agreement.

s139
00:10:56.578 --> 00:11:00.178
Um so, this is not simple, but we have solved similar problems before, right?

s140
00:11:00.178 --> 00:11:10.138
Like we've written shared libraries, we've written middleware, we've written SDKs in order to kind of write these things once, verify with a larger group of people if those performing

s141
00:11:10.138 --> 00:11:13.058
um appropriately, and kind of reuse them all the time.

s142
00:11:13.058 --> 00:11:15.858
Um which sounds like a solution to what we want to do here.

s143
00:11:15.858 --> 00:11:18.938
Um but what are the problems with SDKs?

s144
00:11:18.938 --> 00:11:24.498
So, um it's easy to write them these days, but you need to get them adopted by everybody, right?

s145
00:11:24.498 --> 00:11:29.418
Like if you have gaps in your uh adoption, then well, what's good are your SDKs?

s146
00:11:29.418 --> 00:11:32.298
Um then you need to write them for every single language that you have.

s147
00:11:32.298 --> 00:11:37.938
And LLMs are probably good at writing some of these languages, but probably not the older ones that you have in your system.

s148
00:11:37.938 --> 00:11:42.218
Uh and then what do you do about your cloud codes, your code X that you cannot go and modify, right?

s149
00:11:42.218 --> 00:11:44.618
Like SDKs won't help you there too much.

s150
00:11:44.618 --> 00:11:49.538
Um then if you're going to have bugs because a LLMs make bugs, we write bugs.

s151
00:11:49.538 --> 00:11:57.378
Um in order to fix that, you not only have to fix the SDK, but then you need to track where is this SDK used, and which one of the systems consumed it.

s152
00:11:57.378 --> 00:12:03.178
Um And then finally, so all of these previous four problems existed before, so that's nothing new.

s153
00:12:03.178 --> 00:12:04.898
But agents have additional problem.

s154
00:12:04.898 --> 00:12:14.459
As I said, they kind of act um and trying to be too optimistic, or they can be kind of manipulated do things, and they proved to be very persistent in trying to bypass our controls.

s155
00:12:14.459 --> 00:12:20.779
So, um do we really trust with using just kind of client-side code to be able to manage these credentials securely?

s156
00:12:20.779 --> 00:12:29.979
Of course, they can cache them, they can store them properly, but if they figured out that there is credential that they can use, as long as it's within their own kind of execution environment, we have a problem.

s157
00:12:29.979 --> 00:12:37.819
So, SDKs clearly are not going to solve this problem for many reasons, and additionally, they don't solve the problem of hiding credentials from agents.

s158
00:12:37.819 --> 00:12:46.419
So, if we take this picture, um the challenge that we want to do is to get all of these tokens out of the reach of the agent.

s159
00:12:46.419 --> 00:12:48.179
So, what can we do?

s160
00:12:48.179 --> 00:12:54.859
Well, let's try to move all of these credentials out of this execution environment and put them in some sort of secure enclave.

s161
00:12:54.859 --> 00:13:02.659
So, we can have our kind of runtime authorization system, vaulting service, that can store and kind of broker all these credentials.

s162
00:13:02.659 --> 00:13:06.259
And then the other problem is now how are we going to make use of them?

s163
00:13:06.259 --> 00:13:10.939
So, gateways are something we've used in the past, and they can solve this problem for us.

s164
00:13:10.939 --> 00:13:27.619
So, agents can communicate to the gateway, can request specific target to talk to GitHub, for example, and a gateway can authenticate who's calling it, talk to our runtime authorization service, validate that policies are in place, and fetch the specific credential.

s165
00:13:27.619 --> 00:13:32.339
And then they can simply inject them into the request path and send it forward to GitHub.

s166
00:13:32.339 --> 00:13:46.739
And what that gives us is now we have like a physical control layer where there's simply no way for this agent to obtain this credential unless it's going to be very deterministic and go try to hack our gateway, or even worse, our authorization service.

s167
00:13:46.739 --> 00:13:50.419
But what most importantly, we get couple more properties out of this.

s168
00:13:50.419 --> 00:13:55.499
Even if you use short-lived credentials, they will have some sort of expiry time, right?

s169
00:13:55.499 --> 00:14:00.139
And we still haven't figured out how to do revocation probably across distributed systems.

s170
00:14:00.139 --> 00:14:09.139
But if you use gateways and you force all of your communication through that point, you can have instantaneous revocation because gateway can check every single request on the fly.

s171
00:14:09.139 --> 00:14:13.059
Additionally, agents will do too much.

s172
00:14:13.059 --> 00:14:17.861
A lot of these legacy services won't be able to scope access properly.

s173
00:14:17.861 --> 00:14:22.181
They will have tokens that allow you either admin, read, or write permissions, but they're not good enough, right?

s174
00:14:22.181 --> 00:14:26.341
Like we want to be able to say, "Hey, you can read my email, but you cannot send my email."

s175
00:14:26.341 --> 00:14:34.221
With the gateways, because we can intercept and more importantly introspect all of the requests, we can attenuate that request.

s176
00:14:34.221 --> 00:14:43.781
We can say, "For this specific request, yes, there is a secure credential we're going to use, but if you're trying to send request, we're just going to block it."

s177
00:14:44.061 --> 00:14:55.701
We also get more observability because the gateway is on a network path, we can see exactly what happens for all the requests, and we don't need to change anything in our downstream services.

s178
00:14:55.701 --> 00:14:58.141
But, there's nothing for free in life.

s179
00:14:58.141 --> 00:15:00.981
So, gateways also come with some challenges.

s180
00:15:00.981 --> 00:15:08.741
While you're adding another hop to your call, so if you're really careful about your latencies, that's going to add some to it.

s181
00:15:08.741 --> 00:15:12.061
Um Well, you need to force all your agents to talk to your gateway.

s182
00:15:12.061 --> 00:15:16.541
If they can go bypass it if you don't have strong network controls, then that's not going to help you.

s183
00:15:16.541 --> 00:15:22.341
Additionally, some agents want to have kind of local tool execution, so you're not really guarding against that.

s184
00:15:22.341 --> 00:15:26.341
There's nothing gateway does about your identity problem.

s185
00:15:26.341 --> 00:15:35.341
Yes, agents still need to get some sort of authentication credentials and present it to the gateway in order to have a correct authenticated requests.

s186
00:15:35.341 --> 00:15:43.581
You're also putting a big target on this one thing that you're creating because now what we're saying is like every single credential will go through it.

s187
00:15:43.581 --> 00:15:47.261
So, well, some people will go try try to hack it for you.

s188
00:15:47.261 --> 00:15:50.301
There's a lot of technical complexities with building gateways.

s189
00:15:50.301 --> 00:15:52.021
Some people call them proxies as well.

s190
00:15:52.021 --> 00:15:54.141
TLS is one of those things.

s191
00:15:54.141 --> 00:15:59.781
If you try to intercept that and try to work with all of these systems, you might run into some problems.

s192
00:15:59.781 --> 00:16:11.101
And finally, if you're running distributed system, you have all of these developers building agents, they need to figure it out how they're going to configure the the routes, the policies, the connectors in all of those gateways, right?

s193
00:16:11.101 --> 00:16:17.541
That still someone has to say if agent A can talk to agent B via the gateway.

s194
00:16:17.541 --> 00:16:19.422
And two, someone has to run it.

s195
00:16:19.422 --> 00:16:22.622
Um, so these are all the problems we have with gateways.

s196
00:16:22.622 --> 00:16:28.662
Um, so what we do at Keycard, we think about all of these problems all the time.

s197
00:16:28.662 --> 00:16:35.302
Um, we don't think uh it's it's sensible for everybody to replicate all of these functionalities.

s198
00:16:35.302 --> 00:16:41.662
So, we've built a single control plane um that allows you to both give your agents identities.

s199
00:16:41.662 --> 00:16:45.862
We issue tokens uh in and federate with everything that you have going on.

s200
00:16:45.862 --> 00:16:50.462
Um, we provide you policies and audit um to all of your requests.

s201
00:16:50.462 --> 00:16:56.182
Um, you can get from us all of the client SDKs that allow you to do uh injection and discovery.

s202
00:16:56.182 --> 00:17:00.382
We provide you with service SDKs that you don't have to worry about how they're being authenticated.

s203
00:17:00.382 --> 00:17:14.382
Um, we also give you gateway uh if you really want to have those controls, but fundamentally um you can bring all of these components to us um and kind of pick and choose which one of these capabilities you need to build your system because you might be building a chat application.

s204
00:17:14.382 --> 00:17:17.902
You might be building a complete uh orchestration platform.

s205
00:17:17.902 --> 00:17:21.582
Um, we are fairly unopinionated on the problem you're trying to solve with agents.

s206
00:17:21.582 --> 00:17:25.062
We're just trying to help you solve these in a secure fashion.

s207
00:17:25.062 --> 00:17:32.742
Um, so if you take anything out of this talk uh and want to come talk to us, um agent off isn't an option optional anymore.

s208
00:17:32.742 --> 00:17:40.182
Uh yes, we kind of managed to survive without this for decades, but uh agents proved themselves recently that uh they cannot be trusted.

s209
00:17:40.182 --> 00:17:41.462
Uh reality is messy.

s210
00:17:41.462 --> 00:17:49.702
So, even if you go on a mission of trying to build some of these components, uh make sure that you use open standards uh and to be interoperable with other systems because

s211
00:17:49.702 --> 00:17:52.822
um we're not going to win this game uh by playing uh alone.

s212
00:17:52.822 --> 00:17:58.342
Uh and then really really don't yellow it uh because LLMs won't be able to implement this for you.

s213
00:17:58.342 --> 00:18:05.862
Um, and make sure that whatever you do, check if the code written to implement these uh capabilities is secure.

s214
00:18:05.862 --> 00:18:07.102
Um, thank you.

s215
00:18:07.102 --> 00:18:09.422
Um, if you want to find out about us, come to the booth.

s216
00:18:09.422 --> 00:18:10.622
We're Keycard AI.

s217
00:18:10.622 --> 00:18:13.182
Uh also check out agent baseline.org.

s218
00:18:13.182 --> 00:18:20.862
We have recently uh kind of released uh a software uh factory reference implementation of all of the capabilities that you've seen here.

s219
00:18:20.862 --> 00:18:26.343
So, you can kind of learn and come and work with us on the how to solve this problems.

s220
00:18:26.343 --> 00:18:27.617
That's it.

s221
00:18:27.617 --> 00:18:29.617
[applause]