[music]

We're talking today about identity for

AI agents and how we authorize uh

agents, MCP servers and uh the

Um, we launched a new product uh

actually this week. So, uh, that made

this presentation fun. [laughter] Uh,

had a major release just a few days ago

um, for several of these features and

ging these. Um, um, additionally, I

should probably preface by saying a lot

of this workshop material has been

repurposed and um, our our architect uh,

Abbyek, he goes by nicknames

Shrek.

um kind of prepared a lot of this and

we've kind of massaged it into this

presentation.

Um yeah, so we're going to cover each of

these in depth. um some of the core

features of this new release whether

it's token vault um async off we're not

going deep on FGA but uh just know that

there is another kind of subproduct if

you will that's all around role based

access control um there's an open-

source project around fine grain do off

um which really extends this feature set

but that's really kind of another talk

Um,

so yeah, that's some of the things we'll

be talking. Uh, quick intros. Uh, uh,

it's my first time at AIE, so thank you

guys. It's been awesome week already.

Learned so much. Um, um, yeah, I'm I'm

from Raleigh, not not actually a Shire,

but [laughter]

uh, this is a little bit about me. Um,

and, uh, yeah, it's been great. I came

over from Duasio from Red Hat and I've

learned a lot about the identity space

in the last four years. Um I'm going to

roll over to Carlos.

>> Yeah. Hi. Um yeah, I'm I'm Carlos. I'm

co-host with uh Patrick for this

workshop today. Um first time in New

York, first time in the US. So great so

far. Uh thank you for the welcoming. Um

I'm best in Spain in Mayor if you know

the place it's a beautiful island. Um I

joined Al and Octa. Um I did a bit more

two years

father of two and well yeah it's a

little bit of about myself.

So I'm going to I want to start this

with a vision that I'll zero share. uh

this is uh to free everyone to safely

use any technology

and the fun fact about this is is a

vision that precedes the AI Asian era uh

and still stands uh because at the end

of the day is what what we do uh we deal

with identity for past, present and

future technology and yeah um

just to give a little bit of

what's the challenge. Um so I said that

our vision is just to to free uh anyone

to use any technology but it doesn't

mean that all the technologies are the

same and all the technologies has the

same uh challenges. It's obvious that

agents bring new challenges, new

threats. And just to illustrate, this is

an updated list of the OASP uh LFO top

10. Um

so you can see new things that they

didn't exist before. So yeah, obviously

we need to to solve new problems.

Um

so how how we modeled or how we think of

agents in our data. So

we think yeah so far we've seen

interactive agents chat box code editors

but this is unlikely the the future.

we start to see other uh modalities

where the agents doesn't run anymore in

a in interactive way. Um dash runners or

autonomous agents is something that is

very popular these days.

But beyond that

we see a feature where fully autonomous

agents can do things uh either on behalf

of the users or maybe just because

agents will start talk to other agents.

So this is how these are four pillars

that we believe will cover all these new

modalities. The first one is

AI needs to know who I am. So this is

this is key. Uh if the agent doesn't

know who I am, it can never apply any

security or any restriction or any

authoration authentication because

>> I'm just an anonymous

source or actor in this and this is

important. The second is

obviously the agents will be autonomous

enough but it doesn't mean that we'll be

alone. It will be just doing things on

its own. Eventually they will need to

access other services to consume other

resources. So AI needs to call APIs on

on my behalf as a user.

But sooner or later the agent will try

to do something riskier or something

that I don't I don't think as a user the

agent should do on its own uh without

any supervision uh from my side. So AI

can request my confirmation

and lastly um AI access

should be fine grain. So I need to to

give the agent control to access my

resources but not any resource, not any

collection or document or anything. It's

just it has to be on my hands to what

the agent can access and what not.

And just to to also introduce

where octa and alto can play or

complement each other.

So we talked about a user and it could

be me, it could be you but eventually

will be an employee within an enterprise

or a company and in this case the

employee is not only acting on his own

behalf is also representing the company

and in in those cases the company needs

also control what exactly those agents

that are acting on behalf those

employees are doing. So that's where uh

Opta also plays a uh important part and

in the other end Alzero is what we uh

the the capabilities and features that

we've implemented I think is where they

connect. Yeah.

>> Just trying to understand you said the

agents need to know who you are.

>> Yes.

>> Who you are is what as the user and the

coder and the one with the permissions.

uh is the subject of the the the

operation that you're doing. Like it

could be anything. It could be you as an

employee. It could be you as an owner or

something as an administrator or

something. But at the end is a person a

human.

>> Yeah.

>> Yeah.

>> In in the scenario I was talking about.

>> Is is this what

what permission the agent have access to

or who has access to the Asian

capabilities?

I'm not like I don't understand

>> both. Yeah.

>> What does that two here?

>> We're sorry.

>> We are definitely touching on both. So

yes, let's Yes. And time for your

questions at the end. Absolutely. Let's

make sure.

>> Thank you.

>> Thank you.

>> Thank you.

>> All right. So let's get deep on exactly

what we are going to present today. Uh

we talk about four pillars. um not in a

particular order but we are I'm going to

introduce uh one of the three which is

or how we made possible one of the three

which is um AI can request my approval.

Um for that we implemented a sync O as

part of the O for uh AI us offering and

basically [snorts] this feature what it

does is creates a mechanism and and a

protocol for the agent to reach out the

user when an operation needs to be

approved by the human in in in this

flow.

It's seems simple. Um

it it is in in [snorts] essence but well

it's security [laughter]

but uh on it's built on top of uh client

initiated authentication uh sorry client

initiated back channel authentication

protocol. It's an ITC uh specification

and it's yeah so in this scenario is the

agent that it's initiating the

authentication and authorization.

So the agent is running maybe it could

be a long run autonomous thing and at

some point needs to make a purchase or

make something that is flagged as risk.

Uh so with with a sync uh with a simple

SDK call it can initiate um

an authorization request that

materializes a notification to the user.

The user receives the details of that

transaction well structured. The user

acknowledges that, approves that and

then that approval gets back to the to

the agent in form of an access token.

And that access token contains the exact

details that the user approved.

And yeah, I'm going to hand over to

Patrick for this one.

>> Awesome. Yeah, thank you Carlos. And

yeah, good question. Thank you both

questions. the the token vault as the

other kind of like you know major

feature we're introducing with this AI

more AI targeted AIO release um token

vault is a new mechanism for persisting

your upstream uh resource refresh tokens

so I'm sorry refresh tokens and you may

have used oor before right for social

providers um or in tangent with like

other identity providers

Um this makes use cases with agents much

much easier. Um so we we we have a

really fine grained now flow which

allows you to exchange tokens. So on on

behalf of users so I can you know I can

send my access token or my application's

