Open Reader

Better Agent Auth — Bereket Habtemeskel & Paola Estefania, Better Auth

completed 40:55 Jul 21, 2026 Watch on YouTube

Current Status

completed

Video ID

JvKO40CFq-s

RAG / Chat

Enabled
Better Agent Auth — Bereket Habtemeskel & Paola Estefania, Better Auth
Description

Better Auth has grown to 27k GitHub stars and more than 1.5M weekly downloads, becoming a popular choice for developers who want to own their authentication stack. Agent Auth is a protocol for autonomous and delegated agents operating services for an organization or a user. It lets agents dynamically negotiate capabilities, manage access boundaries, and maintain secure authorization flows. This session breaks down the protocol design and demonstrates it live. Speakers: Bereket Habtemeskel — CEO, Better Auth Bereket is the Founder and CEO of Better Auth, the most popular auth framework for TypeScript, and a co-author of the Agent Auth protocol. X/Twitter: https://x.com/bekacru LinkedIn: https://www.linkedin.com/in/bekacru/ Paola Estefania — Staff Engineer, Better Auth Paola focuses on agent identity and is a co-creator of the Agent Auth protocol. LinkedIn: https://uy.linkedin.com/in/paolaestefaniadecamposdefranco

Summary

Generated by gpt-5.6-terra

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Agent systems should stop handing agents a user's standing credentials and instead treat every agent as an identifiable principal with narrowly granted, revocable capabilities.
  • Why it matters: This offers a concrete authorization-control-plane pattern for MCP-connected agents: discover tools, grant action-level authority, log every delegated action, and revoke a compromised agent without severing the entire user integration.
  • Best use: Use it as an architecture review for OpenClaw or any agent platform that currently relies on user OAuth tokens, broad scopes, MCP connectors, or opaque shared credentials.

Executive Summary

Better Auth's proposed Agent Auth Protocol argues that the central security mistake in current agent integrations is credential delegation: an agent connects to Gmail, Calendar, or another service using the user's OAuth authority and consequently acts as the user. The speakers frame this as giving a new employee the CEO's credentials rather than creating a distinct identity with a limited job description.

Their proposed model has three connected layers: discovery, authorization, and identity. A directory lets an agent discover available services and their machine-readable capabilities; capabilities replace broad OAuth-style scopes with specific permitted actions; and each agent receives its own cryptographic identity, allowing services to attribute requests to an agent, its user, and its originating host.

The workshop's Gmail/MCP demo shows the lifecycle: an email-reading agent discovers read/list capabilities, obtains user approval through a device-style authorization flow, reads email, and produces attributable audit logs. When it later attempts to send email, it needs a separate grant. Revoking the agent invalidates that particular identity, though a host may create a new agent that can still receive default-safe permissions such as read/list.

The material is strategically useful because it moves agent security beyond prompt permissions and gateway logging toward a first-class delegated-identity model. It is still an early, open-source draft and the speakers acknowledge unresolved policy questions around persistent versus ephemeral agents, enterprise policy, host control, and enforcement boundaries.

Key Takeaways

  • Claim: Do not give agents user credentials; give them delegated authority bounded to the work they are allowed to perform. | Evidence: The speaker compares current practice—connecting an agent to a user's Gmail or other personal account—to handing a new employee the CEO's credentials. The recommended alternative is to let the agent act for the user only within explicitly granted limits. | Implication: Ken should treat raw user OAuth tokens, API keys, and broad MCP connector access as an anti-pattern for autonomous or semi-autonomous agents; introduce per-agent delegated credentials instead. | Caveat: The protocol does not eliminate the need for user-to-agent delegation: agents remain associated with a user and the authorization service must continually validate grants and policies.
  • Claim: Agents need to be first-class principals with their own identities, rather than invisible processes acting under a user's identity. | Evidence: The protocol assigns each agent a private key and agent identity; logs can then identify the agent, user, and host that originated an action. The speakers explicitly distinguish this from AI gateways, which they say do not yet make the agent a principal. | Implication: A control plane should model agent ID, human/user principal, host/runtime, key material, grant set, and lifecycle status as separate entities—not merely record a user ID beside generic tool logs. | Caveat: The proposal is a published draft, not an established interoperability standard, and its lifecycle model is still evolving.
  • Claim: Fine-grained capabilities are preferable to broad OAuth scopes because an agent's intent should map to specific tool actions. | Evidence: Instead of a general 'read' scope, the proposal represents concrete operations such as list, get, delete, post, or send. In the demo, an agent authorized to list/read email cannot send an email until the user separately approves a send capability. | Implication: Define permissions at the tool/action/parameter level for agent workflows, with stronger approval requirements for externally consequential actions such as sending, deleting, publishing, or spending. | Caveat: Fine-grained authorization can create approval friction; the speakers recommend combining capability constraints with user and host policies rather than prompting for every low-risk read.
  • Claim: Capability discovery should be standardized so agents can locate permissible services and actions without hardcoded, manually wired integrations. | Evidence: The protocol proposes a well-known agent configuration endpoint, analogous to OIDC well-known metadata, plus a directory that maps user intent to service capabilities. Until services natively support the protocol, Better Auth proposes translating existing OpenAPI specifications into capability records; Gmail and Notion are cited as directory-style examples. | Implication: For an agent platform, maintain a signed or governed capability catalog rather than letting models infer tool privileges from ad hoc connector descriptions alone. | Caveat: Not every service publishes usable OpenAPI metadata, so capabilities may need to be manually declared until providers adopt a compatible discovery format.
  • Claim: Per-agent identity enables meaningful auditability and targeted revocation. | Evidence: In the Gmail demonstration, the system displays an agent ID, agent name ('email reader'), user ID, host/local-device context, granted capabilities, and action results. The operator can revoke the offending agent rather than disconnecting the user's entire Gmail connection. | Implication: Build revocation at multiple levels: individual agent/key, grant/capability, host/runtime, and user integration. Audit trails should make these objects queryable and distinguishable. | Caveat: Revoking an agent identity alone is insufficient if the host can immediately mint a replacement agent and default capabilities remain available; host-level policy and host revocation are therefore necessary controls.
  • Claim: The host—the environment that creates or runs agents—must be a policy and trust boundary alongside the agent itself. | Evidence: The protocol introduces 'host' as the place from which agents are created. The speaker says logs should expose host, agent ID, and user, and a host can be deleted/revoked if it is no longer authorized. Policies can be assigned by user or host. | Implication: Ken should not trust an agent solely because its user approved it; require runtime provenance and enforce whether a particular host, deployment, or MCP client is allowed to mint, request, and use agent authority. | Caveat: The speakers say persistent, long-running, multi-agent enterprise environments were not fully addressed in the initial February draft and are a priority for the next version.
  • Claim: A directory is intended as a discovery and authorization-metadata layer, not as a data-path proxy. | Evidence: When asked about proxying, the speaker stresses that their 'proxy' is only a directory matching intent to capabilities and organizing provider-level logs. They reject a real proxy model as non-scalable because it carries data. | Implication: Separate the control plane (catalog, grants, policy, identity, audit) from the data plane where possible, but verify that services enforce the issued authority rather than relying on voluntary client behavior. | Caveat: Avoiding a data-path proxy shifts enforcement responsibility to participating servers, SDKs, and integrations; the transcript does not establish how non-compliant clients or direct API bypasses are prevented in every deployment.

