AI Engineer World's Fair 2025
Securing Agents with Open Standards
Read the talk
Securing Agents with Open Standards
Agents need more than permission to call tools: they need a user identity, bounded access, and a way to obtain approval before sensitive actions execute.
From a talk by Bobby Tiernay and Kam Sween
Before you start: Basic familiarity with API access tokens, LLM tool calls, and TypeScript will help you follow the walkthrough.
Who is the agent acting for?
When an agent takes an action on someone’s behalf, how do you establish whose authority it used? Bobby Tiernay and Kam Sween approach that question through their engineering work at Auth0: Auth for Gen AI, the Auth0 MCP server, and the first-party agent Tenant Security Manager. Their practical concern is delegation: connecting an agent’s ability to act with the particular user who authorized it.
Once agents move beyond chat, the failure modes become concrete. Secrets can leak into prompts or logs. Scopes can grant more access than an operation needs. A system can appear to work while recording too little information to reconstruct an incident. The missing evidence is often basic: who requested an action, what the agent did, and when it happened.
Bobby frames this through the access-control side of OWASP’s excessive agency risk. API calls, data retrieval, tokens, credentials, and keys all give an agent ways to affect a system. That access needs limits, monitoring, and a connection to a real user. Sensitive data exposure follows the same concern: an agent that can reach unauthorized material may disclose it. As agents start workflows and change systems, the relevant identity cannot stop at the application’s service account; it must preserve the individual user’s context.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Replace shared keys with delegated tokens
The first concrete comparison is an agent calling an API with a shared key loaded from an environment variable. The key may be reused across users, environments, and services. The request succeeds, but the credential does not distinguish the people behind those requests. Rotation becomes a manual coordination problem, and the key’s permissions may be much broader than any one task requires.
The alternative inserts a backend into the credential flow. The agent requests access for one user and one target API. The backend uses a mechanism such as OAuth token exchange to provide a short-lived token. This gives the system a place to centralize token handling and associate downstream activity with user context.
| Concern | Shared environment-variable key | Delegated token flow |
|---|---|---|
| User context | Reused across users | Bound to a particular user |
| Target access | Broad, reused permissions | Limited to the target API |
| Credential lifecycle | Manual key rotation | Short-lived tokens, centrally managed |
| Accountability | Shared credential obscures attribution | User context supports an audit record |
Bobby reports that this approach has scaled better in their experience, including deployments with dozens or hundreds of agents; he supplies no measured benchmark.
Token scope is useful only when the system knows whose authority it represents. Identity connects actions to users, supports investigation, and informs subsequent access decisions. An agent running under a service account may possess considerable authority without knowing which user’s permissions should constrain a particular request. That creates the conditions for a confused deputy: the agent can exercise its own access on behalf of someone who should not have it.
The proposed foundation combines OAuth 2.1, Rich Authorization Requests, and token exchange, while preserving upstream identity and handling token refresh properly. In Bobby’s sequence, the agent asks the backend for access; the backend retrieves the necessary material from a vault and obtains a short-lived token for the user and API. The application uses that token transiently instead of making the agent a persistent store of secrets. The custody point is to avoid long-lived secrets carried around by the agent, not to assume that a usable access token can never enter application memory.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Control what the model sees and when the agent acts
In retrieval-augmented generation, authorization determines which information becomes model context. Different users should not automatically retrieve the same documents. Enforce access at the retrieval layer, before sensitive data reaches the LLM. Asking the model to decide whether it should reveal material is too late: the material has already crossed the boundary. Fine-grained policy enforcement belongs in the system that supplies the context.
Some actions also need approval at the moment they are about to happen. Client-Initiated Backchannel Authentication, or CIBA, separates the agent’s request from the device on which the user authenticates and approves it:
- The agent sends a request to the authorization server.
- The server contacts the user through a trusted device, for example with a push notification.
- The user approves or denies the request; Bobby also describes the possibility of asking for more information.
- The application receives the authorization outcome and can continue accordingly.
This suits background agents and environments without a screen available for a browser redirect. It removes the need for an approval interface on the agent’s device, not the user’s participation on the trusted device.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Remote MCP makes identity a request-level concern
MCP introduces another boundary as tools move from local processes communicating over standard input and output to shared servers on a network. A local integration’s assumptions do not automatically carry over to a remote, distributed system. Each request now needs a trustworthy association between the caller, the user, and the requested action.
The pattern presented here uses browser sign-in, followed by token issuance handled by the MCP server, with the agent’s scope and binding established before issuance. The client does not expose third-party credentials. This reflects the March 2025 MCP authorization specification, which referenced OAuth 2.1 as an IETF draft. Later MCP resource-server arrangements should not be substituted for this historical walkthrough. The security requirement remains straightforward: on a shared tool server, establish who is making each request and what that identity is allowed to do.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A local trading assistant with an approval boundary
Kam brings these pieces together in a local AI trading assistant. He points to a collection of examples from the application’s package.json, then introduces the scenario: an agent makes local tool calls to a broker service to buy stock, but the user must explicitly approve the action before it executes. The design has three parts:
- User identification and context: establish which user the agent represents.
- Token vault: keep secrets and sensitive token handling out of the application’s embedded configuration.
- CIBA: obtain consent before executing the sensitive action.
The identity provider must support CIBA, an OpenID Connect specification. Auth0 supplies that role in the demo, but the pattern does not require Auth0 specifically.
The application is a TypeScript CLI with a stock-trading tool, inspected in IntelliJ. Kam mentions a Python example as forthcoming; the walkthrough here remains in TypeScript.
Before opening the runtime code, he sketches a fuller trading system. A user tells a chatbot to buy stock at a particular threshold. A polling service tracks the changing price. When the threshold is reached, the system requests approval through CIBA immediately before executing the trade. The demo leaves out parts of that monitoring stack to concentrate on identity and consent. Kam’s joke about trading rules based on vibes and Truth Social posts underscores why the live example avoids making market behavior its central dependency.
The runtime separates conversation handling from session setup. generateMessages mediates between the user and the LLM, with the buy tool supplied to it. main establishes the context and binds it to a particular session thread. That association gives tool execution a stable answer to “which user is using this session?” rather than requiring the model to infer identity from conversation text.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Authenticate, pause for consent, then call the tool
The tool definition is wrapped in two higher-order functions. useDeviceFlow bootstraps the OIDC authentication client so the application can obtain access tokens on behalf of a user. useCIBA intercepts the sensitive tool call and lets the user approve or deny it, supplying the identity provider with configuration about the requested resource use. These are the wrapper names shown in the recording, rather than a claim about today’s SDK signatures.
The demo uses a blocking callback: the application waits for approval before proceeding. An asynchronous continuation or polling arrangement could also be used. Blocking is an application choice, not a requirement that CIBA impose the same execution model on every client. The essential boundary can be expressed in TypeScript as a wrapper around a tool:
typescript
type Session = { userId: string };
type Tool<Input, Output> = (
input: Input,
session: Session
) => Promise<Output>;
type Approval<Input> = (
request: { userId: string; input: Input }
) => Promise<"approved" | "denied">;
function requireApproval<Input, Output>(
approve: Approval<Input>,
execute: Tool<Input, Output>
): Tool<Input, Output> {
return async (input, session) => {
const decision = await approve({
userId: session.userId,
input
});
if (decision !== "approved") {
throw new Error("User did not approve the action");
}
return execute(input, session);
};
}
Here, approve is the integration boundary for the approval flow. The tool receives the same input and session only after approval; a denial never reaches execute.
Inside the buy tool, Kam highlights the credential-handling call at line 28. The displayed code retrieves credentials, assigns an access token, and adds an authorization header before a POST request. He identifies the utility as Auth0 Token Vault and distinguishes its token-management role from a password manager such as 1Password. Tokens are still sensitive credentials; the useful distinction is that the tool obtains the token it needs without embedding client secrets in its source.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The ten-share request and the intended approval flow
As Kam starts the services, he emphasizes that local execution does not eliminate identity requirements. Multiple users, multiple agents, access to user files, and compliance concerns still demand attribution of who accessed what and when. This demo does not have a fully stateful service that persists user identity, so it begins with authentication through a user interface. Once the application has the user’s tokens, CIBA handles approval of sensitive actions without another login interface in the CLI.
OAuth, OIDC, and CIBA therefore belong in the initial application design, even if they are not the first features a developer wants to build. Kam acknowledges a competing pressure in an example application: enough infrastructure to make the security behavior meaningful, but little enough that readers can follow it. The simplified local services and blocking approval callback keep attention on that boundary.
The live request is to buy ten stocks of SECO. The intended next step is for the LLM to interpret the request and select the stock-buying tool. The attempt stalls; Kam attributes the interruption to Wi-Fi and switches to describing what should have happened. No completed approval or successful trade is shown, and the broker is a local mock trading service rather than a connection executing a real market transaction.
In the narrated flow, the authentication middleware would first prompt Kam to log in and obtain tokens for the agent to act on his behalf. CIBA would then send the authorization request to Auth0’s backend and trigger a notification on his phone. The notification would identify the agent and the proposed purchase of ten shares, rather than presenting a generic approval request without context. Kam could approve and advance the flow or cancel it. Subsequent trades would reuse the authenticated session, but each would still pass through CIBA approval. Signing in establishes identity; it does not preapprove every later trade.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Standards supply the foundation; integrations connect the pieces
Kam closes the demo by acknowledging that he has talked through the flow rather than successfully shown it. The components nevertheless correspond to defined protocols: OIDC for identity, CIBA for backchannel authentication and consent, and Rich Authorization Requests for richer authorization expressions. He describes Auth0’s offerings at the time as a mixture of developer previews and production capabilities, but is explicitly unsure whether CIBA is generally available or still in early access. The recording should not be treated as a definitive release-status announcement.
Bobby returns to the integration work left above those protocols. Standards reduce the need to invent identity mechanisms, but developers still need usable connections among authentication, delegated API calls, token exchange and storage, asynchronous confirmation, and authorization for retrieved data. Auth0 packages those pieces in Auth for Gen AI; Bobby notes that other platforms offer similar capabilities. OpenFGA is another option for fine-grained authorization without requiring Auth0’s platform.
The closing invitation extends beyond that product packaging. Bobby asks developers to bring the identity and access problems they encounter in practice, describes his participation in MCP specification discussions, and points to open-source work such as MCP Auth. The remaining engineering work is to make these standards usable together: carry the user’s authority through the agent’s tool calls, enforce access before data or actions cross a boundary, and return consequential decisions to the user when consent is required.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The standard for backchannel authentication and consent, including poll, ping, and push token delivery.
The token-exchange standard covering delegation, impersonation, and target resources.
Structured authorization requests for expressing permissions beyond simple scope strings.
The March 2025 MCP specification describes OAuth-based authorization for HTTP transports.
An MCP server for Auth0 administration, with setup instructions and controls over exposed tools. The repository labels it beta.
An open-source engine for modeling and enforcing fine-grained permissions, with local setup instructions.
SDK setup for connecting an MCP resource server to a compatible authorization provider.
Further reading
JavaScript integrations and examples for tool authorization, RAG access control, and asynchronous user confirmation.
Updates since the talk
Current guidance for storing external-provider tokens and accessing APIs on users' behalf.
Read the complete timestamped transcript
- 0:00
[on-hold music] Hi, everybody.
- 0:16
I'm Bobby, this is Kam.
- 0:17
Hi.
- 0:17
And, uh, we're both engineers here at Auth0, and we've both been working a lot in this, uh, the AI space lately, um, trying to come up with clear ways for identity and access control that's designed for a world where agents are center stage.
- 0:34
So that's included our work on our Auth for Gen AI platform, our Auth0 MCP server, and our own first-party agent called Tenant Security Manager. And just like everyone here, we're learning from the community as well as we do this.
- 0:47
Just the main thing is trying to get to grips with what delegation and access means in a world where agents are acting on users' behalf. Um, and today, we wanna share some of those lessons that we've learned in this journey, and, um, what's actually worked, what hasn't worked, and a few practical ways that you can get started
- 1:06
with identity and access right from the start.
- 1:10
But, uh, I had to splash this slide 'cause we were shown-- [laughs] we were told we could have opinions as long as we showed it. So here we go. To kick things off, let's talk about, uh, the security challenges of smarter agents, um, as they start to do more things in the real world.
- 1:27
And once they're moving behind-- beyond chat and actually doing things in the, in the real world, cla- cracks are starting to appear, and it's pretty clear. Secrets end up in prompts, scopes get too broad, and troubleshooting gets really, really hard when you don't have the right visibility.
- 1:43
So agents are out there making decisions, taking actions on behalf of users, but it's very easy to lose track of what's really going on. Uh, things might look fine on the surface right up until there's a security incident, and you realize you don't have enough data to trace what actually happened.
- 2:01
This is where a lot of the gen AI risks begin. The OWASP, OWASP calls it excessive agency, but really that's just a fancy way of saying giving agents too much access without guardrails.
- 2:13
And access here means calling APIs, pulling data, using tokens, touching credentials and keys. If that access isn't scoped, monitored, and tied to a real user, you're wide open to abuse and unintended behavior.
- 2:27
And there's other OWASP risks too, like sensitive data exposure, but that often comes back to the same root cause. If an agent reaches into something it shouldn't, it's usually because no one told it not to.
- 2:39
And if you've been listening to the talks here, it's pretty clear that agents aren't just responding to prompts anymore. They're actually doing real things, calling APIs, kicking off workflows, changing your systems.
- 2:51
And that means they're moving through your stack, touching real user data, interacting with real external systems. And it all needs to happen under the right context, not just on behalf of your app, but on behalf of your users, individuals.
- 3:07
Here's what this looks like in practice. Uh, on the left, you see a pattern that's very common, and an agent calling an API using a shared p-- uh, key pulled from an environmental variable.
- 3:18
Um, that key probably gets reused across users, environments, maybe even different services. It works, but it's fragile. You can't tell who did what, and rotating s- uh, secrets and keys is manual and risky, and the access is way too broad.
- 3:34
On the right, things are looking better. Instead of a shared static key, the agent asks your backend for a token that's just for the one user and one API.
- 3:43
The backend uses something like token exchange to hand out short-lived token, and the agent can safely use that. Now you've got a real record of who did what, and you can easily rotate tokens, support multiple upstream systems, and manage up-- uh, all of this in a centralized way.
- 4:00
And we've seen that this, uh, approach scales much better, even if you have dozens or hundreds of agents. It's a small tweak in your flow, but a big step up in how you handle risk.
- 4:12
So we've talked about the secrets and shared credentials problem, but underneath it all is identity. If your agent doesn't have identity, it doesn't matter how well you scope your tokens or rotate tokens, you still have-- don't have real control here.
- 4:25
And identity is what connects actions to users. It lets you understand what happened, trace the activity, and decide what should happen next. But before we talk about delegation and scope, we need to get identity right.
- 4:38
So if identity is the part we're often missing, the next question is, who is the agent actually working for? If you don't have a clear answer, chances are it's just running as a service account, and that's how you get the confused deputy problem that you've been hearing a lot about, uh, this week.
- 4:53
The agent has access, but it doesn't know who it's acting for, what it should avoid. The fix is to anchor that behavior into real users using standard flows like OAuth 2.1, RAR, uh, and token exchange to tightly control what the agent can do.
- 5:08
Um, that includes refreshing tokens properly, properly and preserving upstream identity. And here's how it works in practice. When an agent needs to act, it doesn't grab a key from a static config.
- 5:20
Instead, it, uh, asks your backend for help. The backend reaches into a vault, fetches a credential, and uses token exchange to, uh, to s-- to mint a token that's short-lived just for this user and API.
- 5:33
That token never sits with the agent. It's handed off, used, and gone. And this keeps your agent focused on doing its job, not carrying around secrets. And it lines up with familiar OWASP standards, so you're not inventing the wheel, what you should never do with identity.
- 5:47
And let's shift gears now to the RAG systems. When you're using RAG, you're not just handing data to the model, you're making choices about what it sees. And not every user should unlock the same data context.
- 5:59
This is where fine-grained authorization matters. You don't want the agent deciding access inside your LLM. You want that enforced much earlier at the retrieval layer where policy enforment-- uh, uh, enforcement can kick in.
- 6:12
So you wanna do this so that none of your sensitive data leaks out, and You keep your company and your users secure. Um, early we covered how to scope the access which agent can see, but sometimes that's not enough.
- 6:27
You also need to control when and how that a- access is provisioned. That's where Client-Initiated Backchannel Authentication, which is a mouthful, or CIBA comes in. Instead of showing a UI, the agent sends a request to the authorization server.
- 6:43
The server reaches out to the user on a trusted device via something like a push notification, and then the user decides whether to approve, deny, or ask for more information.
- 6:54
Um, this pattern is really great for agents running in the background or in scenarios where there's no screen to direct a user to. And Kam's gonna show the demo where this really comes to life.
- 7:04
So keep this flow in the back of your mind when you see that. And of course, we can't talk about secure agent execution without talking about MCP. Um, MCP servers are showing up everywhere these days.
- 7:16
What started as local standard IO input on your, on your laptop is quickly turning into a core part of remote distributed systems. And once you put it on the network, security can't be an afterthought.
- 7:30
This pattern here uses, um, OAuth 2.1 flow. The user signs in through the browser. MCP server handles the token minting behind the scenes. Agent gets scoped and bound up front, and the token is issued.
- 7:43
Client never exposes third-party credentials. The key takeaway is that when every tool and action runs on a shared server, the need for solid guarantees about who's making each request and doing what they're actually doing becomes critical.
- 7:56
All right. So to bring this all together, Kam's gonna show what this looks like in practice. He's gonna go through the, the CIBA flow and example. Kam, over to you.
- 8:04
Sweet. Thanks, Bobby. Um, lot of talking points. This is, uh, gonna be a challenging demo. Uh, so thanks for outlining some of the, uh, security and identity challenges that are facing production-grade, uh, API agent or AI agents.
- 8:16
Building on that overview, um, you can actually find this demo, uh, alongside of a ton of other really great working demos, um, at the following URL that I've got highlighted in the package JSON of this little application.
- 8:26
Um, for our scenario, we're gonna do a, a local AI trading assistant that's gonna make local tool calls to a broker service in order to buy stock, right? Uh, we tried to make this, uh, as applicable as possible.
- 8:37
Uh, the AI agent is gonna initiate the request, but the user is gonna have to explicitly approve it before, uh, it's executed. I don't have enough screens, so I'm gonna pull another one up.
- 8:44
This'll be really fun. Bear with me. All right. So, um, this is gonna really, um, emphasize three critical components for us. So we're gonna have user identification and context, which is gonna identify the user so that the agent can act on their behalf.
- 8:57
Uh, we're gonna use the token vault to, uh, prevent us from embedding any kind of like, you know, secrets or, uh, sensitive data inside of our actual code. And then we're gonna use CIBA or Client-Initiated Backchannel Authentication, uh, to request user consent before the agent executes, uh, sensitive actions.
- 9:11
It's worth highlighting, uh, this is gonna require an identity provider that supports CIBA. Um, you know, our Auth0 is the company we w- work for. Um, but importantly, like CIBA is part of the OIDC specification, so this is gonna become more ubiquitous over time.
- 9:23
Uh, so taking a look at the app that's driving this demo, um, [lip smacks]
- 9:28
zoom out a couple here. Gotta love IntelliJ. I'm gonna hide this too. There we go. Okay, so we're using a pretty simple TypeScript CLI application. Anybody speak TypeScript in the room?
- 9:40
Show of hands. Few. Okay. All right. Uh, the Python demo will come later. Um, so [chuckles] um, this is basically just gonna expose a command line interface on, uh, f- for the user, uh, which is configured with a stock trading, um, tool.
- 9:53
Let me make sure that a couple of prereqs that I need are true.
- 9:59
Bear with me one second. All right. Um, I do not see what I'm looking for,
- 10:09
but that should be fine, hopefully. Um, so, um, rolling back, um, in a more mature trading environment, it would probably look something like this. Um, so you'll have this user who's gonna specify, you know, buy some stock, um, at a certain threshold, which will get dispensed as a user action that'll interface with your, um, chatbot.
- 10:27
There'd be some sort of polling s- system that would be capable of understanding what like the real-time value of that stock trade is over time. And then it would, um, at the time where whatever threshold is defined, at that point, it would then execute the trade, and prior to executing the trade, it would dispatch a CIBA request
- 10:41
to make sure that the user is able to authenticate that, right at the, at the last mile. Um, now with today's stock volatility being what it is, it'd be a real challenge to define any reliable trade rule based on vibes and Truth Social posts.
- 10:52
So we're gonna elide, uh, certain elements of this stack. That was a joke. I hope you enjoyed that. Um, [chuckles] let's stay on the script now. Um, so we're gonna take a look at the actual application.
- 11:01
So this is the primary agent configuration and runtime definition, um, inside of this stack. You can see it's, um, bifurcated into two primary methods. You've got the generateMessages method, which is basically the handler that's interfacing between the LLM and the user.
- 11:14
Here we're passing in this buy tool, which we're gonna dig into a little bit more. [lip smacks] Um, then subsequent to that, you have the main method, which is gonna run on the main thread.
- 11:21
Here's where we're going to define the context and bind it to a particular thread for this particular session. This is gonna give us the ability to, um, durably identify who, uh, who is using this particular, um, uh, session.
- 11:35
Um, so within that, let's take a look at the actual tool call. Um, so here we have, uh, the definition of a tool call inside of, uh, this application.
- 11:45
Um, you'll note that it's wrapped in two higher order component, uh, functions. So there's this useDeviceFlow. Taking a look at that, um, this is basically how it is, um, that we are, uh, bootstrapping the OIDC, uh, wrapper within this application.
- 11:59
That's gonna enable us to have an auth client bootstrap for the application. This enables me to use access tokens on behalf of a user, basically. So there's a whole lot of configuration that goes into that.
- 12:08
Stepping back, there's another handler, this useCIBA, um, higher order component. So this is basically gonna enable, um, this application to, um, intercept a tool call in which we want the user to be able to approve or deny behavior, and that's really the h- the heart of CIBA.
- 12:22
It's also where we provide configuration information to our identity provider about how we're gonna use the resources. So in our case, we're using a blocking callback down here. Um- Which is going to, um, actually pause the application while it's running in order to wait for the approval.
- 12:36
Um, you could wire this up with an asynchronous flow or polling or however you wanted to. Um, but for the sake of this demo, this was a lot easier.
- 12:43
Uh, one last thing that I'll highlight here, uh, inside of the buy tool call, uh, the way that we're handling credentials here on line 28, um, this prevents us from embedding, um, client secrets directly inside of the code, which is a nice utility, uh, method.
- 12:56
In Auth0, we call this our token vault. Uh, it's dissimilar from like, um, like [REDACTED:password] or like a credential manager. This is managing tokens, not credentials. So, uh, just a little bit of a note there.
- 13:06
So let's get these services running. Uh, fingers crossed we don't run into, uh, any super fun Wi-Fi issues.
- 13:13
May the Wi-Fi gods be forever on our side. As that comes up, um, so even with local AI a- agents, identity matters, especially when you're using, um, multiple users with multiple agents involved, um, or if the agent has access to, you know, user data or user files, right?
- 13:28
So it's crucial to know who the, um, who is interacting with what and at what time, uh, especially like once compliance gets into this, it gets a lot more, um, robust.
- 13:36
So we're, uh, not using a fully stateful service to preserve and persist the user's identity. Um, so instead, we're gonna authenticate the users through the UI. So you'll notice that, um, little blurb will pop up.
- 13:45
After that, when the AI agent needs to perform a sensitive action, like executing a trade, we're gonna rely on CIBA. That means no additional user-facing UI is required after the u- user has given us their tokens, and I'll give you a little bit of a demo of that.
- 13:56
So we're definitely aware that identity standards like OAuth 2, OIDC, CIBA, these are not always top of mind or super interesting for developers when you're building great applications. That's why we're highlighting that there are solutions to these problems.
- 14:07
There's open standards that are evolving over time, um, and a lot of those are live today. Um, so that can be something to be thought of, uh, in the pr- progenation of an application instead of as an afterthought.
- 14:17
So one thing that we run into repeatedly while building this demo is determining just how much complexity is needed to effectively showcase, um, you know, these sorts of scenarios.
- 14:26
Um, please let us know how we struck that balance. Uh, you can email Bobby directly. Uh, he loves feedback. All right, uh, so now [chuckles] for the fun part. Let's try and buy some stocks with this, uh, if the Wi-Fi gods are on our side.
- 14:37
So, um, buy me 10 stocks of SECO, just, uh, some company. So what this is gonna do, um, is the LLM is gonna process the intent, and it's gonna select the buy stock tool.
- 14:48
The agent is going to send, uh, [laughs] I love Wi-Fi. It's my favorite thing. Um, let's see if there isn't a way around... Um, I can just sort of talk through this at a high level.
- 15:00
We'll take a look at, um, this piece of our demo. So, um, what would, what would have h- you know, ideally happened is we would execute that trade. Because we have bootstrapped our middleware inside of this application, it would prompt me to log in, and once I logged in, then the agent would have tokens to use on
- 15:16
my behalf as a user. That would then execute a trade. It's not actually executing a trade. I have like a local trade service running, so you're not missing many highlights, don't worry.
- 15:24
Um, and then once the trade, um, or once I authenticated, then CIBA would immediately dispatch a notification to Auth0's backend, and it would blow up my phone, and I would get a little notification that's like, "Hey, would you like to approve and authorize this trade?"
- 15:38
One nice thing about the notification that I get is it's not just gonna tell me, "Hey, something happened. Would you like to approve it?" And I'm just gonna be left generically in the middle of the ether trying to figure out where this notification came from.
- 15:48
It's actually gonna say, "This agent tried to do this a- action," which in this case is purchasing 10 shares of something, "on your behalf. Would you like to approve that downstream flow?"
- 15:57
And then I have the autonomy as an end user to, to determine whether or not I'm going to advance that flow or cancel that flow. Uh, one other thing that I would've shown is once I've authenticated the agent to act on my behalf, subsequent trades no longer need me, um, in the loop outside of the CIBA flow.
- 16:11
So once I've authentic- or yeah, once I've authenticated in, the authorization flow is then just dispatched to CIBA, which is pretty cool. Um, so going back to my notes, I'm gonna see how many things that I missed.
- 16:23
A bunch of things, but that's okay. Um, so in summary, we saw, well, kind of, I talked through how an agent can identify and act on behalf of a specific user, how to store and access credentials securely, um, and how to use CIBA to get explicit user approval for high-risk actions like trading without a brigh- browser to
- 16:39
be required. Um, so these patterns are live. Um, they exist in defined standards like OIDC, CIBA, um, Rich Authorization Requests. Auth0, um, developer previews have like, um, attempts at a lot of these things or actual production versions of a lot of these things, so I'd encourage you guys to check some of those things out.
- 16:55
Um, and some of these are GA. Like our, uh, CIBA, I believe, is GA or at least in early access, um, inside of our platform, so that's pretty cool.
- 17:01
Um, thanks. That's, uh, my demo.
- 17:04
All right. So just moving back here. Go to the next slide.
- 17:08
Cool.
- 17:10
As Kam was saying, like we're, we're trying to make this easier for, for developers. Um, the standards are great. It means you're not reinventing things over and over again.
- 17:19
But there's still a lot of building blocks that you would have to build. The Auth0, other platforms have similar things, but we're, we're trying to wrap this all up in a nice experience for developers.
- 17:29
So the async user confirmation with CIBA is like a very key component here, uh, as well as calling APIs on behalf of users, things like token exchange and token vault, as well as fine-grained authorization for RAG.
- 17:43
You don't have to use our platform for this. We have OpenFGA that can snap into this type of thing as well. Um, and user authentication and authorization generally is, is something that we do, we think deeply about.
- 17:57
And with that, here's what you can take with you. There's a nice QR code, and we'd love to talk to anyone who's struggling with these challenges, what you've hit, uh, in your, in your, in your d- day-to-day life.
- 18:12
Just come talk to us after the talk. Um, I'm, I'm also part of the Open MCP spec, uh, driving some of those discussion as well. We're very interested in improving that for everybody, so it's not just about Auth0.
- 18:25
Working with other, um, open source libraries like MCP Auth, which is another great thing. So very deeply interested in this space.
- 18:34
Thanks everyone.
- 18:34
Thank you