refresh token um whether it's for an API

whether it's for my application um and I

can then request scopes for an upstream

uh you know service. So whether that's

accessing Slack API or Facebook API or

um any any other identity you know uh

scoped API and so yeah and we we

actually persist scopes we manage

lifetimes of tokens um we do a lot of

handling there to ensure that your SDK

life is very easy um and that your agent

stays online and it's it's it's

available and it's secure u um yeah

we've been testing this flow really

extensively. Um, but you can kind of get

a picture of what is going on under the

hood and um, yeah, we'll talk more about

token vault in the in the shop. It'll

make a lot more sense when we get in

there. Um, I do want to kind of

highlight a few flows though. Um, where

you know I mentioned refresh token and

access token. um as we are digesting

each of the agentic frameworks you can

kind of see that well it may differ if

you're using a single page app right and

uh you know you're you don't have a

backend which is as you know uh as

secure you're or you're wanting to

access an external API um in these cases

especially like with langraph uh we we

use an access token it's shortlived

access token um that's simply because

langraph stands up an external API um

there's a langraph protocol around the

langraph CLI. So yeah, in this case like

we kind of model that flow whereas like

other flows you may just have a native

app or a simple Nex.js regular web app

um traditional web app with your agent

running embedded. Um then yeah in this

case like a refresh token may fits your

use case perfectly fine. Um, and then I

think as we're going to talk later,

there's also cases where, you know,

maybe you have an asynchronous agent

accessing other data. Um, we have a new

mechanism now called a custom API

client. Um, which can allow an MCP

server for example to access remote

data. Um, so that's kind of the

conceptually what we've done at Ozero.

We've taken agent, we've kind of modeled

it as a client and we've taken your APIs

and kind of modeled them as traditional

OOTH resource servers or APIs in our

platform. Um, so yeah, that's a little

bit what's going on here. I've kind of

listed some details about token exchange

on the [laughter] slide. Um, yes, that

just know that the subject token type is

kind of type of exchange whether access

or refresh. The subject token is your

your token. um [snorts]

the user token be in exchange for the

third party token. Um

let's see. This is a really quick GIF of

um our interrupt flow with Lingraph. Uh

recently wrote this. Um so it just shows

kind of you know what the what the

mechanism looks like. If the the prompt

says uh you know I need access to my

calendar, we have a a Google social

provider. um we have an interrupt you

know as part of our SDK it will feed you

back the the mention that you need to

request additional scopes we then do the

token exchange from token vault get you

a new access token and then you can up

access your upstream provider um really

quite simple in our in our framework now

um quickly about MCP and then we'll dive

into the workshop um MCP [snorts] is

very new for us we just launched a

preview Um but we've been avidly working

on this for quite some time. Um but

yeah, you can kind of see where we've

modeled the MCP server also as a client.

Um and yes, there are cases where agent

is a client talking to MCP server which

is also a client talking to upstream

APIs. So um and that's that's actually

what I'm going to show today. [laughter]

Um but yes, the the flow is quite

similar and we'll talk more about MCP

semantics and um you know how we've

implemented dynamic client registration

and um kind of what we have here. Uh

these are totally from our teammates. So

[laughter]

just trying to pick our favorite slides.

Um and yeah um as far as the workshop uh

I think we're planning to just kind of

highle high note each section. Um, if

you don't want to work through it,

that's okay. You can follow along. If

you want to work through it and you're

more hands-on, um, that's fine, too. Um,

and yeah, we really truly appreciate all

your feedback. We do have time at the

end for questions and all kinds of

feedback. So, um, we would love that.

And, um, yeah, this is what we are

building, um, today. Um,

basically, we are building an agent

Nex.js app. Um what's nice about Vcel's

platform, right, is we can build MCP

tools alongside our agent in the same

infrastructure quickly. We can then use

the agent client to communicate with the

MCP server and then leverage the MCP

server to talk to third parties. So um

that's really powerful and you know it's

secure and it's easy to build. um you

know we we feel quite good about several

areas of this the security stack there

but yeah I think this is kind of the the

rough idea like a lot of typical flows

you might see um you know in the

industry um yeah so uh I'm going to yeah

so we can pull it up and get going uh so

let's see uh yeah hopefully everybody is

able to capture the link Um

and

>> all right. Uh so yeah.

>> Yeah. Well, while while Patrick is um

showing and kind of doing the workshop,

um I'll be available for anyone has a

question or uh a problem with with the

workshop itself. Just raise your hand. I

will approach you.

>> Awesome. Awesome.

Yeah. and then I'll do like a quick

intro then kind of showcase what it does

and we'll kind of step through this

journey of building that topology. Um

so

yeah uh but welcome is really just

around getting your dependencies and

getting um a a client. Um so I guess the

first step here we we have a a root

tenant an upstream IDP for you. So this

is kind of a little more of an

enterprise use case. So let's say you

have a a core IDP provider um that you

know you you tap into for like upstream

API management or upstream identity. Um

so we have this like fictitious uh stock

trade application uh which looks like

this. Um and this application basically

the idea is is that you know consumers

can come here they can access a stock

API they can establish identity here but

this

this application also exposes a stock an

API for downstream consumers and

downstream agent clients and and

additional consumers. So we have a

basically a link a federated a linked

access uh with our ODC connection um to

this to this tenant. Um so yeah uh so

the first part is really just um getting

your um your client. Um, I already have

a client, but where you would start here

is basically just um going through

Ozer's stack and getting um

uh a tenant and starting to get your

client developer keys. Um

so we'll add O as the as a subsequent

step, but I'll show the like the first

step where we just have a really simple

agent and then we're we're adding on um

identity and then authorization.

Uh

so so yeah these are some prerequisites

node PNP

standard toys um OS CLI so we use a CLI

for a lot of CLI management of our stack

it makes some things easier we use a

combination of Terraform and CLIs um in

this demo um

um [sighs and gasps] yeah so that's kind

of the conceptual overview and some of

the like major dependencies Um, after

you've created your your client and kind

of signed up here, um, we've got a link

to it here. Um, you should be ready to

go for spinning up your tenant. Um, but

yeah, I'll talk more about that in step

two. Um, so yeah, let's start with the

very beginnings here. Um, so we're in

this step, we're just we're we're

building our downstream chatbot. Um,

this is a downstream application that

we're just spinning up. hasn't connected

to anything yet and we're adding we're

adding on this upstream provider and

adding on access um with agents and with

tools. Um

and so yeah uh I used OpenAI with my

agent but yeah you'll need uh an open

API access key. Um this is the repo

which has the base um the base template.

I'll give you a branch at the end which

has all of the changes we make in this

workshop. Um

and

um yeah, so let's take a look at what

that looks like. Go for

agent.

Okay.

Oops. [snorts]