Detailed Brief

Protocol and implementation shape

  • Claims: The project is presented as an open-source, protocol-agnostic draft intended to work alongside existing service authentication rather than requiring an immediate replacement of OAuth.; The server-side component verifies agents, evaluates policies and constraints, and issues or validates authorized grants.; The SDK/MCP side creates agent key material and associates keys with individual agents.
  • Evidence: The speaker describes three layers deployed as one protocol: an Agent Auth server/plugin, SDK integration with MCP clients, and a directory.; The proposed discovery endpoint follows the familiar OIDC pattern of a public '.well-known' configuration location.; The MCP demo uses a device-style approval flow: the agent requests listed capabilities and the user approves or denies them.
  • Caveats: The demo is intentionally simplified and uses an Agent Auth MCP integration; production implementations need to ensure agents cannot bypass the controlled tool path with direct credentials or alternate connectors.; The transcript references a future draft intended to further constrain how agents leave the environment to request external services.
  • Implications: This is a reusable architecture pattern: identity issuer and policy engine, capability registry, enforcement point at service/tool boundaries, and auditable lifecycle management.; MCP support alone is not an authorization model; it needs an identity, grant, policy, and enforcement layer around it.

Policy and user-experience design

  • Claims: Capabilities can include constraints beyond the basic action, such as maximum execution time and other policy conditions.; Authorization should be risk-tiered rather than forcing users to approve every benign operation.; Hosts and user roles can receive different standing policies; the speaker uses a CEO versus recently joined employee as an example of differentiated access.
  • Evidence: Read/list email is treated as a default-safe capability in the demo host, while sending email triggers a new request and can be denied.; The interface exposes agent status and whether an action request was approved, denied, or revoked.
  • Caveats: Treating read access as inherently safe is context-dependent: inboxes can contain highly sensitive data, so read/list defaults should be conditioned on data classification, tenant policy, and the trust level of the host.; The transcript supports the idea of constraints but does not specify a standard policy language, decision model, or evaluation semantics.
  • Implications: Use approval policies based on action consequence, data sensitivity, delegation duration, and runtime trust—not merely HTTP verb or generic 'read/write' classifications.; Agent UX should expose a comprehensible action-level consent record while allowing pre-approved policy envelopes for trusted recurring work.

Notable Concepts & Terms

  • Agent Auth Protocol: Better Auth's proposed open-source protocol for agent discovery, delegated authorization, identity, auditing, and revocation.
  • Agent as a principal: The core model: an agent has its own identity and keys, acts on behalf of a user, and is distinguishable from that user in authorization and logs.
  • Capabilities: Fine-grained, concrete permissions such as list, read, send, delete, or post, intended to replace broad OAuth scopes for agent actions.
  • Well-known agent configuration endpoint: A proposed public metadata endpoint, inspired by OIDC discovery, through which agents can learn how to interact with a service and which capabilities it offers.
  • Directory: A control-plane catalog that maps agent intent to available service capabilities; it is explicitly not intended to proxy application data.
  • Host: The runtime or environment that creates an agent; it is tracked in logs and can be subject to policy or revocation independently of a user or agent.
  • Device flow: The authorization approach used in the demo, where an agent requests capabilities and a user approves them through a separate interaction.
  • OpenAPI-to-capability translation: An adoption bridge that derives agent-readable capabilities from existing OpenAPI endpoint definitions before services natively publish Agent Auth metadata.

Operator Notes / Why Ken Should Care

  • Inventory every agent and MCP connector that currently receives a user's OAuth token, long-lived API key, or broad integration scope; classify whether it can read sensitive data, write externally, delete, or spend.
  • Adopt a minimum delegated-identity schema across the agent platform: agent ID, user/delegator ID, host/runtime ID, public-key/key ID, capability grants, issue/expiry times, and revocation state.
  • Require a distinct grant for high-consequence operations—send/publish/delete/transfer/modify permissions—and add parameter-level constraints such as recipient allowlists, execution windows, spend limits, and maximum duration.
  • Design revocation tests that cover four paths: revoke one agent, revoke one grant, revoke a host/runtime, and prevent a revoked or untrusted host from silently reminting an equivalent agent.
  • Evaluate Agent Auth's draft/SDK as a reference implementation, but do not make it a production dependency without validating enforcement against direct API bypass, persistent-agent lifecycle behavior, multi-tenant policy isolation, and the security of private-key storage.

