Good morning, everyone. Thank you for joining this session. So let's start with the obvious thing. As we all know, keeping up with the AI is like sprinting alongside a corvette. So you can run as fast as you can, but you're always going to fall short. So in this new world, we now have security agents that are monitoring and blocking threats. Before we even notice, there are coding agents that are basically reviewing and merging pull requests overnight. There are meeting copilots that can caption conversations in any language as they speak.
So that is great for overall efficiency, but as the saying goes, with great power comes great risk. So how do our authorization standards that were originally built for slower request and response model keep up with this new reality? Yes.
Okay, I think we're good now. Sorry for that.
Yeah, so it's about real-time authorization and dynamic continuous authorization protocol. So as I was saying, that keeping up with the AI is like sprinting alongside a corvette. So you can run as fast as you can, but you will never catch up. So in this new world, we now have security agents that are monitoring real-time threats. Before we even notice, we have coding agents that are basically reviewing and merging pull requests overnight. We have meeting copilots that can caption conversation as they happen in any language.
So that piece is great for overall efficiency, but as the saying goes, with great power comes great risk. So how do our today's standard keep up with this new reality? Because those standards were built for traditional request and response model. So in the next few slides, I'm going to explore why those static bearer tokens fall short, and how we can build a real-time protocol on top of HTTP3 and QUIC so our agents can be blazing fast and secure.
All right, so before we dive into the topic, I would like to build some context, and let's rewind and see how we got here. So it really kicked off in 2017, when a Google team published a landmark paper, which is called Attention is All You Need. That paper introduced the transformer architecture. So the transformer architecture is a link attention mechanism to the text generation. So you can have text generation at scale. And then you have chatbots. We can generate a lot of text. So you give your model a prompt, and it could predict the next token, and you could do text generation at scale.
So you could crank out emails, or write blog posts, or stuff like that. And next, the researchers wrapped that model in a chain of thought reasoning. So it could come up with, it could solve math problems, it can create code, and it can also even part of the bar exam. And now we are at stage three, which are the agents. So at stage three, the model stops talking, and it starts interacting with external systems. So you can automate your workflows, you can file your expenses, you can interact with external systems using a variety of protocols. All right.
So stage three agents, they don't just talk. So they also change the way we interact with the system. So basically, the interface is turning into a conversation. It's more like a conversation. So if you think about your traditional IAM portal, a user signs in, and instead of digging through tens of windows, and which often requires a lot of training as well, so they can simply open up our sidebar, which now hosts a co-pilot, which is basically just a UI for agents. And then they can simply type, OK, let's extend the Alice role by 30 days.
So the co-pilot reads that line, and it can spin up a few specialized assistants, and those agents can interact with external systems while the users simply watch the chat scroll. All right. So user consent is non-negotiable. So before those micro-specialized agents hit any API, or they can talk to an external system, the co-pilot pauses, and it presents a consent card. Why this is necessary? Because you don't want to end up in a situation where agents can go rogue. And so the user has to be in a slope.
So for example, if Alice doesn't tap a lock, nothing moves, there will be no silent overreach, no redisco. And if she approves, we basically lag a short-lived delegation edge, and the agent gets the green light, so they can perform whatever they were supposed to do. So this way, we can give the power in the user's hand, and every step will be audited and record. So once the consent is in place, the agents get to work. So they can extend expiring access, like at 2 a.m., they can freeze risky accounts, they can do a lot of stuff.
So they can run 24-7, and they can basically make decisions in millisecond latency, which is great for users, but if you are operating in a security environment that is stuck for using tokens that is eligible for 30 minutes or 60 minutes, even 60 minutes, then there's going to be a problem. Okay. So as we just saw that our agents can act in milliseconds, but the token they use usually lasts 30 minutes. So if a token leaks, anyone can copy it and use it, and there's no lock, or they are bound to a certain device or network.
So stopping a bad token means waiting or running you need to run end point or you need to invoke certain APIs, you have to subscribe to certain webhooks, which basically operates in a traditional request-response model. So OAuth got us here. Now it's time to, it needs a real-time extension. So for example, if we are implementing authentication for AI agents, many teams opt for client credentials when they just quickly need a quick server-to-server access. It feels simple, you just need an access token and a secret, and you're good to go. But there are certain problems with this approach.
So the first problem is there's no user trail. So you can't really audit who asked what, right? And there are broad scopes, so if any token leaks, the attacker can do everything that the app can. And the tokens are also slow to kill, so they usually have 30 or 60 minute shelf life, and it's harder to kill in real time.
I mean, that model was good for a traditional nightly job or back-end workers that do not interact with users. Okay, so now we have OBO. So OBO was a quick fix to basically switch to, so now you have the user context. So OBO is the biggest gap by stuffing the user ID back into the token. So we finally know who asked what, until you get into the details. So if we go back to our co-pilot example, we have a co-pilot in our IAM portal, and it basically requires users to log in to IDP and the user log in to the IDP, get the OR token, and then the co-pilot needs to swap that token with the IDP.
And if, let's say, that co-pilot requires orchestrating multiple agents, then the OBO chain needs to be repeated again and again. So that's the problem with this model. So bots are exploding in numbers, 80 for one employee, and the problem is no one retires them. The signatures often linger, and you often end up in a situation where you have orphan keys everywhere.
And so, yeah, in my view, non-human identities also need to mimic the same join-mover-leaver process that people have. So that's what happens when you don't expire the token gracefully. So in 2022, attackers grabbed OR tokens issued to Hiroko and Travis CI because they were better tokens, and they were able to clone GitHub repos for hours.
And, yeah, it was quite a nightmare because they were not bound to any device or any session. So they were just bare string, and they were able to replay it on a different network. So this GitHub breach shows the core issue that REST is stateless. So the server can't really tap into the client's shoulders and say, OK, token revoked. You must stop now. So in traditional REST environment, you have to pull for or wait for the token to expire. And that delays exactly where attackers exploit.
So if you want real-time control, we need a channel that lets server pushes a stop message the moment something changed at the server, the risk policy change, or IDP, something like that. So the stop channel already exists. It's called HTTP3 on QUIC. Unlike old REST, TCP, QUIC lets your server push a control frame back to the client. Then it shows up, so it can say, OK, the token has been revoked. You can stop now. And it can reach the token. The revoked frame can reach to the agents in less than 50 milliseconds.
And the same connection stays alive even if you switch your device from Wi-Fi to 5G. Your connection still stays alive because the QUIC is basically the QUIC UDP internet connectivity. So it doesn't use TCP at all. So even though your IP is changed, but your QUIC connection ID will still be the same. So that's why you're able to sustain the reconnection. And it might sound a bit of a very tiny feature, but it's a huge deal for enterprises. So imagine if you are building a web application, or you're having an enterprise, and you don't have to deal with reconnection.
And every time, the IP changes. So this is the protocol HTTP3 and QUIC that I just talked about. So unlike old REST on TCP, it lets you send control frame back to the client. So basically, QUIC gives you the two-way connection that we were missing. We need a token that can travel on it without slowing things down. So that's where the RTE framework comes in. And because in today's world, we are using JWT, which if you compare the payload size, it's huge. And in RTE token, we are just using the 96 bytes and it's binary token. And it's bound to a live QUIC session.
So you can replay that same token to a different network. So in this case, there's no polling. There are no roundtables. You don't have to maintain any secrets. The RTA keeps your IDP and your trust. And it simply replaces the binary token that you use. So this is the high-level design of this RTA framework. So at the center of it, you have RTA server that basically operates on HTTP and QUIC. And you have certain components like k-event listener. So it allows you to listen to various IDP signals. For example, the user is locked out. The session was revoked.
So you can have a listener and it can ingest all the external events into a centralized event bus. And from that event bus, the RTA server is already subscribed to the event bus. And once it gets the signal, it can immediately push all the revoked frame to the connected agent. Let's say if you're working asynchronously, there are 50 agents working in parallel. And all of those agents working on the same, on behalf of the same user. So once they get the token, the token will be immediately revoked in near 10 milliseconds. So this is the overall flow.
So when the user sign in to the portal, they get the IDP, the OAuth token. And then the portal hands over the OAuth token to the co-pilot, which in turn orchestrates new agents. And the agents can exchange that OAuth token for the RTA token. And the RTA server makes sure that when the token exchange is happening, it basically calls an introspection point just to make sure the token is valid. And once the token is valid, it can basically issue a new RTA token that can be revoked in near milliseconds.
So if we see inside under the hood, we have a traditional token header, we have session ID, we have context hash. So the context hash basically allows us to see who, what, and when. So we can store policy, we can store user ID, we can store agent ID, we can have actions, certain actions. For example, if the co-pilot says Alice access was extended for three days, during that time, we can have all that information here.
And also how we are going to demonstrate proof of possession, we are using MTLS, the mutual TLS protocol to identify that the agent is legitimate and is able to communicate with the RTA server. So that's how we can close the MFA gap between human and agents, because humans, we can spin up our MFA app, we have ODP and all that. But agents can type and they don't have any keyboard. But in RTA token, we have a key and with MTLS key and with the live quick connection ID, we can use this combination to basically mimic this multi-factor type of communication. So you have event driven revocation.
So with standard GWT, if you are using a standard GWT, the only way to get fine grained control is to stuff more data into the token. So you would have a long list of scopes, claims, and even the whole arrays. And pretty soon you would end up 8KB limit, the standard header limit. But RTA basically flips that model. So the token stays 96 bytes and it can contain the hash of the last year's decisions, so it contains the last PDP decisions in real time. So you can store information like resource ID, action, risk level, time window, yeah, and all that lives in the PDP.
So the RTA framework also has a component which allows ingesting a webhook using CAPE and standard SSF. So once you have, once it receives the webhook, it immediately dispatches the revoke frames to all the connected agents. All right. So fine grained policies always lives in the PDP. So in context hash, we just define the coarse-grained permission and for the fine-grained permission, we always contact our PDP. So that's the comparison between traditional OR token and the RTA token. So you can see we have, we can have a latency less than 50 milliseconds, so you can make decisions real time.
Whereas in traditional OBO flows, you would have to have multiple round trips involved with each hop. So now you might be wondering, do we really want to bet on HTTP3 and QUIC? So the answer is yes, because the market already has and more than third of the public websites is on already serving HTTP3. That's pretty cloud-free. It's already seen 40% increase in global traffic. And Google search and YouTube also moved to HTTP3 and yeah, Facebook, Instagram, they're also migrating their core services to a QUIC.
So all, and it's supported by all major browsers. So you can have Chrome, add Safari, Firefox.
So, and on top of that, IETF basically sealed the deal by creating a specification back in 2021. So you have specifications like 9,000, RST 9,000, 9,001, and 9,114. So real-time authentication is basically riding the highway. The internet has already paved.
Yeah, and that is, that's a wrap. I'll be happy to take any questions if you might have.