Okay.

Go for it.

One, two.

>> Sure.

>> So, well, yes, standard uh chat box. Um

so at this point when when when you

start if you try to do anything other

than just regular gen AI questions you

will get just the model nothing else but

um the important part is if we try to to

ask the model who who I am

>> that's when the model then says okay I

don't know who you are I don't know what

they is so I don't I know nothing.

The same for in this case this is a

downstream of a trade uh app. If you try

to consume data from that trading

service like again the chatbot will tell

you I know nothing. Uh so let's let's

fix that. uh let's give uh the chat box

awareness uh first of the service uh and

tools and then also [clears throat]

>> authentication. So let's let's

authenticate and let the the agent know

who who I am.

>> Okay.

>> Uh

>> so that's okay. Yeah, keep going. I'm

going to apply this.

>> So well

I will try to sing with Patrick here.

>> Yeah. [laughter]

>> Um yeah, this is pretty standard. I

think you saw this in several workshops

already just today and imagine several

times in the last weeks but yeah we are

uh in the basel uh AI SDKs we will

introduce the uh get stock price tool

>> um and later the uh authentication part.

So, let's go for the simple thing. Um,

in this case, Patrick is cheating

because he has all everything stashed.

>> Won't be that easy for you guys, but

>> um

>> rest assured that uh let's run it again.

Um I

>> was going to say rest assured all of the

code that's here is is in this stash.

So, you don't have to worry about that.

So, um, let's go back to the chat box

and let's ask again about prices.

>> You guys want us to try to follow along?

You're going to do an overview.

>> Okay.

>> Like, am I supposed to try to keep up

with what you're doing?

>> Yeah, that's hard, right?

>> Yeah. [laughter]

>> Let's let's let's complete everything,

right? Yeah. Okay. Yeah. Good. Good

call.

>> You can tell it's the first time we run

inspection. [laughter]

Great.

>> Pretty awesome.

>> All right. So, let let's let's let's

make an actual or let's start uh with a

um trading questions or at least get

info questions about it. Okay, cool. So,

now we've got the chat box

um connected to the upstream API.

>> Yeah, exactly. Uh in this case it's a

public service. It's a public endpoint.

So no authentication association was

required

>> right

>> let's try so let's move along.

>> Um

>> there are more

info in that page but

>> sorry.

>> Yeah no no no it's okay. I was going to

say that let's go back to the kind of

important stuff.

>> Okay.

>> Um

all right.

What happens if we want to read not

public uh data from [snorts] the

upstream service but personalized data

so data that I as a resource owner own

in this case is we are going to use uh

token board so basically when when we

logged in can you go back uh the chat

box

>> yeah yeah yeah

>> so so far we didn't go through any login

process so there is no who I am or

anything like so it's just um anonymous

uh session so far but at some point we

will log in we will log in in the uh

Asian IDE

>> right and but that will give us a

relation a trust relationship between us

and the Asian alone

we need to go beyond that we need to

establish a relationship also it's kind

of a a three-way thing it's us is the

upstream service and the agent so we

need to establish this triangle

relationship, right? And we do that we

will do that through token bot. We will

uh first authenticate the agent that in

exchange well issue an ID token and an

access token u an access token that

basically authorize us to use the agent

alone. But we can with token bowl we can

use uh once we establish the third

relationship we can use that access

token to exchange to exchange it by an

upstream access token. Yeah. And that's

what token does. What it does is once we

connect our upstream app, in this case

the demo trade app,

Alzero will start storing the refresh

token

and dealing with the issuance that of

the access tokens. So we store the

refresh token, we store the the access

token for as long as it it until it

expires. And every time the agent needs

to access this data, it runs the refresh

token uh grant to obtain a new access

token and that is issued back to the

agent. So

>> can you Yeah, that's that's more or less

the the graph. Can I yeah jump to uh

>> so yes um you know it's also going to

show just adding the basic off for your

user and and built and then adding on

these these token vault requests. Um the

so SDK code here kind of walks you

through like the sign up the terraform

all of the tenant setup um so that you

can start to use these services, right?

so that you can access token mold so you

can start using identity with providers.

Um this is a very new feature set with

some of these features. So you'll you'll

notice like in some of our configuration

you're enabling a connected accounts

feature with our new my account API. Um

you're you know setting up grant types

for your client application, your agent

[snorts] application. Um, and you're

configuring your OIDC connection. Um,

um, so yeah. Um, [sighs]

I don't know if we want to. Let's keep

moving and then we can kind of show the

tenant. Um,

>> um, but these are kind of the steps, um,

we can apply to just add a basic

identity. And yeah, I'll turn to you

while I'm doing that.

>> Yeah, TDR, all the steps are there. uh

references, links, and everything you

need in case you want this to want to do

this later or at home.

>> Uh all right. [clears throat] So,

>> let's try. So, the

>> So, at this point, what we're going to

do is bring the login button to the

agent basically.

>> Um

>> just kind of show what that looks like.

>> Yeah.

>> So, uh route.

>> Yeah. So,

>> so we use ALJ SDK for Nex that provides

a middleware

>> um

>> not the right one. One second

>> and a wrapper uh for our routes.

>> You will see.

>> Sorry. One second.

>> Yeah,

>> I think it's that. Oh, it's complaining.

Sorry. Conflicts.

There we go. Okay, there we go.

>> Yeah, a huge change. It's intimidating

but it's because um it's dealing with

the connected account. I think uh we are

in the process of simplifying that in

the SDK

>> way more.

>> Uh but yeah uh

>> what is this?

>> Uh so this is the next uh route for the

chat.

>> Yeah. So we've taken the page uh that

yeah has the the chat um client. Uh so

it's yeah it's just your your standard

NexJS page and um yeah this is our

wrapper [snorts]

um which then basically forces login um

or gives you a redirect.

>> Um yeah

>> let's step back a

>> yes

>> and I'm going to add authentication to

this agent.

>> Yes.

>> Okay. Where does this fit in?

>> This is an embedded agent within the

next app. So yes, this chatbot is an

embedded agent. Um we'll show other

>> I'll tell you what I'm agent do is

>> I have a existing deployment what

additional components you're sharing

with me right now. What's my existing

deployment?

>> Yeah.

>> And what's out of the box?

>> Yeah. So it's really these wrappers u

from the SDK which wrap an endpoint um

you know whether it's a page route or um

something else. Um so yeah and then this

is pretty standard with like our next.js

JS SDK now um we established a session

um so yeah I'll show login but that's

there's there's really not a lot of

magic here um we are however requesting

this new connected accounts to see if

you have a federated connection so

that's kind of the confusing part here

because like you know the old school

zero flows would not have that like you

know we we wouldn't be requesting

upstream providers in many cases or

other APIs Um but in this case yes we

