We’re ready to get started. Welcome everybody to another webinar by Akeyless. And today, we’re going to talk about, scaling and talk about different phases. Whenever I talk about, with a customer or a client about, you know, moving them into using a secret manager, I like to talk about phases in the journey. Right? Because we don’t want to overwhelm anybody with, hey. You’re gonna you’re gonna do everything. Akeyless is a very powerful platform, so we’re gonna take it back to the basics and how to get people, through through these phases. And as we go through these phases, I’d like you to think about yourself yourself, your organization, and where you might land in those phases and how to move forward. So joining me today is Netser Heruty, who’s the director of solutions architecture at Akeyless. This is probably, what, our second or third webinar together, Netser. Yeah. So if you don’t mind introducing yourself. Yeah. Yeah. If you don’t mind introducing yourself, for those who might not have, attended the previous webinars, that would be great. Yeah. Absolutely. So thank you, Sam. And like you said, I’m the director of solutions architecture here. That means I’m actually involved with our customers throughout presale and post sales, and I get to see both, let’s say, the the dream phase where we tell them how secrets management is going to look like and the actual real life implementation where, like you said, we have to gradually actually do the work, get through the steps that we’re about to talk about, and I think it would be very, interesting topic to cover. Just a bit about myself. I’ve been with Akeyless for the last four years, and I’m, looking forward to all the following years. Thank you. Very nice. Thanks, Netzer. And, folks, if you have questions, go ahead and post your questions in the q and a, and we’ll be happy to take them as we go along. A little bit about myself. My name is Sam Gabriel, and I am the founder of Techin8 Solutions. And I am a content creator in the platform engineering space. I have an academy and a few things. I’m really interested in educating folks on anything and everything to do with platform engineering. So let’s go ahead and get started. And, like I said, we have phases. So we’re gonna start with the status quo. That’s phase zero. That’s the very first phase where you’re in a place where you’ve got scattered secrets everywhere everywhere. We’ve got sprawl everywhere. Your secrets might live in the actual code itself. It might live in a version control system. It might be in your pipelines. There’s really no single central source of truth that you have. We’ve seen, secrets for, let’s say, a database being shared among multiple applications for the same, database. So reusing of secrets and credentials, we see the same key in multiple places, even keys being shared among engineers. So we have an amplified blast radius. We want to bring everything into a centralized location. And on top of all this, we now see AI driven workloads, scattered secrets across applications, and across your AI driven workloads themselves. So that’s the status code. This is phase zero, and let’s move on to phase one. But first, before phase one, in case in case somebody here is still skeptical about, you know, secrets management and the the the the the need to have secrets management in the first place, this chart maybe can can, make you a believer. And, you know, research has consistently shown that the compromised credentials are involved in these majority in the majority of these successful security breaches as you see on the screen. And even more concerning, most identity related breaches now involve nonhuman identities rather than human users. And the examples that you see here highlight a pattern that security teams tend to see repeatedly and that, you know, API keys exposed in public repos, service account credentials stolen by third party vendors, OAuth tokens abused after, compromised, long lived access keys that never get rotated, overprivileged applications, the and automation systems withstanding access to critical resources. And as you can see in recent years, several high profile incidents demonstrated how damaging these weaknesses can be. An example here is the Okta breach that led to downstream compromises of customer environments. Cloudflare disclosed a significant intrusion that leverage credentials connected to that incident. Other breaches involved exposed cloud access keys, leaked API credentials, and compromised third party integrations. And now to top it off, we got the rise of AI, and I think Netser might have a a quick story about that as well. I think that last one that you see here, Pocket OS, is, an interesting combination, though. It’s no longer just about machine identities that do what they’re told, but then they need to be well governed in terms of how they manage their secrets, in terms of where you keep them, making sure they’re regularly rotated, etcetera. It’s also about the potential damage of just letting those new actors, the AI agents, use your secrets without discretion, potentially. Right? When in this case, there was an overprivileged AI tool that was requested to do one thing, interpreted it rather differently. And, actually, instead of going ahead and cleaning up some test data from a database, it interpreted it as go ahead and wipe out the database and actually caused a full blown outage to the company that took them, I believe, a couple of days to actually restore and and resolve because it just deleted the data. So, obviously, those the fact that AI agents have access to your secrets is now a new almost like an internal threat. And the fact that a potentially, this is another side of the same like, the the flip side of the of the same coin. Right? The the fact that even when you do properly secure and govern your secrets, you still need to be very worried in term of who can access them and what can they do with them. And this will also fit into our greater story in terms of how you climb those steps. Yeah. Exactly. I I like that. And I think we’re gonna talk about the intent. So it it moves Yeah. Moved past just secrets, but it it actually touches on the intent of that agent as well. So yeah. Excellent. Alright. So first phase, this is typically where I see a lot of organizations, you know, land, and, unfortunately, many of them stay here. So we’re gonna talk about this first and then see how we can move from here. So this is where we wanna centralize. Remember we had all the secrets are scattered all over the place, no visibility, no audit trail. We wanna have a secrets management solution like Akeyless to centralize all our secrets in one place, making it the single source of truth for all our secrets with a full audit trail and full visibility. So that’s the goal. And what you gain from this, like I said, this whole idea of visibility, audit trail, source of truth in one place. But what remains is that we still have standing credentials that still exist. Remember, these are static secrets that have a long life. Breach window is still open. Access doesn’t expire automatically. Right? So this is a great step moving forward from from the sprawl, but we can do better. Right? So next phase, this is, the auto rotation phase where we want to automate periodic rotation of credentials and API keys. What you gain from this phase is automated credential rotation. You significantly reduce your exposure window and improved compliance and auditability. Alright? So now we we wanna move away from those static secrets that have a long lifespan and, on a regular basis, automate the the rotation of these credentials rather than getting humans to manually go in and rotate these secrets again at scale, it’s unmanageable. We we really need to automate this process. So that’s phase two, and in this phase, what remains still is some long lived secrets still exist within the system. Standing access is not completely eliminated, they’re only refreshed, and then a breach window reduced but not closed. So what we mean by that is that, again, depending on how you’ve how much time you’ve put in place to automate the rotation of these secrets, it could be a day, then that day for that period of time, you still have a a a secret that lives during that time. Netser, I don’t if you wanna say anything here or add anything. Yeah. Sure. We we often look at these as these are entitlements or or standing privileges. The secret changes, that’s significantly better than the static approach, obviously. But you still have the same identity with the same grants or permissions or entitlements that make up this identity as a static identity and potentially a threat. While this, obviously, is a great stepping stone to our to the next phase, I will say, realistically, I believe most companies and organizations that I work with are somewhere around this bridge from step one to this phase to the second phase, especially because of compliance and regulations that are mainly focused on making sure you have rotation in place. It used to be talking about, you know, a yearly rotation that would suffice to check the box, and it would be, you know, infrequent enough for people to do this manually, have a change window, do some like, a maintenance window and a change request, and, you know, take take take the chance, essentially. But with actually, the compliances now are looking into narrower, like, shorter lifespans for these rotations, talking about ninety days in some aspect, forty seven days for certificate renewals, which is a similar but slightly different aspect. But the shorter these become, it’s no longer practical to rely on manual approaches or rotation. Right? So this automatic rotation is already a significant advantage to where many, many companies are today. But, of course, keeping your your you know, keeping an eye on the future and what you should be preparing for as prefer preparing for, especially with AI, I think the next one would be very interesting. Thanks for that, Netser. Yeah. So, phase three is dynamic or zero standing privileges and just in time access. So like we said, centralizing isn’t enough. It’s still standing access where now we wanna move towards a just in time credential that gets generated the moment it’s needed. So it doesn’t exist prior to that, but when the application needs it, when the human that’s accessing Akeyless needs it, that credential gets generated at that point in time. It’s scoped and also auto expiring. It has a time to live, and after that time, it’s it disappears. It no longer exists. And whenever the application, whenever the user, whenever the pipeline needs it in the future, then it will generate a new credential. So, again, there is there’s no standing there’s zero standing privileges, no persistent access that remains at this point. Cool. That takes us to the next phase, and this phase is when we like to talk about platforms that provide identity to the resources that they spin. So, for example, Kubernetes, it spins up pods, right, as, you know, part of a deployment and so on. And there’s a service account in there, And that service account basically can be tied into your application. And through a mechanism where we can tie your Akeyless to Kubernetes as a platform, we can allow the application to automatically be authenticated into into Akeyless without having to provide a credential to Akeyless. So this is really solving a secret zero problem where it’s a bootstrap problem. Where do you start? Where’s the first secret that you introduce? Because you need a secret to access Akeyless and then from that point on you can get the actual secrets you need for, let’s say, a database and so on. So at this stage, we really need to think about where the applications live. Do they live in a platform like Kubernetes or like a cloud platform, AWS, GCP, Azure, where we can leverage these platforms that provide a fingerprint or an identity to the resources that they spin up. And if your application happens to live in one of those resources, then they can automatically get authenticated into, into your secrets management, platform like Akeyless. So this is another phase where it’s basically secret less authentication. And that’s where I see you you went off mute. You probably wanna say something, so go ahead. You you know me so well. Yeah. Secretless is the should be the de facto standard everywhere possible. Regardless of the the secrets management solution like Akeyless, many platforms that companies are using allow secretless I’m native authentication in house within their own platform. So within AWS, two different resources can talk to each other based on their own IAM role. Within Kubernetes, the two different service accounts can do the same. These are all secretless flows, and these should be adopted across the board. The problem really begins more where you’re working, like, across domains when your AWS resource needs to talk to a maybe an on prem OpenShift Kubernetes environment or some cross cloud communication. And that’s where trying to tie all those workloads to trust each other, to talk to each other becomes cumbersome. It’s hard. It’s and it’s, repetitive in in a bad way. Like, you’d have to repeat the same procedure multiple times to actually achieve something remotely trustworthy. Whereas putting this platform in the middle, something like Akeyless that could allow each of those respective applications to authenticate to Akeyless itself natively secret list and then be provisioned with one of the previously offered secrets, the static, dynamic, rotated. Ideally, dynamic is you know, when possible, it’s ideal. That would get you all the way through and also add the advantages of the auditing, just being there in a central location, governing for all of those interconnections across the board. Perfect. Yeah. I love that thought. Cross clouds. And the more and more I talk to customers, the more and more I see that almost everybody is a multi cloud plus private cloud on on prem. So Yep. But even for the, you know, for the single clouds, it’s just maybe last bit is they may still have their SaaS application. They may still have even their own self deployed app apps running, maybe hosted on a cloud, but not necessarily through an app that knows how to leverage the layer of the I’m of the underlying I’m, and they need to authenticate to the app running on an e c two potentially, but it doesn’t mean it supports the native authentication. Right? So these there are all these problems. All only, like, the very specific managed services could allow you those things, and even those are relatively new. Right. Right. Yes. Excellent. And this takes us to phase five, the agentic experience or enterprise, where AI agents are autonomous actors now, not just workloads. Identity alone is not enough. And this is the intent aware access. So when I’m using, let’s say, Claude or Codex, and it’s no it’s not just what I, as a human, intend to achieve. The, the the agent itself might actually reach out and do something a little bit different, which is interesting. So, for example, if I’m if I if I ask Claude something about my infrastructure, Claude might actually go out and reach out to different other pieces in the environment to kind of get an understanding to answer my question. And similar to what Netzer talked about earlier about that breach with Pocket. Right? So it actually the the AI agent itself might have a different intent from what I had. So this is where Agentic runtime authority and we’re not gonna spend too much time here, but if you find this interesting, I’d love to to hear your thoughts in in the questions and answers or even in the comments because we’re we’re planning on doing a webinar on this as well, where AgenTic runtime authority is very necessary, and it’s kind of like a gate two way gate because when the request comes in, that’s my intent, that’s the agent’s intent, Akeyless needs to look at that request to see if it’s supposed to happen. And then on the way back through the response, it needs to also take a look and see if that response should come back. Right? So I don’t wanna spend too much time here. I don’t know if, Netzer, you wanna briefly share something around this. Very brief. It’s the last bit. It’s actually it’s the secretless aspect because you talked about applying different policies to the actual runtime. Even if you look at the simplest value proposition here, it’s it’s this. AI agents shouldn’t be exposed to secrets. If you thought machine identities shouldn’t be exposed to secrets and they should be used at one time, AI agents definitely shouldn’t because they could actually take action spontaneously to an extent and do things you’re not expecting. So the fact that we can keep them secretless entirely both based on the authentication that we discussed in the previous phase. But, also, when they actually need the secrets, we’re not gonna give it to them directly. It’s going to be performed for them. You’ll you’ll hear more about that in that dedicated webinar. That’s the real, I think, secret sauce, the fact that they’re just not exposed to any secrets. That’s the goal. Love it. Love it. And all this, just like Netzer mentioned, this all stands on phase four. The you know? So the workload identity federation, that’s synchronous auth that we’re talking about. Cool. Now you might have this question in your head. You’re like, okay. This is all cool, Sam and Netzer, but, like, what does this mean? Do I need to change my the way I’m building my applications? How do I start? Where do I start from? So I wanna put you at ease in a sense. So, because I see this a lot. You know, the biggest fears in in this is disruption, but the good news news is that you don’t have to rewrite your applications to eliminate static secrets. Again, depending on your application, depending on your situation, but for the most part, you won’t need a full application rewrite. Your apps keep consuming secrets the same way they always have. The modernization here happens beneath the surface in the secrets platform itself and in the delivery mechanism of these secrets. The second point I wanna mention here is keeping your existing consumption patterns. So if your consumption pattern is the application consumes, let’s say, a Kubernetes secret, their app reads from that same place, but what changes is how that secret gets there in the first place and how long it gets to live there. And then thirdly, prioritizing risks. So when we’re looking at, you know, onboarding, first of all, you wanna break this down by teams, by applications. But, one thing to note, convert the highest risk credentials first, database passwords, cloud admin keys, shared service accounts. These are the highest value targets for your early migration, so think in that, in that regard. Okay. So this takes us to our demo for today. And for today, I’ve got an application, one app, one database. We’re gonna go through the these four phases. Phase zero, where I see this quite a lot, hard coded password inside of the application itself, maybe even packaged inside the the Docker container. And then phase one, we’re going to use a static secret inside of Akeyless, and application’s gonna consume that secret. Phase two, we’re gonna see how we can rotate that credential on a regular basis. It’s actually set for every day to rotate, but, I’m gonna manually rotate it for us so we can see it live. And then phase three, this is the secret authentication where we’re going to, so far in phase one and phase two, we’re using an API authentication method for the application to authenticate into Akeyless to retrieve the database secret. But in phase three, we’re actually gonna leverage the Kubernetes authentication method in Akeyless using a service account that the application can can leverage, and you won’t see any kind of secret whatsoever to be able to log in to Akeyless. Okay? So, like I said, one database. It’s a MySQL database. One application. It’s a simple Flask Python application, and we’ll go through all phases, here live. Once again, if you have any questions along the way, please post them in the q and a, and we will, address them as we go along. Alright. So I’ve got four tabs here, and every one of these tabs is the actual application. Right? So this is a Flask application. This is actually live. If I refresh here, this should refresh, and you can see the connection ID is incrementing. So I’m not cheating here. This is not a static site. This is an actual application running. And phase zero, as you can see here, this is a hard coded configuration. The auth method, not applicable because we’re it’s not authenticating into Akeyless or anywhere, and the credential lifetime is indefinite. The database password, as you can see here, it’s right here. It’s hard coded in the application. If we have time, I can show you the application itself. And, what else? The database user for this instance, we kept it simple, just root. Of course, you wouldn’t do it that way. You’ll have an actual user for the database. And the database time here, you can see that this is every time I refresh, the time changes as you can see here. So that’s the first phase. Second phase here, I’ve got it running on another port, the same application, and this is where we’re centralizing the the key. It’s a static key that lives in Akyless, and the application is requesting this key. The auth method is an API key into Akeyless, and, we’re fetching every request just for the demo. The credential lifetime is indefinite unless somebody goes in manually and changes or rotates that secret. It’s gonna stay there forever. And, what else? The database password, we we kept it the same. And, again, same user in here and database time. Again, if I refresh this, this this changes, so it’s live. Phase two here is where we’re actually going to be rotating our secret, or this is actually set up to rotate every day in Akeyless, but I’m gonna rotate it here manually so we can see it. So in this case, a rotated credential was fetched once at launch using API key authentication. It remains unchanged until the pod restarts. So, basically, we’re caching it, and, actually, the application doesn’t need that credential. It just needs it on on on start time. And the authentication into Akeyless is API key again, and it’s a rotated secret. Here’s the database password, and here is the database user. Okay. And once again, I keep refreshing this. You can see it’s live. What I’ll do now is I’ll jump into Akeyless. And right in Akeyless under items, you can see this is the rotated secret, and this is the current secret. I think it should be the same here. Ends in n u d n u d. So what I’ll do is I’m gonna rotate this live. But if you look at the rotation configuration, you can see that we have this rotating every one day at eight o’clock in the morning, and we have different configuration that you can put in place. Versions, you can see this has been rotating over forty times as I’m practicing this demo and so on. But let’s go ahead and rotate the secret here. Secret rotated. Let’s take a look and see what the value is right now. It ends in m c p k eight. Let’s go back here. Refresh this. Give it a second. And here we go. M c p k eight. So the application, what happens is behind the scenes real quick is I have a very small utility that I wrote, so that it’s not specific to Kubernetes if you’re running this in a VM. What this does, it will it talks to Akeyless, on a regular basis. It finds if the the finds out if the secret has rotated, and then it restarts the pod. And then that comes up with a new, rotated secret. So you can use this utility again in Kubernetes. You can use it outside of Kubernetes in a VM, for example. So that’s phase two, the rotation. And then the last phase here is the secret list authentication phase, and this is where we’re using a Kubernetes service account inside the application. So rotated credential was fetched once at processed start startup using Kubernetes workload identity. It remains unchanged until the pod restarts. Let me just control r here, refresh. This will go ahead and show me the latest secret that we just retrieved. So it’s exact same secret that we saw rotating. And this is using a Kubernetes service account, so there’s absolutely no, credential that is sitting inside the application to log in to Akeyless. It’s using the Kubernetes service account. And, same same process as as the previous phase for the rotated secret, it only, gets that secret upon pod restart, and you can see the database user as well and the time, the connection ID, and all of that. Now real quick, I wanna take us back to Akeyless. And here in Akeyless, we showed you the actual rotated secret here that where it lives. And here is the static secret for phase one. So we we kept it here just for you to see. So this is where the application goes in in phase one, retrieves that status secret, but it’s long lived. And the other piece I wanna show you is the authentication mechanism. And over here, we’ve got the static API key that we’re using in phases one and two, and this is where it’s it’s just a a static key that is stored in the application to authenticate into, into Akeyless, which we don’t wanna do. Right? We don’t wanna have a secret that sits there for a long time. I mean, what’s the point? It’s like having that database secret sitting there for a long time. Right? So we wanna move towards a, a platform identity. In this case, the Kubernetes identity here, you can see we’ve have we have the configuration for for that setup as part of the Akeyless gateway, and that’s what enables the application using its own service account to automatically be authenticated into Akeyless. Now all of that is associated with roles, and this is the authorization mechanism. What is the application able to do inside of Akeyless? You can see that we have two authentication methods tied to this role, the Kubernetes one and the API key. And the rules in here, it’s basically allowed to read and list inside of the webinar demo. This is this is for an old demo, but this is what’s relevant for our demo here. So notice the permissions are only read and list, so we’re very specific as to the actions that are allowed to be taken by the application. Anything you wanna add here, Netzer? Yes. So the thing I liked about the phases is that they’re rather realistic to real life implementations with customers. People often wanna get started with something quick and rather easy that just works, and that would do it with a static credential and an API key. But then you have to think back to why have you purchased a secrets management platform? Why are you here? What are you trying to achieve? And that should allow you to quickly understand what I need to be doing is move on to phase two and phase three to get to where you really wanted to go, to go secret list. That’s the point. If you’re half doing it, you’re getting some value. No doubt. Right? It will be audited. You can still restrict certain access, principle of list privilege. There is value to it. But if you wanna go and really take advantage of this platform properly, that’s the way to go. You need to neutralize the the way in from the off method to work secretless, and you need the secret that you’re there that you’re getting into Akeyless in order to obtain it. That secret should also be nonstatic. Rotated is per is great. Dynamic is even better. But you should keep in mind that you want control. Right? As as someone who has this platform, you want also to be able to potentially say, oh, this secret, right, the one Sam just showed us from the rotated secret, we can all now consider it as compromised because a bunch of us here are seeing it live. Right? And if someone is quick enough to get into Sam’s environment, you could attempt to break this application down, do whatever. The fact that he can now click a button or have it done on a schedule or through an API, doesn’t matter, gives him back a sense of control to know that even if he were he was compromised, he can do something about it rather than be it, like, a sitting duck and wait or or have to do a manual change that could break production systems, etcetera. That’s, I think, the the the key. Yep. Excellent. Excellent. Excellent. I think we have a question here. I don’t know if you see it by Ryan. He’s saying in phase three, you still have a database password. Can you talk about how Akeyless could replace having the database password also serviced from Akeyless? So no passwords or keys in the code. It’s a good question. It all comes down to the target. So I’m aware of maybe a couple of database services that are more advanced and offer more advanced types of authentication. Forget about the keys for a second. The question is which or whether this database itself allows you to authenticate to it using something other than a username password. So I know I I believe I hope I’m not wrong. MongoDB Atlas has, like, an OIDC, more native authentication or or sorry. Like, a modern authentication flow, in which case you could provision, an OAuth token just in time rather than a password. But there would always be a form of credential even if it’s short lived. Right? Even, like, through a dynamic secret or an OAuth token that is typically around the sixty minutes TTL, you’d have to supply the app with a form of credential or or a secret to talk to the target. Otherwise, the only, like, the only way it’s not required if if they are under the same roof or under the same issuer, like I mentioned before, two different workloads on AWS that could natively talk to each other. They don’t actually need to go through Akeyless. That’s the that’s the honest truth. But for the most part, you need that. Right. Did I answer you, Ryan? Is that a I don’t know if you can yeah. Actually, I don’t know how you can acknowledge it. I think, yeah, maybe in another question. Yes. Yes. Okay. Thank you. Excellent. Any, any other questions? I’m not sure if it’s worth going through the actual application code itself. It might be too much. We can actually show you the the Kubernetes cluster if that’s at all helpful. So, we’ve got, let’s just look at the pause. I just have it running here. So we got the two the four phases right here running. Here’s this rotation watcher that I built that, again, watches, I think, every I don’t know when I put it, five seconds or something goes. And the RotationWatcher itself is leveraging its own, its own Kubernetes service account to talk to Akeyless. So there’s no there is no a key there’s no static credential here to access Akeyless as well, right, similar to the application. Do we do we have do we have something like that? I think we do. Akeyless has maybe a utility that helps us with that. I’m The injector. The injector. Right? Yeah. I didn’t want but the injector is for Kubernetes. I didn’t want to be too specific with Kubernetes. Yeah. No. The the that’s very right to point out that Akeyless, being API driven, we operate from the client side perspective in terms of plug ins. We offer a way of integrating from almost any level. So it could be bound to the orchestration platform like Kubernetes, in which case it would be Kubernetes specific using something like our injector or secrets operator or a CSI driver. There are different options there. But it could also be at the app level, leveraging something like an SDK or a, like, a wrapping script, something you want to make very, very specific. May some apps have their own internal, like, native secret manager, external vaults, external secrets that they support, and we are just sort of becoming a native provider there. So you have the diff like, different where different places where you can fit in. And then any platform that supports code, be it in, like, writing REST API calls or commands or CLI, there’s always a way in from from some level. Yeah. But I I like the a bit more agnostic approach that you’ve taken that would allow this to work wherever you deploy it. Right. Right. Any other questions? Let’s see here. I will say maybe about the rotation watcher you have here. It actually makes me think about how the the injector part specifically. It has I I think what is what would be better about using that just to to share share my thoughts is it has a way of actually alerting the dependent apps or the deployments or telling them their secret has changed, and they need to perform a, like, a graceful rollout restart. Right? So because oftentimes apps consume secrets through environment variables, and those can’t change on the fly. I’m assuming whatever you’ve done here with your internal SDK or or something of that sort is more advanced. It’s where you get to control the application and tell it to watch a file for changes or something along those lines. But oftentimes, app app teams just deploy an app that they didn’t necessarily write. It can’t really change, and they need to work with what they got. And, typically, the way in for secrets are environment variables. That’s the most common practice, and those can’t change at runtime. You’d have to restart. So the injector, like, bridges that gap. We’re able to notice that, oh, a secret has changed. We need to alert the app that uses it that it needs to restart. But with Kubernetes, it’s graceful. It’s done it’s done in a rollout phase that first creates the new pods and then terminates the old ones so that you maintain the same availability. Yeah. It’s the same. Yeah. It it does a rollout, for the deployment and and builds it that way. So yeah. Could you share, oh, we got a couple one more here. Let’s see. Could you share more on intent aware permissions authoring and how it’s used during execution for enforcement? Oh. Great question for our for the for the AI. Yes. So there’s interest in in the, in a webinar on that, so that’s good. Yeah. Maybe I’ll give you a Sleek. Teaser. Yeah. Something along those lines. You can envision that’s we have a component in Akeyless called the gateway. The gateway actually is going to be able to it’s, anyway, a piece is very central to our architecture because it is able to perform those dynamic secret creation against the targets or rotate the credentials against the targets. It also has the ability to obtain a fragment of the encryption key that keeps you safe from us. It has a lot of value, generally. And then on top of all of that, that same gateway is now also able to intercept agent request or prompts actually going out through MCPs or to diff to various targets and actually stop the agent at the gate telling it, wait. I’ll I’ll do it. I’ll do it on your behalf. And then rather than just obtaining a secret for it and then letting it see the secret and use it independently, it does what the agent wanted to do against a target, allowing it to both keep the agent completely in the dark and not have any clue what the secret was never being exposed to the secret, but also apply policies. You’d be able to say if this is, for example, connecting to a database where you have sensitive data and you wanna make sure that that data would would not be exposed at all to the agent, you can explicitly say in in free text, when using this secret through this runtime authority solution, don’t expose PII information from that database. Right? So that’s a very, very quick quick way to try to round it all up, but I will say maybe from another angle, it it feels like Akeyless has built for years all the building blocks and modules required for the AI era, dynamic credentials, secret less authentication, the ability to actually govern access all the way, right, end to end. We’ve been always telling customers, like, they’d they’d have to often think where could they they use all of that. Right? Like, where is it where is there a good fit for all this just in time identity security secret list? And then came AI agents, and now it’s suddenly clear. Everyone has them. Everyone lets them access their secrets, and everyone shouldn’t. Everyone should be able to give them this secretless path end to end. Yeah. I saw this recently. I have a you know, agentic runtime authority. It’s pretty cool. It’s not on my plan yet, so maybe I’ll ask Maybe I can hook you up. Yeah. Hook me up. It’s pretty exciting. I know a guy. There you go. Cool. Any other questions, folks? Alright. Well, as usual, the the code is going this this is gonna be a part of a blog post as well, and we’ll have the the code for for this demo there. If you’re interested in digging deeper and looking at the actual application code, happy to do to we’ll make that available to you. And if there are no more questions, I think we can, wrap it up. Going once, twice,