Source/Metadata

  • Title: Better Agent Auth — Bereket Habtemeskel & Paola Estefania, Better Auth
  • Transcript words: 7941
  • Duration seconds: 2455
  • Timestamp note: No timestamps or chapter markers were present in the supplied transcript; the transcript also contains substantial repeated demo material.

Transcript

5390 words en Processed in 258.3s

Well, hello everyone. Can you hear me all okay? Yes? Perfect. Welcome to our talk, our workshop actually. I know maybe you were expecting Birgit also. He couldn't come, but we make this workshop together for you. Okay? So as you see, you have the QR code. You can go ahead and go there. It's our page for Asian health protocol, so that you have it and I don't have to spell it for you. Okay, so my whole idea today is to tell me, me telling you stuff and you do this and show you how to do stuff. I want us to take one hour at least to think about Asian security, Asian health. Because sometimes we are excited about this new AI era, right? But we never think about, or maybe yes, but not as much as I wished, what happens when you, for example, say, hey Asians, where are my, maybe my schedule for tomorrow, where are, send an email. Have you ever thought of this? How many of you, raise your hand, how many of you use AI agents every day? Okay, higher. Don't be shy. Okay, great. How many of you give them access to your Gmail, to your calendar, to your personal accounts? How many of you? Oh, so much less. Okay. The ones that do, what do you do? You connect an MCP server? Okay, yes. And they have another one. Good. Maybe you connect your personal token to dot end point. Okay. So, what happens when we do this? We're actually doing, the agents, it's acting on behalf of us, but pretending to be us. So, do you think that's a good idea? Yes or no? Who thinks it's a good idea? Not a good idea. Why? Exactly. And why we didn't think about this before? Okay, so it doesn't matter. Here we are. We are thinking about it. I always remember the time when internet came. I'm old, almost 40, so I remember. And everybody was so happy about it. But then it started to question, okay, all the whole data is public. It's like we are in the same moment today, right? We are really excited about AI, and then after, we start to think about security. But it's good. So, why I put there a lot of data to hire your agent? The analogy I want you to think about, let's say you have a company, or a part of a company, and you hire someone. You give them, you need them to have access to things of the company, right? So, what do you do with these people when you join? Or when you show, what did they give to you? You have your own email, right? Your own access, your own credentials. So, if you think about it in the ancient world, what are we doing without agents? It's like we are doing the CEO credentials, right? You never say, okay, this is the credentials of the CEO, go and read the email. No. Because anything could happen. This is the same. The idea will be to hire an agent in a sense of giving them your agent authority instead of your credentials. Do you think it's a good idea? Yes or no? No. Okay. My idea is, I know sometimes we could be shy, but I think it would be nice if we could interact a bit, because it's a moment that, thanks to the engineer and all of us being here, all of your time, we could get together and think about something. I think it's not common, right? So, make 100% of it. Okay, great. So, did you all go to the page there, the QR code? Yeah? Great. So, remember my idea of saying, okay, agents read my emails, right? Have you ever thought how the agent gets there? How it gets to your email? First of all, how do agents know what they can do? Huh? Okay, great. So, you do it by hand, right? It's not something automatic. Yes. Exactly. But, exactly. But, huh? Exactly. Context window also, too. But you always somehow connect something to the agent, like, okay, this is what you can do, right? So, what if we have an ideal world, where an agent can go to maybe a directory and say, oh, this is the whole thing I can do, and these are all the things I can execute? That would be the smartest idea, right? Have you ever used a phone book? Yeah, right? It's the same, like, who I can call? So, I go and look in the phone book, and then I have how to call it, have the number. It will be the same. What I want to do, and how do I call it? So, that was our first problem: discovery. How agents discover what they can do. And the idea will be an automatic way, not just us all the time telling how and connecting and stuff, right? Then also, there's another part. It would be nice to tell the agents, or grant agents, what they can do and what not, but really specific. The ones that connected the Gmail accounts, maybe they all gave them read access, right? Just read, so we can, I don't know, don't send, or not remove anything, so it's safer. Okay, but what if you have so much important information there that then, if something gets wrong with the agent, somebody else can read your data? It's not good either. It's not safe in any way. So, what is it? What if we can get all this, what the agent can do, all these tools, as he mentioned, and you can grant access to every tool? Like, this yes, this no, this reading, it's okay. That would be a better idea, right? So, we think about authorization to that agent, not to act on behalf of me and have everything I can do, then the agent can do. It's like going back to the hire example, that a person I just hired has all the same access as the CEO. Or maybe you have an assistant or a friend that does something for you in your real life. You will never give them your access to all your things, right? And if you do, you change them after. So, this is the same thing. And also, okay, we have an ideal world when the agents can discover what they can do. Then we can tell them what they can do or not. But how do we trace them down? How do we trace today what the apps do on our behalf when we authorize them? Huh? Exactly. Okay. All the logs. So, perfect. All the logs. So, in the logs, I can see what? I need to see some identification, right? Which agent did what on behalf of which user? In order to do that, it comes to our main thing: give the agent identity. If every agent has identity, we can trace them down. We can know what the agent did, what, when, on behalf of which user. It seems so much, so much better, right? And also, what else can you do when you can trace someone? Regarding the whole hiring thing, you can fire them if they do something wrong. You can revoke access. In the same way, the agent will be revoked if you know who they are. If something was wrong with today's things, you have to disconnect the whole thing, right? Yes or no? So, imagine how, oh, this agent is fucked up. Sorry for the word. You can't remove it. That's it. So, we have traceability. We have the whole thing. Okay. So, as it comes out, as a sum up, we have the discovery issue, where the agent can go, find the service, and read the capabilities; authorization, what this agent can do, scoped down; and who is this agent? Are you on board with this? Do you think it's a good idea? Do you have any questions? Jump in. Okay. Great. Have you ever heard of capabilities? Raise your hand. Yes? Okay. Do you all know what a capability is? Who doesn't know? Okay. Almost the whole room. Okay. So, the idea of using capabilities is instead of using scopes. You know, scope is like a big thing. For example, you have the read scope. So, what does that mean? It's nothing so specific. The idea of the capability is what an agent can do, but it's more cut down. So, I can actually determine what action an agent can do. So, the idea is going back to the example I put in the beginning. Let's say you talk to the AI in the chat and you say, okay, give me my emails from the last week. So, the agent has an intent to do something, right? It has to be a way that that intent has to be jump in. Okay. Great. Have you ever heard of capabilities? Raise your hand. Yes? Okay. Do you all know what a capability is? Who doesn't know? Okay. Almost the whole room. Okay. So, the idea of using capabilities is instead of using scopes. Scope is a big thing. For example, you have the read scope. So, what does that mean? It's nothing so specific. The idea of the capability is what an agent can do, but it's more cut down. So, I can actually determine what an action an agent can do. So, the idea is going back to the example I put in the beginning. Let's say you talk to the AI in the chat and you say, okay, give me my emails from the last week. So, the agent has an intent to do something, right? There has to be a way that intent has to be mapped to a tool or maybe several tools. So, that's the idea. The tools will be capabilities, and intent will be matched to that. So, that's what we're solving with discoverability. If you ever read the protocol that we are proposing, or maybe read it later, you'll see our idea of a well-known agent configuration endpoint. If you know a bit of identity, you remember OIDC, right? OIDC Connect. These are the same well-known. And the idea is for an agent to have a public place to know how they can interact with the service. Like everything, the kind of encryption, et cetera. So, there will be something like this, and also a place to list capabilities and stuff. But what happened, for example, in a world like today, where we are still, I hope in the future we adopt this, but in the meantime all the services are still working just with OAuth? So, how do we do it in the meantime? What do we need agents to be able to know what they can use from each service? Let's say Gmail. We can build something like a directory. So, the idea is to have something. Let's see it here. So, let's say most of the... You're familiar with OpenAPI? OpenAPI spec? Yes? Okay. So, most of the common services we use, they all implement OpenAPI. So, we have a place where we as developers or engineers can say, okay, what can this service do? So, the idea is to use that and convert it to capabilities. So, at the beginning, until we... Every service is vacation now. So, let's say, for example, do you guys use... I don't know. Tell me a service you use. OpenAI. OpenAI. Ah? Okay. Gmail, we have it there. But let's say, for example, let's see if it works. OpenAI. OpenAPI.json. And sometimes they have public... They have the publics. OpenAI. But we need a JSON. I don't see it. Maybe I open... Okay. I do know... I think it's this one. No. Well, that went wrong. Notion. Notion has a really good one. I wanted to use another one from you guys, but Notion is more reachable. So, here. So, if you have, for example, not every service has, but the OpenAPI JSON, what we're doing with the HTML protocol is translating this... Oh, I already registered it. So, I'm going to show you guys. Yeah. What is this one? Sorry. Let's see it here. It will form something like this. This is an example, but it's the same. So, you will get all the capabilities from the endpoints. You see, sometimes you see a delete, a get... So, it will be the idea to approach a middleware to this point. Yes. Oh, sorry guys. Thank you for telling me. And... Here. Is that better? Oh, thank you. Sorry, guys. Okay. So, the idea is to see here, you can translate the endpoints to capabilities. So, because we are still... This is just because we still don't have so many services, or let's say none, implementing the agent of. But the idea is in the meantime we have something that translates it. So, what does this mean? It means you will have something... For example, do you have there in the agent of protocol, you see you have a directory. This directory will have, for example, the Gmail one that we did the same. So, you see you have, for example, 20 lists of capabilities. So, the idea is you grab what the service can do, what it is exposing, maybe through OpenAPI, or maybe you do it yourself. Because, for example, maybe you want to automate a workflow. So, the idea is everything gets listed here, so the directory will be like a phone directory for the agent. Are you following me? Yeah? The what? Sorry? Yes. It's a good point. Did you hear him? Fine-grained out. Okay. So, the idea is yes, in a sense of having the most scope thing as possible, but still, fingering out still goes like minting a token to the user. We want to mint a token for the agent. So, what we are switching is the principal. We now want the agents to be a principal actor. But it's a really good thing. That's why we fire on that. I think it's one of the best things we can do. Okay, great. So, going back to the capabilities, the idea is what I just said. Instead of having the scope ones, you have the readings or maybe just the gets or the deletes or the posts, like everything is quite discerned. So, you can decide whether they can or not. Okay. Until here, do you have any questions? Yes? Yes. Yeah, yeah, that really sucks. The idea is you can do it manually. You can actually declare everything. So, in the directives or in the future, the agent knows how to do. It's less common, but yeah, it could happen. But the idea is in the meantime, we do this until the services implement this agent else. So, yeah, it's a good question. Okay. So, remember our problems, right? So, now we are trying to get a solution for how the agents know what they do with the directory. Then, we have a way to authorize them through the capabilities. And now, if you remember, we said it was a good idea to give them identity, right? So, what we come to is giving agents a private key, a famous private key. So, each agent will have its own. And that will be attached to the identity. So, in that sense, because every agent has its own identity... Now, if you... I see. You want me to put this on light mode too? Ah, why didn't you say that before? Okay. Let's go back to this. There. That's better? Okay. So, now that the agent will have access to its own private key, they can sign tokens, they have their own minted tokens, and everything is encrypted with the private key. So, what this means is from now on, instead of a service, let's say Gmail, seeing a user interacting with the service, we can have a log that actually says, okay, this agent is doing something on my behalf that is connected to the user. But it's actually, for example, an agent from Courser or an agent from Cloud or an agent from whatever. So, we are changing the paradigm. We have stopped seeing an agent as hiding behind the user, and now the agent is there as a principal acting. So, for me, it was really exciting. So, do you have any concerns about this private key, private key polychees? Yeah. Exactly. That's beautiful, right? You can say, oh, this is not doing what I'm supposed to be doing, and I go and revoke it. So, it's good. And maybe you can think, okay, I revoke it, but the access token is still there. So, what you can do is delete it with the GDI. So, bye. Yeah. The problem I know was operating the agent of the API. Mm-hmm. Always token, always the agents, they always have a user that they are reporting to. They are never detached. So, the agent is always with a user. Yeah. Yeah. Yeah. Exactly. You have all the information. The agent, also the host. We are introducing a new thing that is called host. That is the place where you are creating these agents from. So, you actually can also delete the host. You can say, okay, this host is not authorized. So, you can see the host, you can see the agent ID, you can see the user, you can see everything. Okay. Great. More questions? Okay. Don't be shy. We are here for this. Yes. Can you speak a little bit higher? Yeah. So, what you can do is delete it with the GDI. So, bye. Yeah. The problem I know was the operating agent of the API. Mm-hmm. Always token, always the agents, they always have a user that they are reporting to. They are never detached. So, always the agent is with a user. Yeah. Yeah. Yeah. Exactly. You have all the information. The agent, also the host. We are introducing a new thing that is called host. That is the place where you are creating these agents from. So, you actually can also delete the host. You can say, okay, this host is not authorized. So, you can see the host, you can see the agent ID, you can see the user, you can see everything. Okay. Great. More questions? Okay. Don't be shy. We are here for this. Yes. Can you speak a little bit higher? Yeah. That's a great question. Actually, it's more an enterprise focus, right? Because we did this in February, the things changed so much until now. For example, agents are not so ephemeral. Maybe you have forever long agents, right? Or maybe you have two agents. Or maybe you have agents inside of a company and they have policies. So, we are working on that in a new draft and we are addressing that too. Because it's something quite important to address. So, yes. I was about to say that in the end, but yeah, we are about to release a new draft. If you have, this is an open source, it's a project that we want all of us to own. So, if you have some ideas, you reach out, that one for example. It's really good. So, we can improve. It's good for ourselves and good for everyone. And I don't want this to be just for enterprise. It's just for all of us that use AI, that would be safe. So, thank you. Okay. So, that was just discussing the B1, B2. Great. So, three layers, then one protocol. Why we say this? Because if you go and search the website, you will see we publish a first version, just a draft or an agent looking inside of a draft. The idea is you can use this and play around and see what you come up with. So, in the agent out plugin, you can use it on the server side. So, a server can verify an agent or issue grants or force whatever constraint that you have been doing with that. Also, on the SDK side, we ship it with an MCP. So, you can connect it to your cloud to try it out. You can connect it to whatever you're using. Courses or whatever you're using with MCPs. And also, the other layer is the directory. It's just a place, like a phone book. Where the intent matches the action. So, intent will be matching the capabilities. So, the idea is that we can see it in action. So, what we will do, if you want, you can go to what I shared in the QR code. Let's go to the page. Okay. You will see a directory there. Did you all find the directory button? You will come into this and you will see a connect button. So, you have to log in first for sure. And you will see a connect. And then you will see the MCP. So, you can connect that, for example, to the cloud. I have it here. I wanted to show you guys a bit what we were talking about. So, let's say we say, I'm going to ask for emails. Okay. I just need a bunch of demo emails, but I'm going to show it to you guys. So, I don't show personal information. But, for example, I have my MCP connected. So, you will see something like this. Connectors. Customize. Here. You see ancient DALF. You will see something like this. Then you can approve or disapprove or always deny. It's just the ancient DALF MCP. And if it's that. My idea is you try it out just with the MTP of ancient DALF. So, the ancient doesn't have access to other tools. So, it's the principal one to see how it interacts and how it gets the identity. Our whole idea is when you use this MTP, the ancient will have an identity. We request you for capabilities. It will try to execute it and we will see the logs and everything running. Okay. So, let's see, for example. Okay. Bring me my last email. Oh, sorry. Okay. So, it's going to use the ancient DALF connectors. Can you see? It's too small? It's okay? Okay. Okay. You see? It's using the, because it has the NCP, it's using the directory to see from my intent of bring me my last email, which capabilities are out there. And he's asking for approval. We are using here device, the Valsflow. Do you know the device flow? Are you familiar? It's just connecting a device. So, we are actually, it's a device. So, you can see the ancient code is called email reader. It's not for default. You can change later if you want to. It's requesting me to read and list my email. I'm going to approve. And I'm going to show you that guys later. So, the idea here is that the ancient will connect. We'll get the identity. We'll have the last email. Okay. Okay, great. We have a nice email. So, we know ancient can read emails. That's not the demo. The demo is what happened. So, remember at the beginning, we said if we gave identity, we can have logs. So, let's see what the ancient did. So, I know I have an activation. There's some email reader. It has this ancient ID. It's in a local device. It has these things. And also, I can see here, this ancient with this user ID. Okay. I see the ancient here. It is the email reader and it got these results. So, I'm actually tracking down what the ancient did, right? So, now, let's say I want the ancient to, I don't know, send an email. By default, what we are proposing is all the hosts, for example, Cloud, have reading capabilities by default. So, then it wouldn't mess up your ancient with your inbox, right? So, let's see. Let's send an email. Who has a really short email that I can put in there? Hello. Really? No, but an actual one. Who has a good email? If not, I can put my own. But if you guys want to show. Okay. So, I'm going to put mine. You see, I made too much. I'm going to put myself saying I'm going to use Hello World. I thought that your email was Hello World. It was so cool. Okay. So, the idea here is if you, as you just saw, the ancient just has the reading capabilities. Ideally, it never could send the email without me granting it. Okay. So, for example, we can see it here, right? The only capabilities it has are these two. So, it will try to see it here. We can also, we also did this extension for us to actually watch better what the agent was doing. Okay. Okay. I'll try to use the patch for security verification. Okay. So, you see? The agent now is using Siva, async out, its client back channel utilization. Instead of just showing me redirect and seeing a device that I'm approving, I could approve from here. So, for the demo, I'm just going to approve. And now that the agent has approved, I approved it, it will be actually sending the email. So, you will see in the capabilities here that now you can send the capabilities of send emails. And actually, we can see here, it just sent the email, right? So, what do we want to try this? We're going to see if you see, no, no. Okay. Here is the email. Okay. So, what we want to try now, let's say there's something wrong with the agent, somebody was trying to access my Gmail, trying to publish it or whatever. So, the idea of this whole thing is to have the trustability we just saw. It's on the logs, right? And what if we want to revoke it? Let's try. Let's try to revoke it and try to, for example, read my emails. So, we're going to revoke it first. So, it cannot see a thing. Oh, I lost the page. Here. So, in agents, we can revoke the agents. So, bye-bye. And now we can say, read that last email you just sent. Okay. You see? The connection got revoked. So, what happened now? Why it can't read it anyway? Because what we did is he created another agent, another entity, because I revoked the one before. Okay. So, what we want to try now, let's say there's something wrong with the agent. Somebody was trying to access my Gmail, trying to publish it or whatever. So, the idea of this whole thing is to have the trustability we just saw. It's on the logs, right? And what if we want to revoke it? Let's try. Let's try to revoke it and try to, for example, read my emails. So, we're going to revoke it first, so it cannot see a thing. Oh, I lost the page. Here. So, in agents, we can revoke the agents. So, bye-bye. And now we can say, read that last email you just sent. Okay. You see? The connection got revoked. So, what happened now? Why can't it read it anyway? Because what we did is, he created another agent, another entity, because I revoked the one before. But this is just happening because the get, the list, is a default capability in our host, because for us, it's safe. What if now I wanted to say, send an email saying hello to myself? It will do the same. It will ask for it. So, actually, it's working, right? I can actually revoke it. I can see the logs. I can say what the agent can do or not. But you think it's nice to have this kind of workflow. It's more controlled. Yeah? You have any questions about this? Something that pops in your mind? Yeah? Yes. Yes. Sorry. Yeah. Every constraint that you want to be careful about, you can put in the capabilities. So, it's good. Mm-hmm. Yeah. Yeah. Yeah. Yeah. Yeah. It's good. Yes. Exactly. You can say maximum time of executing. You can say the time. You can say everything. Yeah. It is. Oh, thank you. There. You can have both. Our idea is to be safe but not to be annoying. Imagine every time you had to read something, oh, I had to approve every time, you're going to hate us. So the idea is, a host, for example, or include, sorry, I spoke in Spanish, include, or maybe a host or someone specific you want. For example, let's say a CEO can do everything, and they're recently joined, just have this specific access. So you can do it by user policies, as I was talking about, or you can do it with host policies. So you have to be in the middle, I think, of good UX, good user experience, but also secure enough. Yeah. Yeah. Yeah. Yeah. Yeah. Because the agent alpha we're doing, like I said, you can try it out. With the server part, it's the one that's going to verify the agent back with the user. It's going to verify the policies. It's going to verify if it has access or not. So, yeah, all the time verifying. Yeah. Great. So the whole idea was to show you this. I was trying to ask the agent to send. I need to confirm. So you see? So here I have the request. I didn't accept it. So let's say I denied it. It would be the same. I just did. So ideally he wouldn't. You see? That's red. Okay. So it's working good. So he wants me to allow it. I'm going to. So can you tell me agent status? So you can have, all the time, track down what the agent is doing. It's revoked or not. Yeah. So what's the point of the thing is that you can serve as an Android server that has a skill that has a . Oh, are you saying if you have, for example, a skill that is saying to use the MCP server differently? Directly. Okay. Yeah. Well, actually what we are doing is, this is just an example for you to see how the protocol is doing, just a demo. But you can enforce, for example, that the agent, the only thing that can use is the MCP tools in this case. That's what we did with the plugin. But yeah, you have, for our next protocol, it's going to be more capped down. So the only way the agent can go out and ask for services is through the agent out protocol. So it's a really good question. Yeah. The what? Sorry. The proxy? Here. Yes. You have this in the directory. Now you can use it. When you log into, for example, you are connecting a lot of services in the directory. So the agent, when it connects to the MCP, can know the capabilities that it can do. So inside of the proxy, you can see, for example, the Gmail. You can see all the capabilities that it can do. You can see the agents doing stuff, the logs, and everything. So every log is cut down by provider. Okay? Okay. And about that, our proxy is just a directory. It's not a real proxy. For us, proxy is a really bad idea. It's not scalable because proxy uses data. So in this case, it's just a directory matching intent with capabilities. Okay. So. So. So. Back again, if you want to try it, you can. It's still alive. You can use the agent.org plugin, the SDK. It's really nice because we started from the problems, and now actually the solutions, right? The discovery, authorization, and identity. This is kind of what I will show you guys, like MCP, how to connect it. So, again, the SDK side with MCP is the one that is creating the keys and assigning it to the agents. And the server side is verifying, authorizing, giving the grants that are authorized by the user, and so on. So, for me, the most interesting thing of all is we need to stop giving credentials, our credentials, to our agents. We need to give them authority. We should stop saying pretend to be me, instead of saying act for me within these limits. So, we are almost at the end. If you have any questions, something that pops into your mind, or it could be also an addition to what I'm saying, I don't know if you ever thought of this. Do you think it's a good idea that we implement something like this? I'm not saying this one, but maybe. Yeah? Okay. The idea is that this is open for everyone. So, I would love you guys to join us on this score, or you can send me a message, send me an email, be in the channel, be active, because if we improve this for all, it's going to be good for all of us. Yeah? Yes? Yes. Yes, please. And please do. Yes, please do. Sure. No, it's totally agnostic. Yeah. Yeah. Exactly. That's the idea. Yes. Yes. Yeah. That's on our B2, and that's our prime focus now. So, yeah. That's a great idea. Great. Anyone else? Yeah. No, it's different. Yeah. No. We also, we have as inspiration everything that's out there, but it's not the same. It's different. Yeah. Because they are not still treating an agent as a principal. We are treating an agent as a principal. They have their own identity. So, from that, it's different in that way. I don't know. I don't have that information. Yes? I'm sorry, what? Oh. Yeah. You see, it's connected because of the discovery. But it's still the same. For me, the most important part is the agent being principal, having their own identity. AI gateway doesn't do that yet. I hope it does. But the whole idea is to have accessibility, have the whole life cycle, and to be able to track down and hunt, if you want, an agent. So, that you only have if you have identity on each agent. And AI gateway is not providing that. Okay. Sure. Is there any more questions? Okay. Well, you can reach me in the, that's my email if you want to email. If you want to contribute together, it would be nice. That's my LinkedIn too, and the Discord channel from the whole agent out protocol. Okay. Thank you so much. It's been a nice one. Thank you so much. It's been a nice one. We request you for capabilities. It will try to execute it and we will see the logs and everything running. Okay. So, let's see for example. Okay. Bring me my last email. Oh, sorry. Okay. So, it's going to use the ancient DALF connectors. Can you see it's too small? It's okay? Okay. Okay. You see? It's using the, because it has the NCP, it's using the directory to see from my intent of like bring me my last email, which capabilities are out there. And he's asking for approval. We are using here device, the Valsflow. Do you know the device flow? Are you familiar? It's just like, it's like connecting a device. So, we are actually like, it's a, it's a, it's a, it's a device. So, you can see the ancient code is called email reader. It's not for default. You can change later if you want to. It's requesting me to read and list my email. I'm going to approve. And I'm going to show you that guys later. So, the idea here is that the ancient will connect. We'll get the identity. We'll have the last email. Okay. Okay, great. We have a nice email. So, we know ancient can read emails. That's not the demo. The demo is what, what happened. So, remember with, at the beginning, we say if we gave identity, we can have logs. So, let's see what the ancient did. So, I know I have an activation. There's some email reader. It has this ancient ID. It's in a local device. It has these things. And also, I can see here, this ancient with this user ID. Okay. I see the ancient here. Just is the email reader and it got these results. So, I'm actually tracking down what the ancient did, right? So, now, let's say I want the ancient to, I don't know, send an email. By default, what we are proposing is like all the hosts, like for example, Cloud, has reading capabilities by default. So, then, it wouldn't mess up your ancient with your inbox, right? So, let's see. Let's send an email. Who has like a really short email that I can put in there? Hello. Really? No, but an actual one. Who has like a good email? If not, I can put like my own. But if you guys want to show. Okay. So, I'm going to put mine. You see, I made too much. I'm going to put myself saying I'm going to use Hello World. I thought that your email was Hello World. It was so cool. Okay. So, the idea here is if you, as you just saw, like the ancient just have like the reading capabilities. Ideally, it will never could send the email without me granting it. Okay. So, for example, we can see it here, right? The only capabilities has is these two. So, it will try to see it here. We can also, we also did like this extension for us to actually watch it better what the agent was doing. Okay. Okay. I'll try to use the patch for security verification. Okay. So, you see? This, the agent now is using Siva, like async out, like it's client back channel utilization. Instead of like just showing me like redirect and see a device that I'm approving, I could approve from here. So, for the demo, I'm just going to approve. And now that the agent has approved, I approve it. It will be actually sending the email. So, you will see in the capabilities here that now you can send the capabilities of send emails. And actually, we can see here, he just, it just send the email, right? So, what do we want to try this? We're going to see if you see, no, no. Okay. Here is the email. Okay. So, what we want to try now, let's say there's something wrong with the agent, somebody was trying to access my Gmail, trying to publish it or whatever. So, the idea of this whole thing is to have the trustability we just saw. It's on the logs, right? And what if we want to revoke it? Let's try. Let's try to revoke it and try to, for example, read my emails. So, we're going to revoke it first. So, it cannot see a thing. Oh, I lost the page. Here. So, in agents, we can revoke the agents. So, bye-bye. And now we can say, read that last email you just sent. Okay. You see? The connection got revoked. So, what happened now? Why it can't read it anyway? Because what we did is like, he created another agent, another entity because I revoked the one before. But this is just happening because the get, the list, is a default capability in our host. Because for us, it's safe. What if now I wanted to say, send an email saying hello to myself. It will do the same. It will ask for it. So, actually, it's working, right? I can actually revoke it. I can see the logs. I can say what the agent can do or not. But you think it's kind of nice to have this kind of workflow. It's more controlled. Yeah? You have any questions about this? Something that pops in your mind? Yeah? Yes. Yes. Sorry. Yeah. Every constraint that you want to be careful about, you can put in the capabilities. So, it's good. Mm-hmm. Yeah. Yeah. Yeah. Yeah. Yeah. It's good. Yes. Exactly. You can say maximum time of executing. You can say the time. You can say everything. Yeah. It is. Oh, thank you. There. You can have both. Our idea is like to be safe but not to be annoying. Imagine every time you had to read something, oh I had to approve every time, you're going to hate us. You know? So the idea is like a host for example or inclusive, sorry I spoke in Spanish, include or like maybe a host or like someone specific you want like for example let's say a CEO can't do everything and they're like recently joined just have like this specific access. So you can do it like by user policies as I was talking about or you can do it like host policies. So you have to be like in the middle I think of like good UX, in the good user experience but also secure enough. Yeah. Yeah. Yeah. Yeah. Yeah. Because the agent alpha we're doing like I said you can try it out. With the server part is the one that's going to verify the agent like back with the user, it's going to verify the policies, it's going to verify if it has access or not. So yeah, all the time verifying. Yeah. Great. So the whole idea was to show you this. I was trying to ask the agent to send. I need to confirm. So you see? So here I have the request. I didn't accept it. So let's say I denied it. It would be like the same. I just did. So ideally he wouldn't. You see? That's red. Okay. So it's working good. So he wants me to allow it. I'm going to. So can you tell me agent status? So you can have all the time like track down what agent is doing. It's revoked or not. Yeah. So what's the point of the thing is that you can serve as an Android server that has a skill that has a . Oh, are you saying if you have, for example, a skill that is saying to use the MCP server differently? Directly. Okay. Yeah. Well, actually what we are doing is we are in for in this just an example for you to see how the protocol is doing. Just like a demo. But you can enforce, for example, that the agent, the only thing that can use is the MCP tools in this case. That's what we did with the plugin. But yeah, you have like for our next protocol, it's going to be like more, more caped down. So the only way the agent can go out and ask for services is through the agent out protocol. So it's a good, really good question. Yeah. The what? Sorry. The proxy? Here. Yes. You have this in the directory. Now you can use it. Like when you log into, for example, you are connecting a lot of services in the directory. So the agent when it connects to the MCP can know the capabilities that it can do. So inside of the proxy, you can see, for example, the Gmail, you can see all the capabilities that it can do. You can see like the agents doing stuff, the logs and everything. So every log is like cut down by provider. Okay? Okay. And about that, our, actually, proxy is just a directory. It's not a real proxy. For us, like proxy is a really bad idea. It's not scalable because proxy uses data. So in this case, it's just like a directory matching intent with capabilities. Okay. So. So. So. Back again. If you want to try it, you can. Like it's still alive. You can use like the agent.org plugin, the SDK. It's really nice because we started like from the problems and now actually the solutions, right? Like the discovery, authorization, and identity. This is kind of a, what I will show you guys like MCP how to connect it. So, again, the SDK side with MCP is the one that is creating the, the, the keys and assign it to the, to the agents. And the server side is like verifying, authorizing, right? Um, giving the grants that are authorized by the user and, and so on. So, for me, the most interesting thing of all is we need to stop giving credentials, our credentials to our agents. We need to give them authority. That's, should we stop saying like pretend to be me instead of saying like act for me within these limits. So, we are almost in the end. If you have any questions, something that pops into your mind or it could be also an addition of what I'm saying. I don't know if you ever thought of this. Do you think it's a good idea that we implement something like this? I'm not saying this one, but maybe. Yeah? Okay. The idea is that this is open for everyone. So, I would love you guys to join us on this score or you can send me a message send me an email, be in the channel, like be active because if we improve this for all, it's going to be good for all of us. Yeah? Yes? Yes. Yes, please. And please do. Yes, please do. Sure. No, it's totally agnostic. Yeah. Yeah. Exactly. That's the idea. Yes. Yes. Yeah. That's on our B2 and that's our prime focus now. So, yeah. That's a great idea. Great. Anyone else? Yeah. No, it's different. Yeah. No. We also, I mean, we have like as inspiration like everything that's out there, but it's not the same. It's different. Yeah. Because they are not still treating an agent as a principal. We are treating an agent as a principal. They have their own identity. So, from that, it's different in that way. I don't know. We don't, I don't have that information. Yes? I'm sorry, what? Oh. Yeah. You see, it's connected because of the discovery. But it's still the same. Like, for me the most important part is like the agent be principal. Have their own identity. AI gateway doesn't do that yet. I hope it does. But the whole idea is to have like accessibility, have the whole life cycle and to be able to track down and hunt if you want an agent. So, that you only have if you have identity on each agent. And AI gateway is not providing that. Okay. Sure. Is there any more questions? Okay. Well, you can reach me in the, that's my email if you want an email, if you want to contribute together, it would be nice. That's my LinkedIn too and the Discord channel from the whole agent out protocol. Okay. Thank you so much. It's been a nice one. Thank you so much. It's been a nice one.