are using a federated provider and um so

yeah it's it's a little more contrived I

guess um and yeah we're creating a

client there you can kind of see the

OIDC options we're providing which are

you know are specific for OIDC and then

um this connect account endpoint um is

is new that's going to enable our new

connected accounts API um for managing

all of your accounts Um

I think that's Yeah. So let me show that

and kind of Yeah, go for it.

>> Yeah.

>> Okay.

Um

>> so that was code. Um

I think

>> let me restart.

>> All right. Okay. Let's try it again.

>> Yeah. Run it.

>> No, it didn't.

>> It's it's it's there.

>> Awesome.

>> So I'm gonna sign out and sign in.

>> Yeah. So we sign out. Um so at this

point is up to you want to place a login

button or whatever login UX is suits

best with with you in this case just to

simplify if you try to access the URL it

will just prompt you with the login

screen right away.

>> Um so we log in now um at this point we

are

>> well we it doesn't show but we are

logging to the upstream ID. Yes. So

using just one credentials

and then [sighs and gasps]

uh well at least uh now

>> uh it knows that I've got a session uh

>> and who I am.

>> Let's see.

>> Yeah.

>> Awesome. So it got the profile from the

IDP. It load that to the context. Yeah.

So now it knows who we are.

>> Yeah. And in this fictitious application

like this is also the same identity

that's uh I'm sorry that's linked with

the the stock trader uh sorry

yeah this dashboard. So so yeah your

identities are now linked between you

know these applications you're using an

upstream provider and you'll also see

shortly that they'll be linked with your

MCP tools as well. So, okay.

So, we've got identity for we've got

login. Um, we've got an embedded agent

running locally. Um,

um, what else do we want to talk about

in this step? Are we ready to go on?

>> Okay. So, it knows who I am, but it

doesn't know what I own. What What is

that? It doesn't have access to the

trading service resources that I own in.

So if you go back to the

>> uh demonstrated app one sec.

>> Uh yeah this one.

>> Yes. So my balance is 10k.

I've got these recent orders.

>> Yeah.

>> Uh so on so forth. So how can we give

the agent access to all this data?

>> Yeah. So all right.

>> So the first step is as we said earlier

>> we need to connect

the two accounts. So even if we are

using the same credentials, we still

didn't say explicitly or the a user

didn't set the explicitly to the agent,

hey I I know I I want you to know who I

am, but I didn't give you permissions to

access my account yet. So that's the

step you are doing. We are connected the

account. So that's when we prompt the

user with these extra permissions that

the agent needs, these extra scopes,

right? And that's when the relationships

is established. Uh so now the agent

knows that uh I have access to this

account

>> with that exact permissions. Nothing

more, nothing else.

>> Yeah. Yep.

And

>> yeah.

>> Yeah. So next I think it's just adding

some tools which can now leverage this

account. Um so I'm going to jump into

portfolio tools.

Um, and this is getting into that token

exchange and um, yeah, now we can start

to ask more pertinent queries, right? We

can say, can you view my portfolio? Um,

and uh, yeah, we're not going to give

you access yet to create orders. That'll

be uh, the next pieces. Um but yes uh

this kind of shows how our SDK kind of

models getting an access token for

another [snorts] connection upstream. Um

how to how to leverage shared tools and

TypeScript. Um I think what's really

nice here is that these tools can be

versatile. They can be shared between

whether it's an agent tool or an MCP

tool. Um hopefully your framework has

you know TypeScript support. Um that's

also a really nice uh capability

tool organization. Um so yeah let yeah

if you want to keep going I'm going to

add the the tools.

>> Awesome. So the same as the same the

first step we did we are going to load a

uh well to give the agent a new tool. So

far local tools we will get to we will

get to into the MCP part later but uh it

is a native tool that it does a simple

>> um HTTP request to the service but uh

the tool

will have a

>> so we can show yeah sorry

>> so one of the other things that we

provide in our SDKs is how we connect

this tool uh with the authentication

part and the authentication part.

>> Yeah. [snorts]

>> Use the the tools basically again.

>> Yeah.

>> So

>> So can you show

>> the code tool?

>> Yeah. Yeah.

>> No, the tool again the code tool.

>> Uh you show the

>> this one tools or

>> the the get portfolio tool.

>> Oh yeah. Go in

uh Yeah.

Sorry.

Yeah.

>> So at some point we have we create uh

with with a client and

in the handler.

>> Yeah.

>> What is that call?

>> So yeah it's just a a get with a include

history you know query pram option

optional uh addition there. um pretty

straightforward

API call once you have a client and a

token. Um but yeah, this the sweet sauce

is the you know we can now leverage this

get access token for connection really

easily on our SDK. Um so yeah let me

show that if you want to

>> yeah it's everything is summarized on

this slide that's what I wanted to show.

Uh so our SDK provides this you provide

the connection in this case that's the

upstream name that is represented in in

your tenant

uh and that's what does all the dance

with the top

>> there I'll say can you show my portfolio

sorry

>> so yeah um all right

>> so we've got an agent with access to our

data now so he knows who I am but also

has access to what I am

has digital access. Well, it's up to you

obviously that the tool implemented but

at least yeah I already know exactly

what we have.

>> Okay.

>> Okay.

>> So, so we have portfolio tools uh which

is great. Um

I didn't show the scopes but [laughter]

uh yeah rest assured that like I must

show the MCP server really quickly. So

kind of what we've scaffolded and

modeled. Um and this may help with some

of the questions but the um yeah here's

the MCP server which we've we've modeled

as an API. Um and we have you know

scopes around accessing the MCP server.

um we've kind of modeled those the same

way as our as our upstream um API. So

let's see permissions. Um we've got

scopes around reading trades, reading

our portfolio. Um and yeah, those are

referenced in in those tools in the

meta. Um that wasn't abundantly clear,

but um yes, we are representing those as

like scoped permissions. Um

>> how do you create these permissions?

Yes.

>> The keyword trade and portfolio these

are very application specific.

>> Yes.

>> Yes.

>> Yes.

>> So how would it know what they are mean

in the context of the application?

>> You want to take that one?

>> What do you mean?

>> So this app is a stock trading app. So

the word trade and portfolio will have

very specific meaning here.

>> Yes. Yes.

>> But I could have another app where the

word trade or the word portfolio maybe

it's like a project management app.

Portfolio would mean something else.

>> Yeah. But

>> so so how does it identify

[snorts] the meaning of the permission?

>> That's taking it.

>> Yeah, I can. So uh yes,

>> I think I understand but at the end of

the day is the upstream service that

sets the rules, right? [clears throat]

So [snorts] if you want to access my my

my resources, I need an access token

with this scope. Otherwise, I would

reject your request.

>> And it doesn't it doesn't matter if

you're an agent or even a just

traditional REST API client. And that

rel that you as an implementer of the

agent, you know that in advance. You

know if you are connected to an

upstream, you know what's the shape of

the request and what's the authorization

layer that I need to implement. You can

model your scopes as you want in your

local tenant but at the end of the day

the translation the scopes to the

upstream should be done. So you can you

can tell

>> where do I do that?

>> It's in the connection.

>> Yeah. When you define the connection.

>> Yeah.

Yeah. So the the enterprise connection

here to our upstream is here. And yeah,

you can kind of see we're requesting

those scopes from the upstream tenant

and it also in this case like has those

scopes modeled around the stock API. So

>> exactly.

>> Yeah.

>> So these scopes I'm getting from that

from the from the service.

>> Yes. So this comes out most likely

publicly available or it's something

that is part of the contract between you

and the upstream

>> and that's exactly what the user will

see on on the prom that you saw at the

moment that they connect the account.

>> Exactly.

>> So we are here for to simplify we use

the same names but it could be different

it could be different scopes have it's

the translation happens on top of both.

>> Yeah. Yeah. And um yeah, I should also

worth mentioning like we model roles

differently, right? like around you know

personas or other identities scopes are

really around API access right so if

you're looking to kind of model more

around a role um yeah definitely check

out FDA um we have role based access

controls which you can apply around

tools as well or around pages but this

is more just you know fine grained uh

access around an API um so all right

let's keep going

>> and this is new

>> yes Yeah, a lot of this is very new.

>> Connections has been around for forever,

but the purpose and actually that's the

name we chose. Uh the purpose of a

connection

>> uh we create a new one which is talking

mode.

>> All right, we're still doing pretty good

on time, but yeah, it's okay. Ready to

jump in MCP. So

>> yes, um any questions so far? Kind of

switching topics here. I I wanted to ask

similar to your question

>> the scopes will be available you get

them from the well-known oids like a

hard

common way to get these right and you

can publicly fetch them and then

>> yes

>> yes yes

>> yes exactly um so yeah that's you've

jumped right into the next flow and

>> uh yeah so we are trying to implement

the current spec with MCP now and that's

kind of the next part of this exercise

is adding the well-known protected

resource metadata endpoint. Um and um

yeah, so we've been testing this with a

lot of providers uh recently and

recently we just EA our DCR uh feature

like this week. So um but yeah, that

this flow is a little more involved,

right? Because the the MCP server

becomes um you know a client of the

agent. Um and we're kind of we're going

to show kind of how we modeled that in

the Verscell code. Um [clears throat]

um and you can see like you know all of

the steps there's you know obviously

more involved but it's you know it's

important because we're actually

securing MCP resources and tools and

kind of doing it in a granular way but

also enabling dynamic registration

um with many providers. Um so yeah we'll

showcase that towards the end here. Um

yeah, I can probably fire this up if you

want. Um kind of see if there's So this

kind of show maybe I'll talk through a

little bit of this. This kind of shows

some of the middleware

um and how we apply like scope

verification on the MCP server itself

and how we expose metadata. So yeah,

that's exactly what you're alluding to

is like we we advertise the supported

scopes um when you go to register um in

that part of the flow and then

um yeah further down I think it's in the

transport when we actually construct

uh so yeah this is just more helpers so

it's like you know creating middleware

to verify a JWT we're still you know

still a beer token um public private key

encryption. Um but yeah, we we reference

those libraries. We have a lot of shared

libraries for doing these things now. Um

and then um yeah, it another important

mention here is this is where we

introduced this custom API client. Um

maybe I can show so this is a separate

client that we've modeled in this uh

demonstration. You could really create

any number of API clients if you want to

model them, you know, more independently

or how you want to build your stack.

But, um, yeah, we've modeled this as a a

linked client, which is also a new

feature, not zero. Um, so now we can

actually link APIs to clients and model

them as basically you can think of them

as, you know, an agent client or an MCP

server client. So, um, so that's a

really nice new feature. um those are

now linked and um we have API support

for those as well. Um so yeah you can

see like constructing an API client with

the MCP server client ID and secret. Um

and

yeah I'll run that in just a second. I

want to see if this so this is again

like monitoring these shared tools. So

we've we've taken this like stock tool

portfolio tool from the agent over to

the MCP server now. So we can expose it

from there as well. Um and then you know

the registration of the tools.

Um and then yeah this is where we create

the transport right. So this is where we

create this MCP's endpoint and

construct the server and um yeah that

that's where we invoke our middleware

and so yeah let me show that and um yeah

if you want to add anything else feel

free

>> yeah so in in this case to an attempt to

to show the whole journey we decided to

create the NCP as part of this workshop

>> but it could also be that you

>> get your upstream NCP not that you are

building an NCP but you still need to

authorize to that right so in in in both

cases association works

>> so it's not that we wanted to show both

ends uh so that's why there's so many so

so much code in in that page it's just

because uh part of it is is the actual

MCP server

>> so I've unstashed all the changes in

this that I just showed and Um yes like

this is basically uh what's going to

give us the MCP tools. Um so um yeah I

will start this. [snorts]

All right. Um

so yeah we made the changes to the

client. So in this case in this the same

nextGS server that the agent is running

is where the MCP is served. But it's up

to you which as your architecture but

same same concept apply.

>> Yeah. So I'm gonna say

>> yes go. Yeah.

>> So if you go back to the chat UI, can

you can [clears throat] you do a prompt

injection to tell that now my connection

have a different scope and

>> so you can try that but it will take a

no effect because the fact that you are

asking scopes that are not part of the

connection would be either ignored or

rejected.

>> So so basically just ignore that. Yeah,

it depends on the the upstream, but

yeah.

>> Yeah.

>> So, the scopes that are not part,

correct me if I'm wrong, Patrick, but

scopes that are not part of the

connection can never

>> end up in the access token.

>> That's correct. That's right.

>> Right. So, I think our policy most of

the times is just ignore what we don't

recognize.

>> So, you just you will get an access

token with valid scopes, but not the one

you try to inject.

Okay.

>> And also I don't think now that you

mentioned I don't think we expose

the out part to the LM meaning we expose

the tool and we grab the tool but the

authorization happened before the tool

execution.

So I don't think the LM will have any

influence in what exactly. But I'm not

saying it's not possible because there

[laughter] are many ways to do many

things.

But either way, even in our end,

>> anything that we don't recognize

shouldn't end up in an access token.

>> Because you mean that the OP will

actually recognize what connections you

have before it pass your instruction

over to LM to execute. Is that right?

>> Yes. So you when you go Jio try to

execute the tool. So the tool will say

okay I need an access token because I

need to do an API call. So it's our

grapper or our SDK tools that provide

this access token to the tool. It's not

the tool on command to the end the to

from the LLM that runs the authorization

request. It's it's let me say it's just

oldfashioned

code. It's not LLM code.

>> Okay. So uh now I'm going to show kind

of step for step the DCR. Um so yeah

it's our I'm using MCP inspector and

common tool. Um and we'll show some

others but um yeah this will kind of

just show now we can actually target

that MCP server directly you know

running on the same server under /mcp

now. Um so yeah and this will show our o

flow and DCR happening. So I'm going to

hit continue.

disclaimer, open DCR is a thing. Yeah.

>> But in as in early access and I don't

think we will

>> Yeah.

>> There are some concerns about how this

will scale.

>> Yes.

>> Um but there are other aspects coming uh

that I think fit better in

>> in this scenario.

>> Absolutely. I agree.

Uh but yeah, you can see the protected

resource metadata coming back. So we

have the well-known endpoint. Um you can

see the scope supported and then we make

a request to the authorization server.

Um that returns more information about

our tenant. Um and you know additional

scopes how to authorize. Um so yeah, I'm

going to jump through that. And then we

get a registration call. Um, so now

we're going to get a new client just for

testing purposes with the MCP server.

Um, so yeah, now we're going to get um

believe this is PKCE. It's our

authorization code flow with proof key

code exchange. Um, so yeah, it's

standard on zero flow, but it's also

works well with with MCP. Um, so I'm

going to copy this.

Uh,

okay. So, yeah, now it's going to prompt

me and give me an authorization code.

And at the end of the line here, we

should get an access token. So, which is

great. So now we can access the MCP

server with these scopes from from

anywhere, right? That's the great thing.

So uh so now I'm going to hit connect

and let's see if we can get some tools.

Uh yeah. So

yes, so now we have access to our

portfolio and um you know our our

identity tools kind of accessing um the

same upstream stock API. Um, so yeah.

Um,

you want to add anything here, Carlos,

before we go further? Oh, any question?

Yeah.

>> Sorry, I'll ask at the end. Yeah.

>> Sure. All right.

Okay. So, um, yeah, this is really the

most involved part of this flow. Um I'm

going to show the claude. Uh so I've

actually deployed it if you want to play

around.

Uh

and um yeah, so um that's that's really

the most involved part with MCPA rather.

Um um yeah, I think we're hitting time.

So let's go into the async goth. That's

all right.

>> All right. Okay.

Um

>> go for it.

Do you mind still um driving the the

coding so I can

>> All right. So we said that earlier the

fact that the agent has access to our

resources it doesn't mean that you

should do anything in any time without

my supervision. Right?

I said this all the time. We don't want

an hallucinating agent buying a stock in

the middle of the night without my

permission.

>> What's wrong with that? [laughter]

>> Yeah. So that's where

part of our uh the bundle is provide a

simple way and a seamless way to the

agent to reach out the user and get

their approval for risky operation.

In this case, we consider place an order

either buy or sell a risky operation.

It's something that we as a developers

of the agent define. It's up to us. Um

so in this case what we are going to do

is we are we will bring um the create

order tool but with some conditions.

>> Yes. So D conditions would be that

before running the create order tool we

will call uh back channel O that's the

the SDK name for for the O uh sync

>> we will obtain an access token that

contains exactly what the user is so let

me let me go step uh backward so we will

create this request to back channel with

the detail with the details of the

transaction in this case it will be

exactly

the symbol I'm I'm buying or selling

quantity and the price for the user to

see that in their screen most likely out

of plan device see that and approve that

and only when that is approved we will

place the order.

>> Yeah.

Yeah. for that in this in this case in

this sample we will use guardian is our

uh mfa uh application is is out of the

box application you can use you can

install and use um but also we support

guardian SDK in case you want to

implement your own

>> um

>> I'll show the user

>> yeah so

to

for the agent to be able to reach out

the user in for this channel in

particular, the user needs to be

enrolled on MFA.

>> There are several mechanisms to do that

uh just for for for the workshop. We

show you kind of the back door of it,

>> but it depends on the UIX how you it

could be in sign up. It could be like a

step up kind of thing. I don't know.

It's up to uh to you. But we need to to

enroll. So you will find this is in the

docs but you will find a way to send an

email that contains all the instructions

to enroll.

>> So once we enroll we will we can we can

add this uh little helper here

>> uh that just basically forwards the uh

off to the to our SDK.

>> All right, let me undo and reapply here.

>> Yeah. Am I going faster than you?

>> No, it's Yeah, it's [laughter] perfect.

Sorry.

>> Catching up.

>> All right. Um

>> uh one sec.

>> Okay. So in a second I will show you

exactly what we are going to send in

this authorization.

>> Um

>> so we can see

>> so I think it was in a zero we add the

>> yeah so here is the uh this

>> is the helper. It's just a wrapper just

for wrap the errors and I'll test it.

But basically it's again this this line

of code in our SDK is what we sent and

what will run all these steps

>> internally.

>> Show the tool.

>> It will keep um it will wait for the

user response. So it's basically an an

sync uh operation and when the user

responds the agent can resume. Oh,

sorry. It's in uh it's in tools. This

one.

>> Uh yeah, this one.

>> So, yeah. So, here [clears throat] we

>> we're creating a new client with uh you

know, so we're specifying like what we

need in the authorization details. So,

we can provide that rich authorization

request detail when the authorization

request comes in. um we're you know

we're using this custom API client in

this case that we've already created you

could create others but yes we're

creating a custom API client to then

perform the back channel request um and

then uh yeah it in this case it waits

you could do a number of things you

could pull you could

there's other mechanisms here but yes in

this case for simplicity sake we wait

for the verification so let me give this

a

All right.

>> Yeah. [snorts]

So,

>> okay. So, we run the client again. Uh,

sorry, the chat box agent.

>> So, we'll go back to here.

>> All right.

>> And

so, now we can ask to

>> I don't know place an order

>> of what is it? Wayne.

>> Wayne. Yeah. For example,

>> fictitious stocks.

>> Yeah. So in this case,

>> yeah, go ahead.

>> I have this question about the code. I

don't know if all this code is checked

in.

>> I'm not sure. Do you have branches?

>> Uh yes. Yes. Yes. Uh yes, I'm happy to

share that towards uh towards the Do you

want me to share it now or

>> later? I just follow Yes, we do have a

final state branch. Yes.

>> Um in this case, the agent is instructed

to inform the user that this is going to

happen. So this is not yet the

authorization request. is just heads up

that hey you're going to receive a push

notification

is is okay it's just a really silly

system

um so you can proceed then

>> yeah waiting hang on

>> um

one minute here should be connected

let's see

>> one a minute

>> you run this like [laughter]

Uh,

turn that off. Oh, because you're hot.

>> And [sighs]

let's see.

Let me try again. Let's see.

>> Yeah. Refresh and try again.

>> Refresh.

[clears throat]

>> Apart from push notifications, we also

support email as a random note. Um, and

more channels. We we will be

implementing more channels to reach out

there.

Yeah, maybe I need to restart the

application server

is if I have

>> can I just pre-authorize certain users

>> in in your engine like

>> yeah I I mean I guess it's up to you how

you manage this session with your agent

this

>> no yeah I want to make sure no one else

can engage like

>> with the same agent You mean?

>> Yeah. Or like can I can I get can I can

I be able to pre-authorize the agent for

certain access but also for preauthorize

who can use the agent for access.

>> Just trying to understand what are the

different use cases around that.

>> Um yeah but this is kind of up to you

how you kind of the how you manage your

sessions and permissions to access the

app as a resource.

>> Okay. Uh but once you establish that

it's just you can you can establish any

policy that you want at the end. I don't

I don't know if I'm following the we can

we can chat later but

>> I approved it. So yeah I had to

reconnect here on this network. So

>> okay

>> uh let me try one more time.

>> It did come in

>> in this example for this agent. It's

saying okay basically the we the agent

is asking if if it's allowed to go to

that website. So I just want to make

sure that the the agent is filled with

that website but no other websites.

That's what I meant about pre

authentication authorization. But when

you say website, you say the the service

>> or certain APIs or certain tools

just trying to see what if anything can

be done as it because right now the

application is happening as interactive.

>> Yes.

>> So I'm just saying can it be enough?

>> Okay. I see. Yeah.

>> Yeah. So

>> this is how I I see I not access person.

>> No no I understand I understand now. I

understand now. So yeah, I I had similar

concerns. I'm I'm not in product, sorry.

But um yeah, so imagine that your

interface is not a chat box.

>> It's like a task runner kind of thing.

>> Exactly.

>> So I guess in what I would implement as

an engineer is I would attach my

identity or at least an identifier of

the user, the subject to that task in my

database. So I I enter the agent, I set

up a task and I say, "Okay, I want to I

don't know, find me a good deal or or

advise me or buy Wayne stocks when it's

below 70."

>> It could be a task, right? I think that

task is modeled in your system, right?

It has to be modeled somehow. I don't

know if it's prompt and ID of the user

and that thing that's when you establish

that. And we use the user that is the

subject is what we use to identify if

the user has a connection to that

account

you know so I need this account this

user to have this connected this

>> I understand

>> and then I will only create a sensitive

identity for the agent because I want to

differentiate if the connection is

coming from an agent or coming from the

user

>> but that's that's the thing you are in

in our uh because the event is an agent

performing the the the request to the

service

>> behalf

>> is in my behalf. what I need

>> but I want to know but but I want to

differentiate though

>> because if an agent goes wrong I want to

know the agent goes wrong right so I

want to know

>> yeah you can you can

>> yes so in that case because the agent is

the client your access token will have

an author authorizing party that's a

claim identify not not the user but who

is

who the user is delegating the access to

>> and that's where you can say okay This

is my ID as an agent. This is my

subject. So I can know exactly okay this

agent is acting on behalf of this user

and you can ruin any policy on that that

you need.

>> Yeah.

>> That's all that's nothing new. It's been

it's been around forever.

>> No, but now I understand. I understand.

Yes.

So um yeah I wanted to show kind of logs

and also just uh we did show the

exchange in the last example for

accessing the portfolio but this is the

actual async siba exchange uh which is

slightly different in our logs but I

think it also kind of ties it together

really well. Um and it shows you know

I'm going to show like what an actual

token payloaded looks like. again

fictitious and these tokens are

>> not going to give you much. [laughter]

>> So this is the details I was talking

about. Um we use an extension of it's

reach authorization request is a it's in

a specification and basically we can

describe exactly what the user is giving

consent to.

>> Yeah. uh and that gets recorded in the

accessory.

In a real scenario, most likely the

resource server will want to verify

that.

>> Uh but yeah, that that's up to the the

stack that out of our but yeah,

>> I'll show the uh notification to so

yeah, it looks like so yeah, that's what

it looked like on my phone actually when

I actually connected it to the network

and I got a slew of notifications.

One of the challenges with uh rich

associations request is that the object

is reported. You can put anything you

want. Um and that complicates thing in

terms of rendering that request. To

solve that, we created an schema. Uh so

we we support an on schema. is flexible

enough to give you any opportunity to

display anything but is known and we can

it helps for our [snorts] app in our

case but also in your apps if you are

developing yours to to render this

dynamically. So our garden app is able

to render any details um and yeah we

provide this schema for you. All right,

>> cool. We're good.

>> All right.

>> Awesome. So, that's a little bit about

our new asynchronous authorization

features. Um,

last piece and then kind of open up more

for discussion and yeah, I know we'll

have a little bit of time, but um I just

want to quickly show and kind of preface

with like some of the integrations which

we are testing. This is very beta and

shipped very recently. But um yeah, this

is using that DCR flow. Um I'm kind of

showing how again how we did it with um

with the inspector, but also with cloud

code or with uh the chat uh I'm sorry,

the open API app SDK. Um so this just

kind of I'm not going to do this now.

We're short on time, but obviously like

we can you know we can deploy this to

Burcell. Um I'm using an upstach

database uh varus database for handling

the state um on on the MCP server side.

Um

and yeah you you can get running pretty

quickly on on versell. So you can you

know you can take this agent and this

MCP server and start sharing you know

these tools. Uh bring your tools right

anywhere. So um

um yeah. So, I'm going to show um I

guess just I've got a deployment that I

mentioned earlier. I'll target that and

uh I'll I'll DCR with my deployment.

Ironically, it's also linked to the same

identity provider. So, I'll get back my

same information. Um which is nice. Uh

and then um I'll show kind of how um in

cloud code this works. Um I'm going to

skip over chat uh GPT app SDK. There is

there is an integration that is starting

to work here.

Um there's some configurations needed.

So reach out and let's talk uh if you

need this today. Um but yeah, it'll be

pretty much readily available in you

know the very near future. So we we do

have some integrations today um that

we've we've tested. Um but yes, there's

this kind of gives you a rough overview

of like how you could quickly bring

those tools to J GPT. Um um

so yeah, I'm gonna gloss through that.

This is just me showing like oh yes,

I've connected it in GPT and I can

access my tools there. Um

um yeah, let me go ahead and while if

you want to talk a little bit more of

that, I will show kind of uh getting a

new a new client with the with my

deployed instance and then integrating

it in cloud code. [snorts]

So yeah, just this is just to showcase

that the the client the MCP client

should also run the same policies all

policies that so all clients should run

the same uh so should identify

authenticate me and author and the

authorization the same authorization

policy should happen. So in this case um

we embedded the MCP as part of the

server but um

well in this case Patrick deployed that

for us. [laughter]

>> Uh so yeah

>> disconnect

>> same same thing we did before

um

in this case this is an production

issue.

>> Yeah same [snorts]

>> as you can see it's asking for my

authentication.

>> Okay. and it got an access token with

the scopes that we requested.

>> All right. So now we're going to pull up

claude

>> and uh

>> and yeah, we can just jump into

uh cloud cut uh give it the MCP.

>> So yep,

I got a command in the read me here

that's in the final.

>> All right.

>> So uh and then yeah, I need to replace

the token. I'll save. So in this case, I

am going to use my inspectors token and

claude does support authentication.

However, there is an open issue right

now about specifying scopes. [laughter]

Uh so yeah, I'm just going to use my

inspector's access token. Um but yeah,

you'll see you'll see that with Claude

and then Claude will still initiate. Let

me show that. Unfortunately, the spec is

pretty new

>> and not all the clients implemented the

same way. Um,

>> yeah.

>> So, yeah, that's um I expect that to

stabilize advantages.

>> There's no like copy in this tool, is

there?

>> No. Okay.

Okay.

Once again, my my token is not going to

do you much. These are fictitious uh

trains.

>> All right.

>> Okay.

>> So, yeah, same same thing as before. We

can start asking about

>> what we got in the in the app service.

>> Uh what happened?

>> It's connected.

>> Is it connected? Okay. Oh, okay. So, let

me res sometimes I have to restart it. I

don't know why. Okay. Now, let's see.

No. Huh.

Yeah. Let me try once more here.

That did not work. I'm sure. Yeah, I'm

not seeing it.

Okay.

Clawed ad.

Yeah, it looked like it was there.

Let's see.

[snorts]

In the meantime, more questions.

>> Yeah, [snorts] you had a question

before.

>> Uh, yeah, I I think I get the perview

when you're a zero customer. Maybe the

context here if you're building an app

for let's say your consumers or

something, then maybe this whole flow

will be applicable.

I'm thinking but if you are an octa uh

tenant you're using octa in your

workspace how do the two work together

or do is this thing also going to be

available on the opta side

>> no I think the idea that got me I'm

going to I don't know exactly so 100%

but what I think it is is we are going

to create some sort of bridge um that

you can apply the the the same policies

as octa as an employee to agents

>> and restrict those accesses to those

services as you would do with that

employee that's where I is that your

question more or less

>> kind of yeah

>> but also how how the two systems are

going to work together because

>> this seems like a feature of zero which

is my understand

>> yeah it is it is a separate part but um

as far as I know

work together on on protests.

Um, but yeah, we can we can connect

later if you want. I can dig into dogs.

Yeah, most likely us.

Yeah. Not sure what I'm doing wrong

here. Uh, do you need to do the

>> uh let's see

>> this this cloud command you don't you

have to run it outside cloud session

>> maybe

>> in the terminal.

>> Oh, in the terminal. Okay. Yeah, let's

try that.

>> Anything else?

>> Yeah. Uh so it seems like if I were

deploying an agent, one way I can start

is just to use the user's token on

behalf of who the agent is acting as the

token for the agent themselves. So what

do you feel like is the advantage of

existing agent identity? What are the

the features that have?

>> So when you say I can just pass so you

authenticate the user and just forward

the access token to the agent somehow or

>> that's that don't do that please. So the

access tokens are meant to first it will

be in terms of operability it will be

cumbersome because access tokens will

expire eventually. So at some point you

will need to reach out the user again

okay login and do all the dance again.

So how autonomous your agent will be in

that scenario.

Um so that's kind of what we try to

solve. So we establish that connection,

that relationship and we take care of

this nasty complex part of refreshing

tokens, storing tokens

um and and yeah all the scope step up

things like that.

>> Okay, so finally got it working here.

[laughter]

>> Some of the interactions I might make

with the agent are through say the the

chat assistant and so whenever the agent

is taking action, I'm

initiating an action, right? Or Not

necessarily as as for example the

example we were talking about before.

Imagine like a taskr runner kind of

thing. You log in, you have the

identity, you have a like a kind of

traditional dashboard where you list

your connectable apps, Slack, Gmail, uh

Google calendar, whatever. And the user

does that once,

just once. So once the these are

connected you can you give the Asian

client well not not double quot is the

Asian client

>> access to those apps. So every time so

the user next time that connects to the

chat that's it. You don't need to run

all this thing again.

>> It's it's already done. It's it's the

relationship has been established

already. So the user will open the chat

again. You don't need to do all this

connecting scopes, prompts, consent

screens. That's it. That's done.

Eventually, it can die. It depends on

the policy of your upstream. The refresh

tokens may expire. In that case, yes,

you will need to deal with, oh, you need

to reload again. You do that once and

that's it.

>> Yeah. So, just an update. Was they

finally able to have syntax or my

version of cloud, I guess. But um yeah

was able to off and kind of show went

through the authenticate screen and um

yeah now I can access my same tools in a

deployed instance. Um you can do this

with several providers now, right? Um

all of which

any which support uh D as as Carlos was

saying like any which support DCR static

client or preconfigured clients um and

then yeah soon to be client ID metadata

is the next uh spec I believe that's

going to be implemented. Um, so yeah,

you'll have a lot of options to to

register new clients, new agents, um,

and access your tools. Um,

uh, yeah, I don't know if there's

anything else we turn back to.

>> Questions?

>> Okay,

>> I think that's it. Um, questions and

feedback, whatever. Um, please reach out

or

>> Yeah. I know I the guy I showed in your

workshop, but to his question, is there

a a later branch?

>> Yes.

>> Yes, absolutely. And let me push that to

his repository and let me show my final

state now. And yeah, I'll pull that up

and link it here.

>> Also,

the live demo and build

a lot

>> for the first time. Yeah, for the first

time with a major release this week was

like we just shipped this like two days

ago. So, but [snorts] yeah.

>> All right. Okay.

>> Uh but yeah, the final state is in my

branch here. Finish

finish state. Uh that should have all

the applied changes and I think I've

like tweaked uh one of the like order

history tools, but it's it's pretty

straightforward. Um there's some other

tools that are implemented there, but

yeah, it's it's up to you what you want

to implement there. Um but yeah, can I

let's see I don't know if I can I can

link this in the notes after and um

>> we'll make sure that you have this uh

I'll probably actually push it to our

our upstream workshop branch. So, and

yeah,

>> just little disclaimer, the workshop

app, well, it can suffer some

disruptions uh as we uh develop more

things. So, yeah, take that into

consideration.

>> All right.

>> All right. Awesome. Thank you.

[applause]

[music]

Heat.