Identity Security

Unleashed For The AI Era

Discover What’s Next in Identity Security

Modern enterprises now manage identities across humans, machines, and increasingly AI agents. As agentic AI gains traction, these systems bring new access patterns and new risks.

Fragmented tools cannot keep pace. Organizations need a modern identity approach that supports the realities of AI-driven environments.

Identity Security: Unleashed for the AI Era is a limited series from Akeyless examining how to extend protection to AI agents while strengthening identity security overall. Hear expert perspectives, see real-world examples, and learn what it takes to secure identity in the age of AI.

Discover What’s Next in Identity Security

Modern enterprises now manage identities across humans, machines, and increasingly AI agents. As agentic AI gains traction, these systems bring new access patterns and new risks.

Fragmented tools cannot keep pace. Organizations need a modern identity approach that supports the realities of AI-driven environments.

Identity Security: Unleashed for the AI Era is a limited series from Akeyless examining how to extend protection to AI agents while strengthening identity security overall. Hear expert perspectives, see real-world examples, and learn what it takes to secure identity in the age of AI.

What You Can Expect

Discover

Learn why the AI era demands a new identity paradigm. Hear how leading organizations are rethinking trust, automation, and control in an AI-driven world.

Apply

Walk away with practical strategies to simplify access and modernize identity security for the next generation of AI-powered systems.

Episode 7 - Managing the Full Lifecycle of
Non-Human Identities

The Lifecycle Directive | Managing the Full Lifecycle of Non-Human Identities

Non-human identities, like workloads, applications, containers, and machines, now outnumber human identities in every modern environment. But unlike users, these identities are often created automatically, spread across cloud and hybrid infrastructure, and rarely tracked from start to finish.

In this episode of The Lifecycle Directive, we’ll explore how to manage non-human identities across their full lifecycle, from creation and onboarding, to rotation, monitoring, and retirement. You’ll see how Akeyless helps security and platform teams reduce risk, maintain control, and prevent credential sprawl at scale.

Why Attend

As non-human identities continue to grow rapidly, manual tracking and fragmented tools create blind spots, misconfigurations, and security gaps. This session will show how Akeyless helps teams centralize lifecycle management, improve security posture, and automate key processes to stay compliant and reduce operational burden.

Highlights that you’ll see:

Managing non-human identities from creation through retirement
Centralized visibility into non-human identity inventory and lifecycle status
Automated rotation and lifecycle enforcement to reduce credential risk

Speakers:

Oded Hareven
CEO & Co-Founder, Akeyless

Dr. Conor Mancone
Principal Application Security Engineer, Akeyless

Oded Hareven
CEO & Co-Founder, Akeyless

Episodes

Speakers

Oded Hareven

Co-Founder and CEO, Akeyless

info

Oded, a veteran of the IDF Cyber-Security elite unit, specializes in Identity and Access Management technologies and has held various senior product and project management positions in both enterprise organizations and startups. Among his previous roles were Director of Product Management at Moovit (acquired by Intel) and Senior Project Manager at CA Technologies. Oded holds a BA in Management & Economics from the Open University of Israel.

Oded Hareven

Co-Founder and CEO, Akeyless

close
Admiral Mike Rogers

Former NSA Director

info

Admiral Mike Rogers retired from the U.S. Navy in June 2018 after 37 years of naval service rising to the rank of four-star admiral. He culminated his career with a four-year tour as Commander, U.S. Cyber Command and Director, National Security Agency. During his service in uniform, Admiral Rogers held positions afloat and ashore around the globe focusing on cyber, intelligence, maritime operations and national security.

Admiral Mike Rogers

Former NSA Director

close
Richard Barretto

CISO, Progress

info

Richard Barretto serves as Chief Information Security Officer (CISO) at Progress a software company that provides high impact software for 1700+ software companies and 3.5 million developers. Richard leads all aspects of Progress’ enterprise cybersecurity practice, delivering the vision and strategy, and governance against a churning landscape of digital threats.

Richard Barretto

CISO, Progress

close
James Azar

CISO, Artera Services

info

James Azar is a cybersecurity practitioner with over two decades of experience in Data security, Privacy, Geo-Politics and cybercrime. James has been featured on Fox, OANN, NBC, AJC and other publications.

James Azar

CISO, Artera Services

close
Nibin Philip

Head of Information & Cyber Security, STP Nuclear Operating Company

info

Strategic cybersecurity executive with expertise in building enterprise-wide security programs that protect critical assets, mitigate risk, and enable business operations.

Nibin Philip

Head of Information & Cyber Security, STP Nuclear Operating Company

close
Shaul Eldar

CISO, Wix

info

Shaul Eldar, CISSP, is an experienced professional in the field of information security, currently serving as the Head of Infrastructure Information Security at Wix. Previously, Shaul held the position of Director Information Security at Amdocs and has also worked as CISO and risk analyst at CYMOTIVE Technologies.

Shaul Eldar

CISO, Wix

close
Todd Moore

Global VP Data Security Products, Thales

info

Todd leads the strategy for enterprise data protection solutions at Thales. He has a deep understanding of security challenges and technologies within the defense industry, and regularly develops strategies for new product development and execution, as well as negotiating strategic relationships and alliances.

Todd Moore

Global VP Data Security Products, Thales

close
Lalit Choda

Founder, NHIM

info

With 25+ years of experience, Lalit Choda is a pioneering figure in Non-Human Identity (NHI) Risk Management and the Founder & CEO of NHI Mgmt Group. His expertise in identity security, risk mitigation, and strategic consulting has helped global financial institutions to build resilient and scalable systems.

Lalit Choda

Founder, NHIM

close
Eric Fourrier

Co-Founder & CEO, GitGuardian

info

Eric co-founded GitGuardian, a rapidly growing cybersecurity startup that is dedicated to helping businesses protect their SDLC and software supply chain.

Eric Fourrier

Co-Founder & CEO, GitGuardian

close
Suresh Sathyamurthy

CMO, Akeyless

info

Suresh Sathyamurthy

CMO, Akeyless

close

Episode List

Episode 1

Identity, Intelligence & the Agents Among Us | Keynote: Identity Security for the AI Era

AI agents are exploding across the enterprise, bringing both power and peril to identity security. Oded Hareven maps the new rules for securing non-human identities, then sits down with Admiral Mike Rogers for a candid conversation on how AI is reshaping offense, defense, and security strategy. Dr. Conor Mancone follows with a live demo of Akeyless AI Agent Security.

Special Guest: Admiral Mike Rogers, Former NSA Director

Episode 2

The Fast & the Federated | The Evolution of Secrets Management to Secretless

Secrets management is evolving fast; from static vaults to secretless, federated access at runtime. Hear how security leaders are rethinking access to deliver spee, agility, and control across every environment.

Special Guests:

Richard Barretto, CISO,Progress
Nibin Philip, Head of Information and Cyber Security, STP Nuclear Operating Company
James Azar, CISO, Artera Services

Episode 3

Vaults of the Multicloud | Unified Governance Across Every Vault

A look at how Multi-Vault Governance brings visibility and policy control to any vault—cloud, hybrid, or on-prem—without breaking existing systems.

Episode 4

Chain of Trust| Automating the Certificate Lifecycle

Track the entire life of a certificate, from issuance to automated renewal. Featuring real-world examples of how enterprises use Akeyless CLM to strengthen trust and simplify compliance.

Episode 5

Mission: Accessible| Modern PAM for the Cloud Era

Inside the modern PAM model built for the cloud era. Discover how teams are replacing VPNs and static credentials with secure, just-in-time access that actually speeds up work.

Special Guest: Shauli Eldar, CISO, Wix

Episode 6

For Your Keys Only| AI Data Encryption & Key Management

AI-ready encryption and key management, powered by Akeyless + Thales. Learn how to keep every key, fragment, and secret protected and always under your control.

Special Guest: Todd Moore, SVP Products,Thales

Episode 7

The Lifecycle Directive| Managing the Full Lifecycle of Non-Human Identities

Managing non-human identities from creation to retirement. Plus preview Akeyless AI Insights, the intelligent assistant that helps uncover and remediate risks in real time.

Special Guests:

Eric Fourrier, CEO, GitGuardian
Lalit Choda, Founder, Non-Human Identity Management Group

Access All Episodes

Episode 1: Identity, Intelligence & the Agents Among Us

Welcome to Identity Security, unleashed for the AI era. Today, we'll be kicking off our series of sessions, which will feature industry thought leaders and practitioners, as well as technologists from Achilles who will showcase the innovations. I am very happy to have you with us today. This is an exciting moment. AI is changing the enterprise faster than any technology before it and that creates a powerful opportunity for IAM

and cybersecurity leaders. This is your moment to become enablers and accelerators of your business by leading secure adoption of AI agents across your organization. We have some exciting news to share today, But first, let me briefly introduce Akeyless. Akeyless secures billions of machine identity interactions from cloud workloads connecting to database services,

Kubernetes containers calling API servers and micro functions, or even IoT point of sale endpoints communicating with data centers. Within each of these interactions, machine to machine authentication and authorization is made possible by using Achilles to serve the secrets: tokens, credentials, certificates or keys.

Serving well over two hundred billion machine identities interactions this year alone, the Achilles Unified Secrets and Machine Identity Platform has achieved over five sixty percent annual growth in just four years. This is all thanks to our customers, partners and investors. Achilles is trusted by some of the world's biggest

enterprises, including top US retailers, international financial services, the largest pharma companies, as well as innovative tech giants. We deliver our highly resilient and scalable cloud native service using the backbone of the largest hyperscalers. Our dedication to customer success has earned top ratings and awards for innovation, product excellence and support. These qualities have been consistently recognized by

leading industry analysts who identify Achilles as a true innovator and leader in secrets and machine identity management. We've built an extensive global partner network of technology, services and channel partners that help us deliver to customers around the world. We are proud to be backed by leading cybersecurity investors, including Deutsche Bank, who share our vision for redefining how organizations secure

identities across every environment. All that brought us to having ninety one percent of our customers choose Achilles over large cybersecurity and infrastructure vendors. The reasons are rooted in our ground up unified platform designed to simplify and secure every aspect of secrets and machine identity management. The platform provides broad integrated functionality

combining secrets management, PKI, privileged access management and key management systems. Our hybrid SaaS model lets organizations deploy fast and scale effortlessly. At its core, the model is enabled by our innovative trust model, the Achilles DFC, which ensures that neither Achilles nor any other third party is able to disclose the customer's secrets. The result is an extreme operational efficiency and cost

savings of up to seventy percent compared to our competitors. Now, getting back to why we are here today. The rise of agentic AI creates new security risks. But what does that mean for identity security? Let's explore a few identity related critical concerns that define this new paradigm. First, AI agents are expected to increase in volume, scale and complexity, outnumbering human identities

in greater ratios that we have never seen before, not even when we dealt with machine or workload identities. Agents are expected to create far more connectivity between humans, machines as well as agent to agent interactions. Each of those interactions require authentication, meaning far more secrets, credentials and certificates will be used.

This trend will increase the effort required to build and maintain highly available identity providers and secrets management systems. Second, unlike traditional machines or applications, AI agents are aware of their identities and secrets, and therefore are able to expose them. In recent example shown in Black Hat, researchers have poisoned ChatGPT connectors to

retrieve API keys and secrets using a malicious prompt embedded in a document. This is very different than what we have seen when dealing with more simple machine identities attacks. This time, it is not just a code repo that was exposed by a human error like happened in xAI rather than abusing agents and LLM models to make them expose authentication secrets.

In order to solve this major risk, our future solutions must adopt just in time and zero standing privileges concepts by issuing temporary identities that are valid only for the time being used. Simply put, password rotation is not enough any longer. Secretless methods are the future. Finally, in many implementations, AI agents' architecture will require cross domains authentication.

For example, when a certain on prem application wishes to connect to cloud application, they don't share the same trust domain, which end up many times with the bad practices of static authentication. When it comes to AI, many companies will consume LLM from a certain service or cloud provider, while the LLM will eventually require access to the data in other environments such as on prem or a different cloud provider. Each of those domains uses different IAM systems.

Future solutions are required to secure such federation as well as support the great variety of ways to authenticate. The AI agent security challenges that we just discussed is what industry analysts are also seeing. In a recent IAM report, Gartner indicated that AI agents need to not just interact with users to serve their requests but also access resources across environments, legacy systems

and other internal and external AI agents. The core requirement to make this possible is two things: credential management and identity provider. In addition, Gartner also highlights the importance of oversight and audit capabilities. Without that structure, these agentic systems become impossible to govern and easy to exploit. Now that you have a good understanding of the challenges

related to AI agents and the requirements, let's talk about solutions. Today, we are announcing our AI agent security capabilities in our Identity Security Platform. Akeyless AI Agent Security is purpose built to protect the way AI agents authenticate, connect and operate. It introduces a new identity model designed for autonomous, ephemeral and dynamic workloads.

The first pillar is Secretless AI. We enable the removal of secrets from the agent's code entirely. Instead, secrets are dynamically created and retrieved in real time only when needed. No hard coded secrets, no secret zero, no static exposure. The AI agent gets temporary access, perform its tasks and then access disappears. It's simple and secure.

The second AI agent identity provider is the authentication and authorization layer. This brings true identity and access control to AI agents. We create ephemeral access, just in time tokens that are used once and instantly terminated. We also enable identity federation across clouds, workloads and platforms so AI agents can authenticate anywhere securely.

We support both modern protocol like SPIFI SPIRE, OAuth and OIDC as well as classic authentication schemes both for on prem environments and cloud. In short, the AI agent becomes a fully managed trusted identity. The third pillar Privileged AI agent access. Even AI agents need oversight when connecting to critical systems. Here we apply Zero Trust access both at the network and the identity layers.

Privileged agents connect through a secure proxy only when needed and only for the duration of that session. Every session can be recorded and if an agent behaves unexpectedly, it can be terminated instantly. This gives organizations full visibility and control without limiting automation. All three pillars of the Achilles AI agent identity security are MCP enabled and are generally available

today for you to implement. Together, these pillars make it possible for AI agents to work securely without slowing innovation. But that's not all. We've taken it a step further. Coming in twenty twenty six, we're excited to introduce Akeyless AI Insights. The AI Insights engine adds an intelligent layer that helps security teams discover,

understand and remediate identity risks automatically. With AI Insights, you can ask questions in plain language. It can ask things like: Show me secrets accessed in the last week by specific identity. AI Insights instantly pulls live data and gives clear contextual answers. Then comes discovery. Our AI Insights engine continuously maps secrets and

identities across environments, uncovering issues like unused credentials or excessive privileges. Our solution also automates the fixes like enforcing least privilege with just in time identities providing comprehensive reporting. Now, let me tell you how this fits into our broader platform. Everything identity starts with a strong cryptographic foundation. The Achilles platform is powered by our patented

distributed fragments cryptography, which secures every secret, key and certificate without ever exposing the full key. The platform includes the capabilities of encryption, multi cloud key management and tokenization. What we are known best for today is machine identity management. We deliver secrets management and certificate automation, as well as workload identity federation,

so workloads can authenticate securely across clouds and legacy systems. We also provide multi vault governance, giving teams centralized visibility and control across every vault in the cloud or on prem. To secure identities, human identities, we've modernized privileged access management and extended it with zero trust application access using just in time

connections and administrators and external vendors. Then, of course, the Achilles AI solution which we just talked about. As part of this series, we will take you through each of the platform's capabilities and show you how the different solutions work. We will demonstrate how all of this is done through a unified platform, single UI, single API. Remember at start when I said this is now the opportunity to

be an enabler and accelerator? With AI transforming how systems connect, communicate and make decisions, security and I'm teams now have the chance to lead that change, not chase it. Lead safe adoption across complex environments and trust zones even when models, orchestrators and data sits in different places. You can reduce identity risk with zero standing privileges

and secreted access, So speed doesn't come at the expense of control. Achilles now enables you to shift identity theft into AI application design. Bake in secretless access, an agent, identity provider and privileged monitoring from the start so compliance is simpler and proof is consistent and immediate. Discovery will always be reactive, yet providing identities at runtime is how you get proactive.

I'd like to thank you for joining me in our session. I invite you to join the entire series so you can learn more from industry professionals and see our solution in action. Next, I'd like to welcome Admiral Mike Rogers, former NSA Director, to talk to us about AI agent cybersecurity top concerns. Hello everyone, welcome back to the Identity Security Unleashed for the AI era.

I'm very excited to have here with us Admiral Mike Rogers, former NSA director and operating partner and teammate. Mike, thank you for joining us. Oh, that's great to be with you as always. Yeah, where we getting you right now on the globe? I am in Melbourne, Australia today. Oh, this is exciting. Well, thank you again for joining us from there.

Here we are in New York. Happy to connect on that end. So basically, Mike, obviously, as we spoke in the past, we would like to, we're very much interested to hear from you about what you're hearing right now in the world from professionals and your view with regards to the top security concerns with regards to AI agents. Yeah, so, you know broadly when I take away

that I led, Cyber Command and NSA. So our focus was both defending networks as well as penetrating networks. And as a defender, one of the things that struck me was complexity is growing both in terms of the threat, but also in terms of the solutions we're employing. And one of my biggest frustrations always was guys, we have got to simplify things if we're gonna get to speed and scale. Secondly, as we created more and more

remote access, as as our attack service just kept exploding. I got really concerned about identity because my concern was guys, as an attacker, if I put on my other hat, compromising identity is one of the key techniques that we will often use. And we tend to focus on identity from a human perspective. Look at the changes that we've seen over the last three to five years. Identity from a machine perspective is

just exploding. It we get you're getting greater growth right now in terms of machine access in some ways than human access. And so identity from a machine perspective is becoming a massive problem, and we need to make it simpler, not harder. And the solutions we need to come up with need to be simpler, not harder. That's for sure.

Obviously, is all about what we're having in this series of sessions and thank you for emphasizing it. Besides identity, the things that you're hearing more with regards to other concerns with AI agents, what other aspects do you hear about? So look, everybody's trying to maximize the effectiveness of AI and how they're applying it. And so clearly,

we're we're the next kind of evolution you're seeing is this idea of AI agents as vehicles to create massive speed and scale for us, to make us much more efficient, much more effective, if you will, in how we're applying artificial intelligence within our organizations. But the challenge with that to me is so you look at those AI agents, look at you're talking about autonomy,

you're talking about reasoning and planning, you're talking adaptability. Those are all very good things, don't get me wrong. But if we're going to build, if we're going to build much of our operational concept around maximizing the application of these agents, then protecting their security and protecting their identity becomes a really new challenge for us.

I'm a little concerned that we haven't necessarily thought that all the way through. Not a criticism, just an observation. Yeah, of course. What with regards to the amount of data that they are about to have, like when AI agent is running, LLA models require so much access to so much information and how difficult it is sometimes right to

differentiate whether a certain AI agent should have a certain access to a certain data while the reviewer or the requester or the one the human behind the prompt actually doesn't have that amount level of data. It seems like right now most of the AI being used in the public domain is built out of public information, so we less see it. But when it comes to enterprise and to obviously

national use, it changes the picture, isn't it? Oh yeah, you're gonna see a whole lot more data from a whole lot more sources if you will. It kind of reminds me, think about a car engine. Data is the fuel in many ways. Now when you're running a small engine, your fuel consumption is much less. When you're when you're using a high performance engine that's

built for speed, for maximum energy output, so to speak in the form of horsepower, you see how your energy consumption goes way up. How much more you're more reliant on access to fuel. And that's what you're gonna see with AI agents to me. Data becomes the fuel and as we tune these agents to become more and more powerful, more and more effective,

the flip side is they're going to be built around access to more and more data. So that's from a security standpoint, from a flow standpoint, those are not insignificant challenges. You know, are you optimistic with regards to our capabilities to really, you know, really overcome this kind of of a threat or a concern in terms of cybersecurity? I I am because my view is there are certainly tougher technical problems there.

This is to me, this starts with a mindset that realizes that as we change the way we are operating, as we employ new technologies like AI agents, that part of our responsibility to me is to not just focus on the efficiency and the output that they generate, but we also got to think about, so what is the risk associated with them and how do we mitigate that? Now, I think we can mitigate the risk that this is an area where

I personally feel very comfortable. All right. Mike, thank you so much. Thank you so much for joining us today and for sharing with us, you know, the concerns that you're hearing around with regards to AI agents. We would love you to join us through the entire series of sessions also and to view together with us.

But we wish you great success. Oded, thanks. And my congratulations to Achilles and the rollout of the new unified platform. I just think it's a really great strategy that's very much optimized for the challenges that we're facing today and tomorrow. Thank you so much, Mike. Hey. Have a great day. Take care. Weekend. In Australia.

Thanks. See you later. Take care. Bye bye. Bye bye. Thank you for watching our session and interview with Admiral Mike Rogers. Now let's continue to our next part within our first episode of Identity Security Unleashed for the AI era. So within our first episode focusing on the AI agent identity security, today with us, Doctor.

Conor Mankone, our principal solution architect in the US. Conor, how are you? I'm doing great. Happy to be here. All right. This is good to see you and good to be with us. So to our great viewers, today, we're gonna focus, as we started on this episode, with entire interviewing, obviously, all of our all of our platform. We've overviewed machine identity security,

human identity security, our foundation within the cryptography, as well as the AI agents. But for this session, we're gonna focus on the agent identity security and the pillars within that suite of solutions. The first pillar is with the secret s a I, the ability to eliminate all the credentials that are needed

in order to make sure that AI agents do not have access to static credentials, and that includes also secret zero removal. So Conor would obviously demonstrate that today of how not to use any secrets whatsoever. The second component within the AI agent identity provider, how to provide those ephemeral access based on dynamic identities. And the third piece is with AI agent PAM. This one we will demo later on.

But in this particular session, we're going to focus on those two. And with that, Conor, this is to you. Yeah, and so this is exactly what I would love to show you how to do today. I know a lot of companies out there really want to be using and are even starting to use AI as much as they can to help processes and simplify systems and save time and money, which we all like, but of course,

you don't want to create risks as you do it. Secrets as always are risks, just like ten, twenty years ago, you want to be careful about sticking access credentials and stack access credentials and files everywhere is something you need to be cautious about always, and in the AI world, you need to be even more cautious because the last thing you want is for those to be accessible to your AI agents

and to your LLMs because once they get there, who knows where they go next? There's definitely risks of them being actively exposed and that's what we wanna show you how to avoid. And so there's two parts of that that I'm gonna talk to you today. One is Akeyless as an AI agent identity provider, That's the first part of this talk that I'm going to focus on in this demo. This is just a very simple architecture diagram to show

you what we're going to be doing. I'm going to demonstrate using a very simple orchestrator to launch an AI agent in the cloud. It's going to be using a machine identity to get an ephemeral identity for the AI agent itself, so it's going to use a keyless to generate a short lived credential to actually launch that AI agent so it can go off and do the job it needs to do.

So that's exactly what I'm going to be showing you how to do. And for the second part, I'm going to be showing how to bring these secret list concepts to your MCP servers. So for those of you who are not familiar, MCP is a very, very important and very common concept inside the AI world. You can kind of think of it as an AI, an API for your AI agents.

The idea here is that your MCP server is what actually interacts with the different resources, whether it's a database system or your communication channels, whatever, you don't typically give the AI agent direct access to those resources. Instead, you have an MCP server in the middle that brokers that access. And so today I'm going to demonstrate how we can use a keyless, not just to connect the AI agent in an ephemeral

way, which is of course a great start for this, but also how we can use dynamic identities and ephemeral identities with the MCP servers themselves. And so again, the goal of all of this is to, just like was discussed in those opening remarks, the goal of all of this is to make sure that we're using ephemeral identities for our AI agents and for all of their workloads so that we can protect our company from

exposed access credentials. So we're kicking it off. Welcome to Akeyless. For those of you who have never seen our platform before, this is it, and we have everything you need to manage authentication and roles and machine identities and secrets for all of your needs, not just AI agents, but that's what we're gonna focus on today. And so for that first demo,

I wanna talk about ephemeral identities for your AI agents themselves. And so to make that happen, what I have here is a dynamic producer, dynamic secret, dynamic producer. These are the things we call it, and really what this is about is an ephemeral identity for your AI agents. This is an OpenAI dynamic secret,

which means it's actually going to generate credentials for OpenAI itself. It's going to create them, it's going to track how long they're supposed to live, and then it's going to destroy them afterwards to make sure that everybody always has those ephemeral identities, those short lived credentials. So you've got that zero standing permissions going for

your AI workloads. So I've already set this up, this is going to generate short lived dynamic credentials for AI, which my orchestrator is going to use to launch my agents. And so I actually have a little bit of code here that we're gonna touch on very briefly. And so what's going on in this code is that this is Python, this is my my AI orchestrator.

It's authenticating to Achilles using AWS I'm authentication. And so it's my orchestrator is authenticating to Achilles using a machine identity. Again, that's just one form of ephemeral identity for things that live in the cloud. So there's no static tokens here, this isn't a static token, this is just a piece of configuration,

but we're able to use that machine identity connect to Achilles, and then we're going to fetch a dynamic secret, AKA an ephemeral identity out of Akeyless, specifically an OpenAI API key, a short lived one, that we're going to then pass into, that we're going to use to launch our AI agents running inside the cloud. And that's what it all comes down to.

And again, Akeyless is going to generate those identities, it's going to track their TTL, it's going to remove them afterwards. And so just to give you an idea of what we're looking at here, I'm already connected to my OpenAI account, and I've got a couple already running in the background, and so when I launch this process, what we should see is another API key showing up,

and each of those API keys represents an ephemeral identity of an AI agent that's using a key list of broker its access. So voila, I'm just gonna run my Orchestrator. I mean, obviously I just have the code set up, nice and easy to run. It's connecting to Achilles using its machine identity, it's fetching a temporary access credential. And so if I refresh my screen, you now see, hey, look,

I've got a third identity here inside my OpenAI account for this new AI agent that I've launched with my Orchestrator. And we can we can see that on the Keyless side as well. So if I come over back to Keyless and come to my dynamic producer, I can do the temporary credentials. Akeyless is tracking all of those temporary credentials, all of those ephemeral identities that it has issued. It's tracking them and knows how long they are going to live.

Here's the one that was just generated. And when their time is up, it's going to come here and it's gonna proactively revoke them so that you don't have to worry about access credentials accidentally being left anywhere. And you do have full control over this process for the current iteration of our OpenAI dynamic producer, you can control which

OpenAI projects those identities are issued for. Of course, you can also control how long they live. This is fully editable. If you have a workload that's living for a very short period of time, it just runs things very quickly, you can set in seconds or if you have a longer running workload, you can give them a lifetime of days, you have full control over how long they live and where they get issued.

So, you can very tightly control permissions in your project. And it's really as simple as that, and that's what we want. We want it to be nice and easy for your engineers to manage these and to control these, and so that is how it works. So on the second piece, I wanted to talk through the situation of interacting with MCP servers, and I think this is definitely worth visiting because like

with any application development, there's a good way to do it and there's a dangerous way to do it, and obviously we wanna avoid the dangerous ways. We want to do this in a way that's gonna minimize risk for our companies while streamlining development, and so that's where Akeyless comes in and that's what I wanna show you. So for starters, I wanted to for my demo, I'm set up to talk to a MongoDB database.

So the use case here is I want my LLM agent to communicate within a MongoDB database and I wanted to do it with just in time credentials, those short lived credentials, those ephemeral identities, so I'm not setting up static credentials everywhere. And for those of you who have never set up an MCP server before, the configuration is really very straightforward, whether you're running it locally or in the cloud,

typically there's a configuration file where you tell the LLM agents how to connect to those destinations. So here is the official MongoDB MCP server published by MongoDB themselves. And again, it's just a little bit of configuration and here's the thing to watch out for. They typically do show you like the first examples are sticking

credentials inside of these static environment variables, those static files. And that's what we wanna avoid and that's what I'm gonna show you how to avoid. And the way we do that is again, we transition from instead of using static credentials, we wanna use those ephemeral identities, but now it's an ephemeral identity for MongoDB itself.

I have Achilles integrated with my MongoDB database. Just like we saw with OpenAI, Achilles is going to be able to issue and revoke and manage short lived access credentials for my workloads, and I want to use that within my MCP server. And one really nice part about this, which I like to emphasize is that you have full control over what kind of permissions are granted through Akeyless.

So in this case, you have a lot of options. The simplest one is with MongoDB roles. When Akeyless is creating this temporary identity, it can assign roles to it. So maybe your read only role, maybe your dev environment, maybe you have a second dynamic producer for your production environment, and you can control who has access to those independently. So you have a lot of control over who and what you're

granting access to right here from Akeyless itself, that stuff is already built in. It's been our bread and butter for a long time now. And so I have my dynamic secret for MongoDB, it's going to be managing these ephemeral identities. And so inside of my MCP world, I've really just made a very small change instead of launching the MCP server myself and providing

it with static credentials, I just have a small wrapper that connects to a keyless and fetches one of those ephemeral identities out of this dynamic producer. And then this little wrapper is going to launch the MCP server using those temporary credentials. And the nice part about this is now there's really no way for those credentials to be stolen because at this point in time, there's no credentials in a configuration file,

there's no credentials in a static file because this is a process that's going to be launched. What ends up happening is these credentials only ever live in memory and they're provided that way to the MCP server itself. And so stealing those would involve getting them out of the machine's memory, which is typically very difficult, and even if something managed to do that, they're short lived.

They're gonna be dead within less than an hour or whatever you configure the TTL for, like Achilles is going to clean them up afterwards. So this is really as secure as you can get, especially because you can also manage, hey, what permissions do these credentials have? Like, you have full control over that on the Akeyless side. And so this is what we wanna We wanna those,

we wanna use those temporary credentials and make sure that is what our MCP server is using instead of static credentials. And one really nice part is a keyless has a lot of authentication options. So if you have developers who are doing this locally, so this is where the actual authentication to Akeyless happens is hiding right in here with our Akeyless CLI. If you have developers that are running this locally,

they can use their human identities. If you're running this in a cloud environment, you can use the machine identities there. You can put authentication layers in front of this, if it's a remote server to authenticate those AI agents, however you need to do, in terms of keyless, we'll happily help you do that. We can support OIDC authentication,

which is very common to authenticate your AI agents. We can also support other cloud identity authentication schemes. So you have a lot of options for how to control access to make sure you have the solution that makes the most sense for your company. Anyway, I'm talking lots, but here you go, I have it set up and ready to go. And so this is actually my configuration.

I'm now working inside my local LLM driven IDE, and so I can query it to go talk to my MongoDB database, and it's actually going to generate a short lived credential and connect to that database, and that's what it's going to be used when talking to Mongo. And so I can say, you know, summarize the summarize information about my MongoDB.

Sure. And we'll go off. And it should, yeah, it's now listing databases. It's already connected to my database using one of those ephemeral identities. It's gonna go run all of its things that it needs to run, and it's gonna split out some simple information about what's in here. It's not a lot, just some contacts, some companies,

everything I need to know about this MongoDB server. And again, the point is very simple. It is now connected to my database using an ephemeral identity. I don't need to worry about my LLM getting access to static secrets. And most importantly, if I come back to Achilles and I can once again view my temporary credentials, I will see all of the sessions that have been opened to connect to that database.

And if I need to, maybe I have a misbehaving AI agent, I can revoke those credentials and immediately kick it out of my database. I have full control over the AI lifecycle of how it connects to my data. And that is what we wanna do, and that is what Akeyless will let you do with our AI agent security. So that's what I have for the demo. Odette, off to you.

Yeah. Connor, you know, while you spoke, there was a question from the audience that I got on live, which is they were asking about the secret zero. Like, how exactly is it authenticated? You started to obviously show that, but the authentication methods, I think that's a thing that will be important and interesting for our audience to see.

If you can go through those authentication methods a different way to authenticate to Aculus. Yeah, I'd be very happy to. So authentication methods is where that starts, and we have a variety. Really, we support just about any, whatever your system is, whatever you need, we support it for authentication in terms of

avoiding secret zero. And so the starting place for most companies these days are the cloud identity providers. We support AWS IAM authentication, Azure, GCP, and Oracle as well out of the box. What these authentication methods do is they effectively turn your cloud provider into a trusted third party identity provider.

So if you have some resource running on AWS and it needs to log into a keyless, you don't have to give it a static access token. Instead, it comes to keyless and says, hey, I'm coming I'm coming from AWS. And what we will do is we will talk to AWS itself to verify the identity of that machine using those I'm roles that you already have in place,

so that you don't have to hand out an access token and your workloads can still get access to keyless. We also have we support OAuth two zero, which is typically with JWTs. So this is very commonly this is most commonly used for pipelines. If you're running on GitHub or GitLab and the like, they will publish a JWT, which you can use to authenticate to Akeyless.

So again, you don't need a static token. We can easily authenticate your Kubernetes workloads if you have your own certificate authority running in your services, and so everything has a certificate, we can authenticate your workloads using those. Your humans, of course, we support SAML and OIDC authentication, LDAP, just like you would expect, so your human should never need an API key.

And I will just say out loud, you can use all of these authentication methods both in the UI as well as the API, the SDK, the CLI. And so you shouldn't even have to have one of those cases where users like, oh, hey, I log into the UI via SAML, but now I need to do something from my CLI, so let me go create myself an access token.

They can use their human identities just the same programmatically. And finally, universal identity is how we bring machine identity to any of your on prem workloads. And so a a lot of times secret managers like this struggle with the on prem world. They don't really have a way to bring machine identity there, so you end up with static tokens,

but universal identity lets you bring machine identity everywhere. So that's the that's the quick summary of authentication methods and how you get into a Keyless in the first place. Alright. Great. I'm sure that our audience definitely got a good answer with regards to that. And I think that it's good to also, you know, at least mention,

and for some people that be struggling with the concept of secret zero, secret zero, the whole point here is basically how to make sure that when your workloads are authenticating to the identity provider slash the secret manager solution, they would not need to use an API key from the first place. Right? And then when Achilles is authenticating those workloads,

just like within this picture in front of us, then they'll be able to get the dynamic secret. So Connor, if you can stop sharing on your screen and I'll continue from there. But basically, the whole point, as we can see here, is that the AI agent, when it authenticates to Akey List itself, then it's built on the on the authentication of the authentication methods, right,

with no secret zero in order to get authentication to the LLM provider as we saw at the beginning, which was the OpenAI. And then on the second scenario, it was the same AI agent, but now after connecting connecting to the MCP server, the MCP server was the one to authenticate to Akeyless, again, without any API key and requesting access to the

MongoDB, etcetera, etcetera, and that dynamic identity have been created. On those. Connor, thank you so much for being us today and leading us on this demo. We're gonna see you more on other demos that we're to see within the series. Thank you guys for joining us for this episode.

With that, we're ending the first episode of Identity Security Unleashed for the AI era. Coming up next, within our next episode to be broadcasted, we have a special guest, DJ Goldworthy, VP Security of Aflac. We're gonna talk about the convergence within identity security realm. What does it include? What exactly does it mean?

All different tools, all different actions, the IGA, the PAM, the access management, everything converged, but also some more surprises within our conversation. I encourage you to go into our website and register within the Landing AI Identity Security. You'll be able to obviously see all the different episodes that we're having. This list will be more and more. But now right now,

ending finalizing the first episode with our special guest and the interview that we just had with Admiral Mike Rogers, the former NSA director, and our next episode with special guest DJ Goldworth speaking about the convergence. You'll be able to see more and more from that coming up next. Thank you again so much for joining us to another episode, and we'll see you next.

Episode 2: The Fast & the Federated

Welcome, everyone, for another great episode of the identity security unleash for the AI era. My name is Oded Hareven. I'm the CEO and cofounder of Akeyblos. And within our series, we're having great conversations with leaders, practitioners, and thought and thought leaders within the industry,

cybersecurity, identity security within particular. Today, we have great three special guests within the within us, basically, discussing the evolution of secrets management to secret list. We have Richard Barreto with us, CISO of Progress. Hey, Rich. How are you? Good. How are you doing? Fine. Very good.

Yeah. Good to see you. And Nibin Philip, the head of information in cybersecurity, STP nuclear operating company. Hey, Nibin. How are you with us? Good. How are you? Fine. Very good. And James Lazar, CISO at Arterra Services. James?

Hey, Yodad. What's happening? Thanks for having me, buddy. Of course. Of course. Thank you, the three of you for joining us for this, for this episode within our series. I wanna talk a bit about Achilles just, in terms of the overview for the ones, that have not seen previous episodes within our series. So Achilles is a cybersecurity identity security provider.

We're trusted by top brands, Fortune ten and Global fifty, as you can see within different different industries such as financial, retail, tech, pharma, and more. We have basically SaaS native hybrid SaaS solution to run billions of transactions. We run more than two hundred billion machine interactions on an annual basis. We've seen more than five hundred percent of growth since

twenty twenty one to this year alone. We're backed by prominent investors, among them Deutsche Bank as well, And we've been covered and endorsed by several industries, analysts all within the time that we're active. That's it for now. Basically, we'll go over all kind of interesting stuff, but let's start with the breaches.

And, again, gentlemen, thank you so much for joining us in this, and we'll have very interesting discussion about what's going on. And let's let's start with what we see in front of us. This is some breaches examples for the last five years. And as you can see, machine identities and their secrets are the number one attack vector.

They're all kind of reports and all kind of data data points that that strengthen that. But as you can see here in front of you, passwords, tokens, standing privileges, access key, stolen credential, stolen tokens, compromised credentials, all of that, it repeats itself more and more within all of those different breaches that are being brought here.

Lately, also Salesforce have been added here. So definitely, this is an ongoing thing that is happening more and more. And what you can see here is that seventy percent of secrets from twenty twenty two are still active today. So, basically, this is a phenomena in which we're seeing for years now. I believe that the last five years,

it has been increased even further in which we're seeing those credentials being being used and somehow being hacked. There are plenty of those reasons. But we also see that they're not well rotated. Right? We also see that this is an example coming from one of our partners, GitGuardian, in which they've looked at different secrets that out there that they found within

GitLab and GitHub projects where seventy percent of those are still active today. So I'm gonna I'm gonna start with a question to this, this great forum. Why do you think that we're in this situation in which for years we've been investing in all kind of different solutions of managing those credentials, those passwords, those API keys?

But, frankly, it looks like that the industry, for a long time, have not been able to actually overcome this. Either we did not deploy it or we did not do. Why exactly we're not able to to fix this? And and, Rich, let let's start let's start with you this time. It comes down to daily workflow, bad habits, trying to create a place where they can create these secrets in a much easier way that that they can rotate.

But, you know, with, yeah, just coding different places, different tools, it's not it's not easy. Different languages. And so and depending on your organization, especially if you're a growing organization, you have thousands of applications that you're dealing with, integrations that you're dealing with, and it's a sprawl,

and the attack surface just keeps on getting bigger and bigger. With tools, it helps to try to minimize the the sprawl, but it it always just comes down to bad habits. Alright. James, would you like to go second? Yeah. I mean, following up Richard, it's always hard. But but I'll say I'll say this. When you look at the the main challenges why this continues to happen,

it's because we've we've been sold and developers have been sold a fallacy. The fallacy is you create an API key and no one can ever get to it, no one can ever do anything with it. It's there, and you don't have to change it. And we've never really considered the fact that that part of the I that API tokens were part of an identity until a few years ago.

Right? Because there there was a period in time where we used to talk about API security, not identity security. I mean, there was a time where Gartner actually had that as a category. Right? They may still have. I don't know. But this all kind of goes into the this this this idea that we we've really kind of this

this membered and kinda created all these various categories instead of just addressing it all as identity. And then if we addressed it all as identity, then identity first principles would apply no different than every single one of us requires MFA. Right? Like, everyone here would require MFA on a human identity. And we talk about rotating passwords and rotating and

refreshing tokens, but we don't do that with any other identity. Because, again, I think developers this isn't security's problem necessarily as well. Security has to deal with the with the fallout. The problem revolves around the fact that within the developer cycle, we're not really requiring a rotation. We're not really adding that as part of the dev. So I I'd like I'd like to push that a little bit.

Push that button maybe furthermore, and and and then I'll I'll and I'll and I'll ask Nibin with that. And and you gentlemen, maybe you'll you'll be able to add later. We all know for a fact that audits and compliance have asked for rotation for more than ten years now in different places than and sure. There are some companies that they need to comply less with

all kind of audits and compliance, and they are less regulated. And yet even ISO twenty seven zero zero one, so basic, is now asking those rotation practices, and still we're seeing those breaches continue. So I'm gonna I'm gonna make it a little bit more harder for us. And and I'm putting, obviously, me together with you guys as a cybersecurity practitioner,

inside of things that I've seen in the Israeli defense forces years back. So, Nibin, why do you think that although audits are are is required and we still and we see regulations that speaks the language of rotation, what do you think that, they're not yet there? We're not able to yet, completely be able to, eliminate that, current issue? Yeah. Absolutely.

And, again, it's not just the compliance piece, right, the fear of downtime. In my world, availability is king. So we often see breaches versus because teams are terrified to rotate the credentials on legacy systems. For example, if fraudating a key risk crashing a critical application, operation teams will fight to keep that static key in place. You know?

So humans always wanna come up with a workaround. So when security controls create freak frictions, engineers find workarounds. We see breaches happens, not because the security vault itself failed, but because someone just wanted to bypass it to get the job done faster. So, you know, for example, saving a key in a script or a config file to avoid the hassle. So we are often dealing with system that were built fifteen

or twenty years ago. They weren't designed for modern security walls. So attackers know this, and they target those older, harder to update integration points. So it's not just the compliance piece for us. It's availability. Yeah. So complexity, it's hard to change. It takes time. Maybe even mislabeling as as James as you've suggested.

Right? Mislabeling the the challenge and the potential potential solution. Any further comments on that on that end, guys? Okay. If not if not, then I'll I'll move on to something obviously very much related. So I wanna take you through the journey that we're seeing within the secret list machine authentication,

which is kind of the ideal of how Aculus and some and some and some within the industry are recommending to go through the journey of basically stop this addiction, I would call it, to static secrets and to go to the more advanced authentication ways to reduce the risk of breaches. Right? But the journey starts with actually acknowledging the

number of static secrets that you have, centralizing all of those, and to be able to first understand. The second is the ability to leverage Achilles to perform this automatic rotation, which is basically defining the object that would help you to automatically rotate every thirty days, every sixty days. But then we also understood that rotation is not enough.

Rotation still keeps those identities available whenever they're not being used. Right? So there is still a database account even when you don't see the moon. Right? Even when you don't see the moon, it's still there. So even when you're not using the identity, the identity is still there. So we wanted to provide a mechanism that would basically

reduce the risk for for breach as a result of using, this particular identity. So we created this dynamic identities or dynamic secret as the industry calls it, based on just in time principles. Right? So whenever a certain workload requires access to, let's say, a database, then we're able to create those credentials, then later to delete those.

So this is temporary and based on just in time just in time and zero standing privileges approaches. The first generation is called secret list and based on OAuth mechanisms, OIDC, SPIFI Inspire, that the name secret list is obviously to imply that the the chances to get the secret is very low, but the industry has started to pull that actually with understanding that there is a token out there,

but it's very short in time. So there is no provision for an identity. So whenever a certain workload requires access to, let's say, a certain API, assuming that this API supports OAuth and Achilles is able to provide this token for a short lived time, it can be for a certain transaction for a certain minute, ten minutes, and so on, and that reduces, obviously, the chance to get this token into for the form of breach by

exploiting this token to a very bare minimum. So I wanna ask you guys, when you look at this journey, how does it, you know, how does it refer to the way that you look at it within your existing places or any previous places that you've been at? James, let's let's start with you this time. How do you see this journey of moving on to secret list? Is it something that is achievable

as well as, you know, the difficulties that you that you encounter? So everything's achievable if it's a priority for an organization. Right? The question is gonna be, as you kinda talked a little bit ago around compliance, Will ISO twenty seven thousand and one update its requirement? Or will SOC two?

Or or beyond all that, will your key customers require you to go that route? Meaning, will that become a contractual obligation that some companies will require that change of behavior? Because when we look at this specifically from from a business point of view, behavior like this has changed from one of one of very few reasons. Right?

Like, we we all wanna go to that realm of of secret list, right, of just everything kinda constantly rotating and evolving. I I don't know anyone that would say no to that proposition, but there's a cost to go there, and there's complexities to get there. So what's gonna drive that is the business understanding we have to go that route. So that's either gonna be regulatory requirement,

which would be oh, there's my thumbs up. Yeah. Yeah. Yeah. Right? The second thing for this would potentially be contractual, requirements coming from key vendors or customers that you work with within the industry that require you to have a specific set of of of of requirements to integrate into their environment, which essentially ends up,

rolling that downstream. Or the third reason is an organization that has the security budget and the desire to be market leading because they see that as something that benefits them specifically. Otherwise, I think the the the hill to climb is very, very difficult. Alright. That's that's interesting. It's a lot about, the demand to somehow change the demand of, you know, where to implement that because you need But there's gonna be

push Yeah. There's gonna be push back. Right? There's gonna be push back from developers, business cost. Who's who's who's getting more money in twenty six? Most budgets are flat. Right? How many systems do you know that are going in saying, hey.

My budget grew by fifteen percent? I think I was looking at a research like, a little research for twenty twenty six. I think that was under five percent. Well, there is some opportunity there with AI, but we'll talk about that later on. Rich, to you, I see that, you have, you have your own, angle on this one.

So the journey is difficult for sure. This is to me. The journey is difficult. So there's a lot of reasons, time and resources, which James talked about. There's tribal knowledge. Niven initially talked about legacy. Right? So you don't know what the impact of any of these changes. And it it comes down to what's the business value. Right?

And the way what James was talking about, I was just listening to him. Life is pretty simple. We do things for a few the only really two reasons, to avoid pain and to find pleasure. Compliance is a pain. Audits complaint is a pain. Finder a pain. If it generates revenue for the business and if it improves our

trust and recognition with our customers, we're gonna do it. I I like the idea about the the the contract, right, and getting our customers to contract with with your company to make sure those things happen. So it it all comes down to visit you know, like like Vane said, it's business prioritization and what can you do within the time and resources.

For for my organization, we we had to look at it from a risk based perspective because that's the only way we're gonna get the best value. You can't go change the secrets or or static secrets in every single piece of code when there's ones that are high value and low value. So I would say you gotta, first of all, find out where all your secrets are and then look at your your

most critical applications, to the organization and and then figure out from there from there your your pecking order of what needs to be done first because there's not enough time and resources or or tools, in fact. Right? Because those require money as well. Yeah. Alright. Nibin, your angle? Yeah. Absolutely. Again, my point is gonna be aligned with what James and Richard just mentioned.

In high state environment, we like things to be deterministic. Right? We want to know exactly what will happen. Dynamic secrets can sound scary because they introduce constant change. So the journey for us is proving that dynamic is actually safer and more reliable than human manually updating password, which is something that is a challenge. Right?

So we have to remove the human bottleneck for sure. For example, the biggest operational benefit of going secret less isn't just security. It's removing the dependency on having humans. No one has to remember to update a certificate or a key. The system handles it. Right? So which actually reduces the risk of human error causing an outage. So we always have to remember the hybrid reality.

We have to be realistic. We will likely have a hybrid state for a long time, modern applications running secretless and legacy applications or infrastructure relying on hard and secret walls. Right? So the goal is to, stop the legacy footprint from growing. I mean, that's something that we need to focus on.

Yeah. I think that, you know, you're mentioning here a very interesting and a very good angle that I I do hear a lot in the in the industry that it's it's it's okay to start with a greenfield. It's okay to start with the newer places that you want to provide a a better, more, you know, more updated policy making, right,

and better implementation. And then to think for of creative solutions that you can do and sometimes you cannot, or it's very difficult to use the same the same mechanisms within your legacy or older environments. Let's call it this way. But I I wanna I wanna pause here for a second and to share with you something that because the thing that you're sharing

here sounds like you know, it reminds me of a past where we spoke the same about application security guys. If you remember ten years back, we said it's very much more difficult to, you know, to change vulnerabilities within the code. Developers right? We all we were all talking the same language where developers

were very reluctant to make the changes in order to make sure that the code itself is more is more secure. But, you know, when you think of it, we actually had a very, very interesting and I guess that you see in front of you right now, if you remember, in the last five years, we talked about a shift left within security. Right?

Basically, is or for the ones for the audience that might not be that, know, let's call it, familiar with this, then this is the this is the CICD loop. This is the DevOps loop that speaks about the buildup of the code, the code, the build, the test, and then the running it, the deploying it, observability. And, obviously, this does not necessarily have a a relation specifically for security. But what what's beautiful here is that that in the last five

years, we've seen good examples of shifting security left, bringing the security from only on the runtime, you know, within the infrastructure. We were hardening right? This is basically twenty years back, fifteen years back. We were hardening the infrastructure. And today, it's so natural for us to speak about security within the CI processes.

So we're talking about CICD, changing CVEs. Lately, I've seen also very interesting startups that are able to literally change the CVEs automatically using AI, which is magnificent. I wonder if this is not the time for us to find the power and to say identity should be next thing. Shift identity left and bring identity much sooner within the process of software making.

Question mark, is AI the right time for us to do so? So, Niven, I'm gonna I'm gonna bring this now for you first. What do you think about this potential shift identity theft? Is that possible? Can that help us to mitigate those those challenges and to be able to help us move sooner to authentication and authorization advanced capabilities. Yeah. Completely agree.

Identity should be part of the shifting left mentality. Right? So we're looking at identity as an architecture. So shifting left means identity becomes part of the architecture and known an afterthought. So we need to define who connects to what in the design phase, not try to patch it after deployment. Right? So standardization. It's about consistency.

If every developer manages secrets differently, it's a nightmare to audit. If we provide a standard method where the identity is baked into the build pipeline, we get better security and cleaner code. So that's my perspective. And, also, from a governance perspective, when identity is defined in the pipeline,

we can see it. We can actually audit the intent before it ever reaches production. So that's my take on that. Yeah. And it goes to the education, isn't it? Right? Absolutely. At the end of the day, it's the ability to communicate with the other side, to communicate with the developers and engineerings,

and to be able to have them to take that in account. I wonder if there are tools to do that, and, obviously, I'll I'll suggest some of that later on. Rich and James, you'll be the last one because I gave you the first earlier. So, Rich, maybe to you. What do you see about this gifting IdentityLeft? Is it even even achievable? What do we need to do in order to make that happen?

Percent of this. It's achievable. It so if if you could build a good guardrails, right, so then you just basically build a happy path for engineers so it doesn't have to be an afterthought, That's that's the route we wanna take. Now it takes time to build that happy path and build those

guardrails with automation and detection, so that it can be done proactively and then stop the bad behavior. We call it bad behavior, but the practice, right, when it's about to be committed either into into production, it it's achievable. But it takes like, with anything, right, it takes a bit of engineering and and also being thoughtful. It I think where the shift was

and I think this is what also helped to the shift was when you go back ten, twenty years ago, all our applications are very monolithic. So you make one change. You don't know what it was gonna break. Now in this day day and age of SaaS services and microservices, you can make a change and the impact is minimal. Right?

It it there's a smaller attack surface or impact, and that allows us more flexibility and agility to do that. So absolutely believe that it can can be achieved, it takes some engineering and and thoughtfulness in in how to create that happy path. Alright. So happy path and take it with take it with engineering. So, James, over to you.

Yeah. So shifting identity left doable. I agree with Rich and I've been I think there's a I think there's a path to get there. The the question is gonna remain, I think, at least in my world and events world, which has a bit more OT in it. Right? How do you do that on legacy?

Because it's easy to do that on SaaS and kinda modern networks. When you get to legacy environments and SCADA environments and ICS environments, that's where I get a little bit more skeptical of whether or not that happy place can be found. And we see that in manufacturing today. Right? Manufacturing is the ultimate example of kinda skate an OT and IT meeting and and, you know,

I I won't name the victims of the recent crimes, but there was one that required a government bailout loan in order to to to keep a country from losing four percent of its GDP. Right? The these things come into play where where, in theory, if you were a modern enterprise, this shift left in identity should be something that's a pretty, a good eighteen to twenty four month project.

Right, Richard? I mean, you're you're modern. I I think for Nabin and I, that's a bit more of a, okay. We could probably do it in our IT environments. We could trying to touch our OT environments is is is significant, I think, in any aspect. When even when you try to switch out a firewall, there's Yeah. The steps you have to go through are complex.

Nevertheless, try to create some sort of identity routine in play that that creates a whole a whole other challenge. Not to say it's not doable. I just think that trying to say that everything is doable for everyone simultaneously is is is a lot more difficult. I think when you look at modern fintech and SaaS companies, I think the shift left for identity across the entire enterprise is is something that's doable.

When you look at manufacturing, energy, oil and gas, I I would say there's significant risks with going that route because of the Yeah. That go on within those environments. So I I listened to you, and then I'm thinking of, you know, a different element that we've had with identity long time back when we spoke about those passwords that, you know, we've had for humans.

And what troubled us all across, and I'm going back again fifteen years back, that everyone had so many different passwords, but I think that people have looked at it more from a complexity problem rather than having rather than the security problem. They're it's a security challenge. So we've created this concept of SSO. Right? We said if you remember back then, today,

it's called identity provider, right, for humans, like XAML. And and we thought about, oh my god. We have so many, you know, software shelf software that we're not able even to to change, and it was not SAML friendly, and there was no standards back then. So back then, we started with all kind of solutions that inject those passwords where the the goal was for the users for the end

users within the organizations not to remember those passwords at all. I think that what pushed this was also the customer IAM that came in for a multichannel enablement and to make sure that everyone can use the same account and not to use different different accounts whenever they need it. Anyway, the reason that I'm I'm I'm bringing this is because when you think of it, we also named that challenge back then that this will be

more difficult to change. We won't be able to change the industry. It will take time. It did take time. But what we did invent back then as an industry is that north star of saying, let's move to more productivity. Let's start saying that we will start using an identity provider so that people would be able to stop using those passwords. And with time, we're going to migrate more and more of those

softwares to be able to absorb that. So I would challenge this forum and talk about the identity provider for machines. And let me share with you what what is the concept here that we're obviously, with Akeyless, that concept that we have started and actually implemented as well. Basically, shifting the mind from reactive, right,

saying, let's go after the developers and start changing stuff, then actually being proactive and basically put on the table a new philosophy, a new terminology for machines. So here it goes. What you see in front of you, and and I call it a more very simplistic way of saying SSO for machines, although I believe that the best way to call it is machine identity provider.

Right? The need is going to be and the demand for that is not just from the era of complexity and security, but I believe that there will be a necessity for that given the new AI agents applications or whatever you wanna call them. But, basically, those AI agents would require further connectivity and further authentication or precision across environments.

We're gonna see that grow more and more. Traditionally, with workloads, developers and platform teams traditionally have have had those implemented those within a certain environment, a certain cloud provider. They've took the front end, the back end, and the database usually, alright, generally speaking, within the same environment.

Although some links have happened between cloud and on prem, it was I will call that a moderate comparing to what the future would provide. The reasons for that is, number one, the built in architecture of AI agents that require multi connectivity between environments. In this example, by the way, you see here a Neo Cloud that provides the LNA model or a

SaaS provider like OpenAI that provides the actual model, the orchestrator to be ran within a certain, let's say, cloud provider, whatever it is, And then the MCP server that wraps the data itself in which the AI agent and the NLM model requires, that would sometimes even be on our on prem. Right? So we're gonna see more and more of that demand within the

architecture of AI agents, but also when AI agents will start communicate with each other. And that will bring a big boom in demand, if you wanted, for what we call a cross domain authentication and authorization. The only way to provide that, and and I'm talking now even educationally, to basically bring those application teams and the new AI programs that are starting to implement those within

organizations is to put that idea on the table today within your excellence, you know, excellence committee that says, guys, let's stop talking about managing credentials. Let's stop talking about managing the secrets or updating them. Let's start now talking about the concept of identity providers. So for that, every application that is now being created should go to the identity provider to provide it with an identity on demand

dynamically. Of course, it's a greenfield thing, and it will take us some time to change. But when you look at Chen AI and the way that it is we'll be able to refactor our applications very soon. I know that for some environments, Nibin is serving and James is serving, within the OT, it might take more time, but eventually,

it will happen there as well. So what do you think about this concept of of having an identity provider and basically laying down this idea of proactivity and to educate by that, well, the the developers, given that we don't have any other choice, this is about to come, and the needs for multi authentication and the multi year IP connectivity will happen very soon.

So this time, Nibin, let's start with you. Yeah. Absolutely. So I wanna start with the reactive security. Right? The cost of reactive security itself. For us, for example, reactive security is too late for critical systems. We can't afford to wait for an alert that says a credential was compromised.

The impact is too high for that. Going back to what James explained earlier, everybody likes to have proactive or predictive, systems or, baselines, absolutely, but it's hard to achieve in operational technology. So proacti means pretty much understanding the baseline behavior. So let's say if a machine identity typically reads from one database or application and suddenly it tries to write to

another, we need to stop that immediately. We need controls that detect that drifting behavior. But how do you implement that in OTD? That's always going to be a challenge, but anything outside OT, it's it's feasible. Right? So we could have automated responses, for example. We need to move forward toward automated containment.

For example, if the trust level drops and the access should be revoked automatically, we can't really rely on a human analyst staring at a dashboard to catch it in time, so we have to use an automated system for that. So, absolutely, I agree. We could go in that direction, but it's challenging, especially in the OT side. Alright.

Rich, let's go, let's go with you now. If you can build a happy path for engineers, I think this is this is one way to get there. Right? You're you're providing them something systematically that they don't even have to think about. It's already prebuilt. Right? The patterns are already prebuilt. There's enablement already prebuilt.

The education's prebuilt. It it it can happen. Going back to what Niven said, in in OT, I can see how that's difficult. Right? Because you have a lot of legacy systems. They've existed for not not years, but maybe even decades. Right? So how do you go back? Anything that you, I think it's it's it's easier. But there is there is gonna be a call for that because,

especially with AI, you know, that you and I talked about this personally, it's it's exacerbating the the whole area of of identity. Right? Because there's more increased workloads. There's more API to API integrations. It's not just you know, especially with the Gentic AI, it's not a one to one. It's a one to many.

And so how do you how do you manage that sprawl, which is which is gonna be a challenge for our industry. And so, yeah, you definitely need something systematically to be able to give you that governance and guardrails and to be able to to rotate those passwords at at will. We talked about this too, Oded. You know, like, in in the future with Quantum, there's gonna be post Quantum encryption,

and there's gonna be you're gonna need encryption at a packet level because it's gonna be that the velocity of finding these or breaking the encryption is gonna be, you know, that big of a problem that we have to get to that to that level at at a packet level. So to answer your question, yes. Absolutely. We'll need we'd need a system, but it it's gonna take time for adoption,

which is always a challenge. Alright. We're going back to a lot of education. This is something that I believe that it will be the first takeout when we think about what's the summary for us when we talk about, you know, with the CSOs and IA meters. The the I think the main thing, if I recognize correctly, is education and relationship between the security and the

platform, which always goes back to this. James, what's what's your view on this? Yeah. So so I don't have much to add from what Richard and and have been said. I think they've covered it fairly well. I'll kinda reinforce the point that she said, which is anytime we'll look to shift the market left, it's not just about educating the systems, right,

which is which are gonna be the the you could say the executive sponsor of the shift left up up up within the organization, but it really does involve educating the entire line of business, right, from from the CIO to the CTO to the developers to helping them understand that process effectively and then helping them understand why to use it. And when you look at, you know, just vibe coding as a prime example.

Right? I kinda like to use that cursor example of how fast the twelve months is what took cursor to get to a hundred million in ARR. And and very and and when I was looking even deeper into that number, that that hundred million in ARR wasn't enterprise led. In fact, enterprise only accounted for a very small percentage of that hundred million.

It was primarily developer led, meaning they were actually very successful in reaching the developer community and getting them to use their tool for Vibe coding and getting the those people to actually pay for it. I think the same applies here. Right? In order to successfully reach that point, we have to reach those those developers and then those system administrators and those business owners to go,

we definitely need to drive it this way from an adoption perspective in order to really move at scale and speed. And then Richard brought up post quantum. You and I have talked about post quantum numerous times. The post quantum world's gonna require a platform like AQUILA's to say, we rotate secrets because post quantum cryptography means crypto agility. And for those who don't know what crypto agility means,

it means swapping out your your exchange keys at a moment's notice because someone was able to actually break that. And and and the business and, you know, this is where AI business regulatory, they're all gonna come together, and it's really what's gonna drive this machine identity kinda revolution in the in the in the front and center. So commenting commenting on what you said just said, James,

and and Richard, you've mentioned, and they've been within your saying, there's a lot of education and and being able to influence our counterparts within platform and within engineering. And I'm thinking here, you know, for years, identity as an organization became like a siloed team when you think of how organization how the CIS organization is is structured.

Some teams are greater, bigger than others, and some are not. So we sometimes see this identity specialist, I'm specialist. But within greater teams, again, it's it's a silo. And I'd like to ask you, you know, as as a discussion point here, couldn't we be better if identity could have been cross functional specialty instead of being a silo of its own?

Rich, let's start with you this time. Yeah. I completely agree. So build us on your excellence around identity. Think where it goes back to even just access management. But now that's taken to a different level, a different extracted layer of of machines on human identity, secrets, tokens, etcetera, Someone has to drive it. You know, you're you're absolutely right.

In big enterprises, a lot of things to operate in in silos. Unless there's some level of governance and someone driving it at a central from a central perspective, that's the only way it's gonna get achieved, from my experience, because everyone has different priorities. But if if there's if there's someone driving it and and has oversight over it and then there's an executive sponsor and there's and there's absolute you know,

complete ROI and and good business value with good business outcomes, it's achievable. But it someone has to drive it. Yeah. It sounds to me like, you know, even when you're thinking of the organization within CSOs, you know, the data security silo, the cloud security silo, a lot of it has a a lot a lot to do with how we've used to do

architecture, how we thought about the newer environments versus the older environments. Maybe a good example of this new fusion is actually the security operation center and the and the and the sec ops. Right? The ops that came into our life, which became cross functional. Right?

Ops that absorbs all of this data and actually operates potential breaches, etcetera. But, again, identity sounds to me like it is so much related to all of those different parts. And I wonder, again, if this should be or shouldn't be a cross functional instead of a siloed approach. James, what do you think about that?

So so the challenge you have with that is the issue of governance within an organization. Right? Typically, IT manages identities in terms of issuing identities and and and so forth, and security oversees it and sets the governance of it. And so the idea that you can just create a a an an identity team across the business is is smart.

It's just a question of how you intertwined it within the DNA of the business. You may be able to create an I'm team, but it's never gonna really be fully under security. Right? You may have to have a kind of an I'm ambassador sitting on the developer side to help manage the nonhuman identities. You may need to have someone on the IT side to help manage the human side of It's a start.

Yeah. It's a start. Yeah. But but you definitely you definitely have to get smarter in terms of how you do it and kinda how you spread it across the organization. Because if it's not part of the the business you're trying to really change and it just becomes something with with the rent policy that you have to to observe,

that battle is way, way uphill. Yeah. Well, Nibin, on your end? Yeah. I agree with, everything that James and Richard mentioned. I know from a solution perspective, we all are trying to unify or have, like, single platform where multiple solutions are tied together just like that.

Even from an identity perspective, it's good to have a unified strategy so that you could implement a strategy that integrates with the different components of I'm to work with different, departments, you know, pretty much seamlessly. And it fosters collaboration. And, again, it's not easy to do it because change always is something that's not easy to implement.

Right? But I'm pretty sure that with the right effort, we could foster that collaboration. Thank you so much, Niven. And, gentlemen, I'd like to thank you all for this great opportunity to have your opinions and to pick your brain. If there's anything else that you'd like to add, this is a great opportunity.

So just unmute if you have any. But if not, Alain, I'll I'd like to thank you and also to invite you to our next episode and to join that. So, again, thank you, Richard Baretto. Thank you, James Lazar. Thank you, Nibin Philip, for joining for this great session. I had a good time, and thank you for sharing your thoughts.

So on our next episode, we're gonna focus on the unified governance across every vault. I'm gonna have a a good conversation with Vanni, our director of solution engineering here in Achilles, And we're gonna focus on we're gonna show some demo of how exactly we can have a a multi vault governance so that you'll be able to see customers are able to see

everything that's running on their cloud vaults as well as on their on prem open source vaults that they have and to basically centralize this whole process within one single pane of glass. Again, guys, thank you so much for being with us. Thank you for our audience, and I will see you next time.

Episode 3: Vaults of the Multicloud

Hello and welcome to the latest episode of Identity Security Unleashed for the AI era. This is an episode series that started about six weeks back, and we have been releasing new episodes around identity security and how that is changing in the AI era. As a part of today's episode, I'm glad to have with me Vaani Thiruvanganam. She's the Director of Solutions Engineering at Achilles.

And the topic that we have for you today is something that most enterprises struggle with. Enterprises that have secrets, vaults in multiple locations, in Azure, in GCP, in AWS, as well as on premise deployments of HashiCorp. And secrets are sprawled in multiple locations, secrets and machine entities. Today's presentation is going to tell you how to deal with it.

And it's not just tell you, it is to show you how to deal with this. We will actually have a demo that we will go through as well. With that, we'll get started. Just by means of introduction, for those of you who don't know us, Achillas, who may have not seen the previous episodes, let me just give you a quick introduction of who we are

before we jump into multi world governance. Now Akeelas is a unified identity security platform that protects machines, AI agents, as well as human identities. There is no other platform in the market today that can claim that it is a unified platform where all of these capabilities are built into one platform. We are trusted by some of the largest companies in the world across financial services, retail, tech and pharma.

We secured two twenty one billion transactions, machine to machine interactions today, and it continues to grow at a rapid pace. You would have also seen our positive ratings in G2, both from a perspective of leadership, ease of use, support, as well as providing you the best ROI as well. And of course, Achilles has mentioned in some of the leading analysts in the world, including Gartner, Forrester,

IDC, as well as Kupinder Kul. With that quick introduction, this is an overview of our platform. I mentioned that we secure machine AI agents and humans. You can see all the capabilities of the platform. I want to emphasize that this is in one unified platform. Now these capabilities may be offered by multiple vendors across multiple products today.

It is very unique that we offer all of these in one platform. And it's a true platformization that eliminates the needs for multiple product solutions and multiple UI. What we are going to focus on today is under the machine identity security category, where we are going to talk about multi world governance. Before we jump into the solution itself, what are the challenges with this?

I want to use an actual customer example here, someone who had to deal with seven thousand vaults spread across AWS, GCP, Azure and on premise HashiCorp Vault installations. And this customer had all of these challenges that we helped solve for them. The first is, of course, you don't know where your secrets are if they are

sprawled over multiple locations. Imagine seven thousand walls. The second challenge is ensuring you have governance and control over those secrets so you don't lose track of, things. The third, of course, is manual and inconsistent rotation. Let us say you have a breach. In the event of a breach, you're rotating all your secrets.

If you have multiple walls, multiple UIs and multiple products, that by itself is a challenge. For some of you who may not know that this might be an issue, please refer to the Cloudflare breach that happened last year and how the company had to struggle to rotate secrets after an incident happened. And of course, you're paying for multiple products,

you have to manage multiple products, you have to use multiple U. S. There is an operational complexity that is associated with it, and it exposes your company to risks, too many unmanaged secrets out there. And as I mentioned about the Cloudflare example, there is also a risk of slow incident response

if you don't have the ability to have visibility, governance and control over your secrets located in multiple locations. What Achilles multi wall governance does is exactly solve those challenges for you. As you can see from the image on the right, Achilles will act as the governance layer and manager of all these secrets managers, AWS,

Kubernetes secrets, Azure Key Vault, Google Cloud, HashiCorp Vault, GitHub secrets, etcetera, wherever your secrets may be, so you get an unified secrets visibility. Now this helps you with the full lifecycle management of the vaults and centralized access control in governments. What we mean by that is you can rotate secrets in an external vault through the keyless multiwall governance.

This accelerates your ability to respond to incidences in the event of a breach. And of course, it reduces the cost of having multiple walls and managing tools and the resources needed for management of those tools as well. And at the end of the day, the reason we do that is for the purpose of enterprise security and compliance, which this tool also helps manage.

And this customer that I referred to that had seven thousand vaults had many of these vaults that you see on the right and were able to consistently manage the secrets across these walls using Achilles multi walled governance. But there is so much that I can talk about multi walled garments. The best thing that I can do though is to show you the product in action and we will pick many of the walls that you see on the right so you can see how easy it

is to deploy and manage multi wall governance. I want to invite my colleague, Vaani Thiruvanganam, who's going to show this in action. What you see on this slide is what you're going to see it in action. With that, Wani, please show us what you've got. Thank you, Suresh. I'm excited to show you all a demo of Achilles and our multi wall governance solution.

Before we jump into it, I want to share and talk about the problem that Suresh just talked about. Organizations have too many secret managers. They want to they're decentralized by choice because they want to make sure that the development teams can develop with the tools that they're comfortable with, with the ecosystem they're familiar with. So, you end up having secrets across many secret managers.

It could be AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager. Introduces a lot of manual overhead. You have inconsistent access control, inconsistent governance, and actually increases your security risk tremendously. So let's talk about how Akeyless with our multi wall governance solution can actually help you with this.

So this is our console, and here you can see that in a unified fashion, you can see all the external walls that you're using today in one unified dashboard. You can actually also see all the secrets that are being managed and rotated by Akey List today. Something as simple as clicking here and viewing all the secrets that are available to you.

So, you might be wondering, hey, how easy is it for me to add a new external vault in Akeyless today? So, let me show you that. But before we step into it, let's understand some basic concepts in Akeyless. What is an item? An item is anything that you're trying to protect.

So it could be an encryption key, it could be a static, rotated, or dynamic secret, a certificate. In this case, as we will be using today, it could be an external vault. What is an access role? An access role is who has access to this, right? And we have role based and attribute based access control. And we lead with the principle of least privilege,

which means that at any point in time, we're gonna give you the least amount of privileges possible to do the function that you want to do, to perform the actions that you're looking to do. What are user and auth methods? So, this is how you have access to it. So, in your organization today, you might already have a way to authenticate.

Achilles works with several third party vendors and integrates with them to give you very seamless human as well as machine integration. So, we have this layer of authentication and then the layer of authorization that I already showed you to give you very granular control. Last but not the least, which we want to talk about today is our targets.

What is a target? A target is an external system that we integrate with, but then perform an action on it. In this case, I'm gonna try and rotate a secret. I'm gonna try and add an external vault. So, I already did add an external vault, which is AWS California. You might be like, hey, what does that involve?

Not a lot, actually. It is fairly simple and I'm using my gateway, which is a lightweight container, existing AWS IAM credentials. So, I'm using one less password, and I have already provided connectivity to AWS California.

So, targets, again, you're creating a connection to an external system. So I'm gonna go in here and create a new add a new external vault. AWS California. I need it to be in my folder. Target, as I said, the connection that we're gonna use today.

And my gateway, again, a lightweight extension of the customer's network. It sits in the customer's network to provide you with caching and advanced functionality. And with that, a couple of short steps, we now have connected an external vault within Achilles. Let us view all the secrets present here.

So, looks very easy. So, let's think about what are all the functionalities that I can perform on this external vault. I can create a new secret. Right? Let's do three. I can set a value

and with a looks like I've already used that name, so perfect. So with a couple of steps, I was able to add a new secret within my new vault. And if you're wondering if it is being reflected, yes, if I go in here, this is already being reflected. Dev user four.

So Achilles is not creating a copy of the secrets in the external vault. It is reflecting it in real time. So, what else can I do? Added a new vault within Achilles. I created a new credential. I'm gonna update this one and you will see that it will again be reflected in real time in the AWS

secrets manager. There you go. And as always, I can also delete it. So you have full management of your secrets in the external vault through Achilles. And here you actually have a unified vision, unified visibility in addition to doing all these activities. So, something top of mind for all of us is to move away from static secrets, have rotation.

So think about it. All the external all the secrets managers that we talk about have various ways of doing secrets rotation, not consistent, needs manual intervention, again, leads to ineffective or inconsistent governance. So how can you manage the rotation centrally from Achilles? So again, let's go to items,

things that you want to protect, and I already have a rotated secret here. So, let's talk about AWS MySQL rotated secret. What is this doing? I have a MySQL database in AWS, and I'm trying to rotate the secret for that. Again, fairly simple to set it up, and my configuration says rotate the secret every ninety days.

And you can, by the way, also send a notification in advance when the rotation happens. So, this is great. It's gonna change the password at the target system. But what about all the secret walls where the secret is stored that might need to update so as not to break the system? So, you can actually sync this password to external walls,

multiple external walls as you choose, and make sure that they stay in sync. So, let us go ahead and rotate the secret. So, as you can see, the new secret is IO3 starts with IO3. So, let's go to Oregon and view the secret.

As you can see, I just checked and the password is reflected here. Again, I will also go into GCP and look at the password. And you can see that the password is reflected. So, in real time, I rotated a secret. It was rotated both at the target endpoint, which was the MySQL server,

as well as in the GCP and AWS secrets world where this password is being used by several other workloads, and this happens in real time with Achilles. Let's also talk about access roles, access controls. So I said with Achilles, you have several third party integrations for both machine and human access.

So we use authentication that was already established in your organization for authentication purposes. Then you want to layer it with very granular role based access control and attribute based access control. So as an example, I've created few of these roles. So I'm saying any Okta user who's logged in and who has this group, a subclaim app.

Aws. Admin, can now read, list, update, delete, and create and work with any of the AWS external bots. For read only, if they have the subclaim app. Aws. Read, then they can read and list the secrets. So again, leading with the principle of least privilege, you can control as granularly as you need who has access to what and what are the actions that they can perform.

Just making sure that you can keep it consistent across walls, across secret managers, which is probably not possible today with all the secrets fall that you have. Everything that happens across the platform is part of the audit logs, every action. So let us go ahead and look at all that we did and list the universal secrets. So, every action that you perform on your external vault,

really everything that happens across the platform is in the audit logs and auditors and administrators will use this to make sure that they understand all the actions that have been performed, as well as to make sure to look for anomalies or suspicious behaviors. They can also integrate external SIEM systems, Elastix, Planck, Datadog to make sure that they can then perform analytics and understand what is the work that's being done

on these walls. So again, to everything that I've showed you thus far, by the way, our platform is highly extensible. So everything that I showed you that I did on the console can also be done using our CLI, our API and our SDK. So you can automate this, use IAC for automation. Our platform lends itself to that.

So just to summarize, we started by showing you this unified view of our universal secrets connector, our multi wall governance, where you can view all the external walls that you're connected to, that you're working with. You can see all the secrets that are being rotated and managed by Achilles. I also showed you how easy it is to add an external vault, work with it,

just the same as you would in the console of your third party vendor. We rotated some secrets. We looked at very granular access control. And last but not the least, our audit logs, which gives you insights into everything that's being done with our multi world governance solution. So I hope you all found this helpful, and thank you, and over to you, Suresh.

Thank you, Wani. That was a fantastic demo. And as I showed in the slide just before the demo started, we were able to see unified visibility, creating a new secret, adding new vaults, rotating those secrets, RBAC and ABAC, as well as governance and policy. There are secrets visibility vendors out there. But the reason the product is called multi world governance

and control is it is not just the visibility that matters. It's what you can do with it. The governing and controlling of the secrets is what ultimately adds business value on using and getting the most out of your existing walls as well. That was a fantastic demo again, Mani, thank you for your demo today. So if you want to see this product in action in your

environment, please request a demo. We'll be happy to tailor a demo for your needs, and you can request a demo from the website itself. If you want to see the other sessions in the series, you can find it in our website too. That brings me to what the next session is. We talked about the Achilles platform. The next session that we will have is on certificate

lifecycle management. To register for the series Identity Security Unleashed for the AI era, just go to the Achilles website and you will see the registration link at the top of the page. Suresh and Vaani signing out and please give multi world governance a try. Talk to you soon. Take care. Bye.

Episode 4: Chain of Trust

Hello, and welcome to the latest episode of our series, Identity Security: Unleashed for the AI Era. In today's session, we are going to talk about a modern approach to PAM with Akeyless. Privileged Access Management is a critical aspect of cybersecurity, and it has warranted changes over the years. Today, we are going to talk about what changes

have happened in PAM, why do we need a modern approach. And we are not just going to talk about the product, we are going to demonstrate it. And I have with me Netser Heruty, Director of Solution Architecture, who's going to showcase the product as well. Now let me jump right in to introduce the product before we go into the demo.

So before I talk about Privileged Access Management offerings from Akeyless in more detail, I want to remind you of our platform announcement, which was the first of these sessions in this episode series, in which we introduced the Akeyless platform and also announced the AI Agent Identity Security capabilities. In this, you can see that, Akeyless is a platform designed for machine identity security,

AI agent identity security, and human identity security. In today's presentations, we are going to focus on Privileged Access Management, which is the highlighted portions of the platform, which is privileged AI agent access, modern PAM for vendor, contractor, and machine access, as well as zero trust application access. Now I have used the term modern PAM in the title of the presentation.

So what exactly is modern PAM? I've taken the liberty to put together this, AI assisted image to help explain this to you. Essentially, think of PAM as three generations. The generation one, which you see on the left, this is the initial phase of PAM. It was designed for traditional IT environments. It's centered on securing privileged access on on premise

setups and legacy systems often through basic vaulting and manual controls. While effective for its time, it lacked scalability and struggled with complexities of modern distributed infrastructures. Then came Gen 2.0, which is cloud compatibility coupled with session management. As organizations migrated to the cloud and adopted newer

systems, PAM evolved to support hybrid environments. This phase emphasized human-centric access with features like session monitoring and management of static secrets. Now, however, it still relied on persistent credentials, which could become vulnerabilities if exposed. Now automation improved, but the focus remained narrow, often overlooking the growing role of non-human identities.

This brings us to the modern approach or what we call the Gen 3 approach. This is PAM that includes humans, machines, and AI agents with zero standing privileges. Today, it represents a paradigm shift. It expands to secure not just humans, but also machines and AI agents, which now constitute a majority of identities in cloud data centers.

According to third party insights that we have seen, it's about 85% of all identities that need to be managed out there. So this has become more important than human privileged access. Key requirement, of course, is ZSP or Zero Standing Privileges, where access is granted just-in-time, and secrets are ephemeral, rendering them useless if compromised.

This phase demands adjustments to systems for dynamic secretless authentication, ensuring compatibility across on-prem, cloud, and legacy environments while minimizing risks from standing privileges. This brings us to our platform itself, our 3.0 vision. In this slide, you see our commitment to secretless. Zero trust access instead of a developer or a bot having a

password that lives for a year. We use just-in-time permission. We create a dynamic secret that is born when the task starts and dies when the task ends. By enforcing zero standing privileges, we ensure that if an attacker scans your environment, they find nothing to steal. They are on always on keys because in a world,

the most secure secret is one that doesn't exist. Now, to more capabilities of our PAM platform, of course, another piece of the puzzle is solving the multi-cloud tax. A PAM product shouldn't mean managing multiple tools across multiple cloud environments. We unify it under a control plane. We have built it to be frictionless for people who actually use it, whether your team is using a web portal,

a CLI, a browser add-on, the security policy remains identical. And, of course, there is automated enrollment. As you scale your Kubernetes clusters or cloud databases, Akeyless automatically wraps them in your security policy. You get comprehensive session recording and auditing across every environment without having to manually configure a single gateway. It's total visibility without the traditional operational headache.

And enough of me talking about the product itself. There's no better way to experience the product than through a demonstration. And I'd like to invite Netser, our Director of Solution Architecture, to now show you the product in action and also show you some of the key capabilities that we discussed as a part of this introduction. Netser, on to you.

Thank you, Suresh. Today, I would like to show you in this demo of our Secure Remote Access platform, the SRA solution, those exact modern capabilities that we just highlighted. As a modern PAM solution, you can imagine as and we've just mentioned these, there are three main pillars of value proposition that we're giving you.

And I believe at least two of them could be agreed that are more expected or more of a commodity around different PAM solutions, which have to do with the zero trust aspect, which is almost a given by now that you're expecting the end users, the ones that are actually leveraging this privileged access solution to stay in the dark, to have zero knowledge of the secrets that are

being used or the passwords that are being used to facilitate their connections. They should be able to do their job without being exposed to what led them there. The second aspect is the monitoring, the session recording, the ability to check the compliance boxes and account for the auditing perspectives to both, let's call it,

intimate or alert end users to think twice before they do anything undesired, but also to be able to retroactively analyze what really happened, like forensics. The most important piece that the modern aspect introduces here is the zero standing privileges. It's what we call the just-in-time aspect. Because if you've done the two other aspects very well,

what you're leaving yourself vulnerable to is the ability of the secrets that were used by this agent with one solution or a Bastion implementation with another solution, they would always be exposed at some point in time to a secret that is able to establish a connection. If that secret is static, then you're actually going back to having a secrets management

problem where static secrets, as we all know, could leak, could be bruteforce, could end up in the wrong hands for whatever reason. And we want to double down on this aspect and make sure that it becomes not an optional but a foundational aspect of privileged access that it's established upon not just rotating credentials, which is a good start, but even what we call dynamic identities,

users that are provisioned just-in-time and then revoked, taking your security posture to the very top in terms of making sure nothing even exists that could leak to begin with. So let's take a couple of examples. Have the demo circle around, I would say, three main use cases. Let's start with Windows. I believe a Windows Remote Desktop Protocol, the RDP,

is a very common use case, especially for somewhat more legacy environments that had to develop a lot of their apps maybe over a decade ago, very .NET-based and active directory based, and the need to be able to connect to those environments securely without letting the end users know their passwords is key. And the ability to do it through Akeyless is relying on

one of two options. You have a local Windows users approach that leverages the users created on a specific computer or server. But the more common or desired solution for most customers would actually be leveraging domain users, that are created at the active directory or some OpenLDAP implementation, and those allow you to connect to a variety of servers across

your domain and leverage either literally a temporary domain user that is created just-in-time, which is quite an advanced use case and could be very relevant for vendors. Right? Think about it. For zero trust access, Oftentimes when you're working internally, you would have your own static credential or static user,

which in Windows means a lot because you would keep coming back to it. You would save files on your desktop so that you could be able to continue working on something. But if you want to allow some integrator to do some very specific work on said server that's running on your production, you don't really want them to have or you don't need them to have their own personal user for that environment. And for that, you could leverage an implementation of an LDAP

temporary domain user. So it would allow you to connect through this temporary domain users from your active directory onto a computer or a server on the domain. This could be done in a way that even allows you to configure a custom delay so that the preparations for the new temporary credential are done and are in sync, not from the active directory domain controls onto the

different servers. And then if I were now some remote vendor and I want to connect into here, I can do this from my own computer leveraging the Zero Trust portal itself, which is a web endpoint. I had use cases that I've heard in the past where this ability were able to spare organizations the need to provision computers, their own company computers to external

vendors that before that that was the way they enabled them to gain access to internal systems. Whereas now, they could do this even from their own laptops having gained some IDP integration. This is all always going to be based on some identity provider with SSO using protocols such as SAML or OIDC against your Okta or Azure Active Directory Entry ID. All of those are supported.

And then for the dynamic use case, as you can see, this can take more time because a new Windows profile is actually being created. That's very much a I think for those of us who know Windows, somewhat of a some sort of a pain that we all accept when we first provision or first create this profile. But for your internal employees, for your end users, while this is loading,

they would never accept on day to day operations to have to have this temporary user being created for them each and every time. Back here, you're able to see where you have fixed user profiles where you don't require a temporary credential that would be more relevant for external vendors that just need to do this one thing, rather some continuous project where you're keep coming where you keep coming back to this server to continuously

configure it, or if you're an internal employee that require this privileged access. But, of course, we still wish to keep you in the dark so you get the operational advantage of being able to keep coming back to your environment or your desktop, but you're unable to know the secret itself. And it could leverage one of two modes, either to have it auto-rotate.

It could be done so that as soon as this session ends, the secret always rotates immediately as soon as it terminates. Or we could even have a fixed user mode with elevated permissions. So right now, what you're seeing is that I was able to log in. It's behind the scenes. This could have either been based on a rotated secret for this user that is fixed,

and you've seen the username when I logged in, or it could be where that user has its own permissions, and nothing changed, or you could have a typical standard user that is able to log in here. But when they go through the SRA flow, behind the scenes, their permissions actually get elevated just-in-time, for example,

by adding them to the domain admin group or a local administrators group for the server, and that would allow them to now do privileged things on said server or environment. And while, as soon as the session terminates, those permissions get revoked. So there's a different aspects of just-in-time that allow you the flexibility of both satisfying your end users that

would obviously wish to have their own profile set and being able to work with tools that they're familiar with and not have to wait for a Windows desktop to be established for them each and every time they log in for the first time. But on the other hand, for those remote vendors that we mentioned, you have a lot more likelihood to want to be able to give them something that is literally just-in-time where the identity

itself, the username itself is created and then revoked. All the sessions are recorded and are issued later or output into recording files that you can upload to different data repositories or cloud buckets. And with that, we also need to understand that beyond the Windows examples that talk about all sorts of secrets, dynamic secrets, rotated secrets, the elevated permissions,

there are additional forms of just-in-time that could be used, for example, with SSH sessions. SSH sessions that allow you to connect to primarily Linux servers can leverage a very unique setup that is based on SSH certificates, where, essentially, Akeyless leverages its capabilities with respect to having a KMS capability to also become a private CA that issues certificates, SSH

certificates, not for PKI, not for TLS, rather for SSH connections where the public key is distributed across the different servers in a single public key approach so that you could have Akeyless sign those SSH certificates is an interesting just-in-time concept because it's taking the idea of a CA, taking a public key and distributing it to a variety of servers, primarily Linux, and allowing you to

issue very short lived SSH certificates that facilitate access to those servers and would expire typically within a matter of a minute or so. It's something you could configure, but the recommendation is to keep it very, very low. So even though we're talking about a situation where the end users don't have, the read permission on such secrets, they cannot see the SSH certificate that was used.

Even for the Akeyless gateway, which is the way we sort of instrument and facilitate those connections, even for it that can read or obtain such credentials, such certificates, the certificates would be expired within a matter of a minute or two, and you will still be able to make use of that session because SSH doesn't terminate it when the certificate expires. It waits for an idle time out or for you to close it.

Now a good example here would be to leverage this SSH certificate into a Linux box that I have running in one of the cloud providers. And you can see that in this case, again, leveraging just-in-time, the session recording here is not applied in the same way. It's actually going to pick up on all of my keystrokes,

and it's going to record both the inputs of what I write and the outputs of what comes back. So it would allow later or actually at real time to stream those session transcripts or logs into your favorite log management or SIEM solution, so that you could also have alerts for whatever is being done on those sessions configured for the SOC team or directly through

your log management environments. This means that everything I do here is now on the record, and I know as an end user that I should, again, think twice before I do anything. But we still know that it may very well be that some of the end users would care deeply about being able to continue to leverage the tools they know and like and wouldn't always be keen to switch to a portal access in a

web shell, essentially. Even though this is a very robust capability and especially relevant for those vendor access types of use cases that we've mentioned, for your internal teams, we typically look at a successful PAM implementation as something where you can take the users onto this platform with the minimal resistance. Right?

Because I believe it's it's no secret, and we all know that when you make the operations hard for the end users, you're eventually going to lose realistically. So it's very much something that we are keeping in mind and putting an emphasis on, thinking how could we onboard the end users in a way that would be the path of least resistance.

So for that, we always have the capability of using also what we call the Akeyless Connect. Akeyless has a CLI also for our secrets management capabilities and others. And based on that same utility, we also have the connect mode where you're able to suggest to select sorry, the target that you wish to connect to. In this case, I'm going to show you the exact same one that I just connected

to from the portal locally and the gateway through which you want to get the access. What's happening behind the scenes is this Akeyless Connect, Akeyless CLI always has some pre-configured profile that it's working with. I'm currently using my default, which has, my IDP Okta using SAML behind the scenes so that when you first enter it,

it would first redirect you to the IDP to make sure that you're still in the company and should be enabled that sort of permission or entitlement. I believe I'm already logged in, so I'm not sure it will actually pop that up. Yes. I'm already in. And then it's actually issuing this SSH certificate, connecting directly to the target,

and now I'm in a completely native terminal experience inside a remote Linux box in a session that is being recorded. And I can do everything normally, including copy paste, SEP, all that is required. And from here, you're able to also get a get a glimpse of what that implementation of supporting SSH certificate looks like if you wanted to take a look at the EDC SSH folder where

we have the SSHD config pointing to a trusted CA key, which sits in a file right here. And this could be the exact same public key similar to what you do with PKI CAs where you have a root CA that you distribute to all the employees. You would have this public key that you distribute to all the servers, and you could still segregate access based on different

claims or principles, that different groups or end users would need to be able to access different servers. All of those capabilities are supported while keeping the operational hustle to a minimum by being able to distribute this one public key. Beyond SSH, which is a very important use case, the Akeyless Connect actually supports all sorts of CLI based or textual based interfaces,

which also extends to KubeCTL access to Kubernetes clusters. It also works with databases that expose a CLI, which are the majority of those. And, similarly, we also have access to similar databases from this console, and you can see you have the selection between a CLI connection or web interface. But I do want to quickly focus on the Kubernetes

example, where just like I could, again, end up in a support shell environment, which makes it super easy for anyone, again, outside the organization such as vendors to come in here, see all these tiles, gain access to where they need to. You can control all of that as the admins with different permissions that you gain in SRA, including the ability to request access,

have a workflow triggered against whichever platform you prefer, and have someone approve it and only then grant them the access to use this. But the more UX user experience aspect that is truly super important when it comes to successful implementations. Alright. So if I want to use Akeyless Connect also to connect to Kubernetes to a more modern stack types of production

environments, I could leverage Akeyless Connect and have it connect to a specific namespace against a specific Kubernetes cluster endpoint through the gateway using some dynamic secret, which behind the scenes, that dynamic secret could either be leveraging an existing similarly to the Windows use case, an existing service account and temporarily issuing a secret for it, or it could temporarily elevate its permissions,

or it could create a temporary brand new service account behind the scenes associated with the corresponding role binding or cluster role binding and allow me to gain access in an audited fashion to this cluster through the terminal. But you'll be able to see in a second that when I'm in this session, I'm now able to run kubectl commands,

or maybe I'll do something a bit more generic to see the different namespaces that I have running here, but it's still leveraging this CLI context that I'm in, using some specific tool. And we know we've worked with many customers on these implementations. They want to be able to leverage the tools they like. Some use Lens. Some use Rancher, K9s.

There are different implementations of what we call thick clients, and for that, we actually have a way to have them continue to use the tools they like. For databases, it could be DBeaver. For the Windows environment, it could be the RDP native. And the way this works is always based on SSH port

forwarding or SSH tunneling, and we have different modes that instrument it. The more technical one is what I'm going to show you right now, and the more UX friendly one that I would like to have a full session for you to focus on would be the future coming desktop application, and we'll get to that in a second. But in here, I'm able to run this very same

command, but have it open a tunnel with this Kubernetes. And then this is actually no longer the interactive session where I have to run the KubeCTL commands. This is now opening a local port in my environment that I could leverage with any of my thick clients. So for example, I now want to leverage this kubeconfig with my native

KubeCTL client that is on my desktop. What this points to before I use it is just a server which is allegedly running locally on this port, which is the same one I provided here. And with this in place, there's nothing real else really in here. I am now able to run this command and actually track

any of those API calls and record them from the API server of Kubernetes. So I saw that an API was gotten to list or to get the namespaces. If I wanted to get pods in a specific namespace, it would also print it and show it in the logs. And that would be a very quick and easy way to leverage thick clients. I demoed the most basic one of Kube, just the native KubeCTL,

but this could extend to different tools like K9s and Lens, and others. But the real promise or the real goal that we have to take this further would be to leverage a native Akeyless desktop application that is already in a beta version that would allow you, even for the less technical users,

to set up something like a tunnel to be able to click on connect to it could be your DBAs wanting to connect to their databases or your Windows admins team that wish to use their native RDP. They could just click from the desktop application, and all that SSH tunneling magic would be done in the background so that they don't have to establish it. It's just being done for them.

I believe this is the primary use cases that we wanted to demo to you today with respect to our Secure Remote Access solution. We hope you enjoyed the demo and that you'd be interested to learn more. Thank you very much. Thank you, Netser. That was a fantastic presentation. And, just to remind us on the modern approach to PAM, of course, this PAM unifies, you know,

Privileged Access Management for humans, AI agents, as well as machines. It's built for the modern DevOps and cloud environment. And, also, it is based on zero standing privileges and just-in-time access. And, hopefully, you got to see some of those in action with Netser's presentation. As you know, this session is a part of a larger Identity Security:

Unleashed for the AI Era webinar series. There are more exciting sessions coming up. We have only seen a part of the platform. We are also having special guests from across the industry. Coming up next, we will have an opportunity to talk about AI data encryption and Key Management. We will have a special guest, Todd Moore, the Global VP of Data Security Products from Thales Security

in it as well. And, of course, I will join you again with, one of our other, solution architects, Dr Connor Mancone. And this time around, we will showcase, encryption and Multi-Cloud Key Management. Thank you again, and I'll see you in the next episode.

Episode 5: Mission: Accessible

Welcome back to the continuation of our episode with regards to AI agents and data protection, within the identity security suite. So today with us, currently with Todd Moore, Global VP Data Security Products with Thales. Hey, Todd. How are you? Hey, Oded. Thanks for welcoming me into your studio. It's great to be here today.

Good to see Of course, as always, Todd. So, today we have a nice and very good, you know, conversation within regards to our joint offering to the market with Akeyless, Thales Altogether, and CipherTrust. And we're going to talk specifically about AI agents as well, and how our Secretless AI is actually being elevated

together with the CipherTrust Manager to provide better protection for encryption keys. But before we start Todd, let's review very quickly with our offering of the CipherTrust, and I'll let you lead on this and talk about the Akeyless part in it. Sure. Thanks, Oded. I mean, Thales has built out a pretty broad data

security platform. We call it CipherTrust. It really is, you know, able to allow you to centralize your key management and policies across a whole bunch of different use cases. And so as you think about what you're doing in terms of data protection, it's finding that data from data discovery and classification and then applying the specific controls

that could be tokenization, masking, or even encryption, both in file systems and applications, and a lot of different environments. One of the things that our customers have been asking for quite a long period of time was, you know, you do centralized key management. That's been really our bread and butter of what we've done within our platform across all these different environments,

whether it's on-prem or in the cloud, hybrid, or different types of environments. They said, what about secrets? I mean, this is a path that the malicious bad guys are getting into the organization through secrets. And why aren't we helping our customers manage secrets just like encryption keys? And, this was a need.

There was a gap within our portfolio, Oded. And as you know, well, we found Akeyless. You guys are a world-class market-leading solution when it comes to secret management. We've taken that solution and we've embedded it inside the CipherTrust data Security Platform and it really has expanded everything we've always done around policies, around managing keys.

We've applied all that rigor and all that life cycle to secrets management and really excited to be working with you guys. I think it's been two years, I think, Oded since we first met and did the integration into CipherTrust, but we're really excited about offering that as part of our platform and our portfolio. Yeah, definitely. And thank you for reviewing that and to the point.

I think those were a great two years that we're celebrating with approaching the market with this joint offering, and having this great combination of our own, you know, Akeyless DFC, the different fragments, the ability to protect those secrets, then to enforce and enhance it together with the CipherTrust offering by having one of our fragments to be within the CipherTrust and potentially also protected with a FIPS

level four HSM of Thales. Yeah, yeah, that's the value proposition. I think another value proposition for folks listening to this is as you have a data security platform and you have a secrets use case, you flashed it up there, Oded, but you know, it's part of our management console. You can just click and say, I need secrets management. It allows us to jump really into the Akeyless service and,

you know, it's from one centralized management platform. So that's one differentiator. The others, as you just said, we can root the customer fragment inside an HSM and it really gives you that high level of assurance from a certification perspective, but also gives you ownership to know that if you, you know, delete that customer fragment,

that you removed information or shredded information, within other environments. So a lot of control for customers and it also helps from an auditing, regulator point of view to know that you actually can manage and have ownership of that data and of those secrets through that customer fragment management. Yeah.

I think it's also good to remind our customers, our viewers, that actually we've built something that will be very easy for existing customers of Thales as well, right? Because of the way that it is embedded, it's already embedded within the CipherTrust. All they need to do is just to click and start using it, obviously, commercial conversation that requires. But basically, in terms of the technicalities around it, right?

The Akeyless gateway is embedded within the CipherTrust that allows a very quick transition of ways to start using it, right? Absolutely. Yeah, you're getting into a little bit of detail there with the gateway, but it's embedded there. The way that we sell our data security and I think a lot of companies are organizations don't buy every use case upfront. I mentioned a bunch of them quickly on a previous slide.

They buy one use case. It might be, I don't know, K MIP, key management interoperability protocol, maybe it's file encryption. And the idea is that you start small and then once you have a platform established or you have that CipherTrust manager there, then you can pick different use cases. So, Oded, to your point, you know, you start small,

you enjoy, get the system up and running, you say, hey, I need secrets management. You click a button and there you go. You're off to the races. So, I do think there is value in having a data security platform and the ability to pick and choose what use cases you want to use. Again, really appreciate Akeyless and what you've done with us in terms of embedding that inside our platform.

It's been awesome. Definitely. So, you know, it has been like few minutes now, Todd, that we haven't discussed AI. So, part of the rules of the ceremony, we must talk to it. And I, you know, I was wondering, all of these sessions of episodes that we're running and different sessions and interviews that we're having,

very much focused on identity security. One of our theses is that with time, identity security in the realm of data protection is becoming closer and closer with time, given that everything identity requires a healthy cryptography behind it or cooperating with it, right? Because PKI, machine identities,

everything is around high level of cryptography and high level of protection of encryption keys and so on and so forth. Now, with regards to AI and data protection particularly, how do you see that market and those concerns with regards to data protection and AI agents? No, great question. You mentioned identity and encryption and I think we've seen a convergence of identity and data protection for a long time.

We'd like to call it internally identity-based encryption, but it's really, you know, there is this correlation between how you're protecting the data and who has access and why they have access to the identity. It can be human or non human machines like you said. But at the end of your questionnaire about AI in general, I believe that no matter what AI, whether it's Agentic, LLM, models, training, you know,

prompts, you know, it all comes down to the data and managing your data. And one of the things that we're seeing with AI and the proliferation of AI is that AI is creating a lot of unstructured data. It's creating a lot of data in general and it's dropping that data all over the place. It could be agenetic AI working on your behalf,

coming together and creating new documents or videos or photos. And it's dropping this data in a lot of different environments, could be in SaaS applications, cloud environments or even on-prem. And you really need a way to come along and clean up all this AI new data that's being dropped everywhere. And I think by tying the identity into it, you now know who and where it came from.

That's the data lineage piece. And then once you have those pieces of data, you can start doing some risk calculation, you can decide where did it come from and then you can start putting additional controls to make sure you're managing all this new AI, Identical AI data that's coming and being created everywhere. So, it's a problem for organizations, Oded.

I think you know that, that people are losing control with AI. One thing that we like to say at Thales is that AI is becoming the new insider threat. That, you know, AI has really gone off doing things that we like to our benefit, but it's also creating a lot of attacks or vulnerabilities within our organizations as well. Don't know what your thoughts are on this.

So, on this, with having AI to be kind of the new insider threat, that kind of thought, We reviewed beforehand one of our solutions to AI agents specifically is called Secretless AI within our suite. Secretless AI basically means to have the AI agents or to decline the possibility, right, of AI agent to somehow expose its own secrets, right?

We say secrets, we mean every different type of secret, meaning also the authentication ones, like the API keys, the SSH key, the database credentials, right? That we don't want any option for the AI agent to reveal those secrets. We've seen those attacks that have been researched and proven already that AI agents are able to expose those secrets within prompt injection and things as such, because they are aware of their identity,

they are aware of their code. But now there's another concern, which is one of those secrets is actually an encryption key, right? Now encryption key can also be revealed, and AI agents that are leveraging encryption keys and have access to those might find themselves actually exposing. Now we need, obviously, to somehow decline this possibility or to make sure that we're protecting versus that.

Now, within Secretless AI, having our DFC, right, our technology of using those different fragments, those separated fragments that are created as such, they are distributed. And one of the fragments is kept on the customer side, where the whole point is that eventually the process that runs the encryption doesn't have the whole key as whole, right? The different pieces are not being constructed ever.

Now, the beauty of that joint offering is that this particle, this customer fragment that the AI agent doesn't have access to, it doesn't have access to all of those because actually the encryption takes place using the SDK that does not construct the key, the fragment itself within the customer hands is kept within the CipherTrust. So by that, strengthening the CipherTrust platform to provide AI data security to encryption keys within

those processes? Absolutely, Oded. I think it's a great roadmap, a great expansion of what we started with, with your secret service, putting the customer fragment within the CipherTrust in a FIPS one hundred forty- three, level three HSM, protecting that on the customer behalf. As you have evolved,

as the Akeyless has evolved your technology to AI with the secretless motion and, you know, this new offering, we're doing the same thing basically. We're offering that root of trust and giving the customer the ability to say, hey, I still have ownership of my data and I'm doing that through an encryption mechanism and I'm doing it through, I guess, a separation of fragments where one fragment is always owned by me.

You got to have that fragment before you can reconstruct the data. So yeah, I think it's a powerful approach. I think it meets auditing and regulatory requirements but also just gives, you know, CISOs the ability to sleep well at night to know that they have a piece of information in a FIPS container that's really protecting that data no matter where And protecting versus the new threat, as you mentioned,

the internal threat that we have within organizations. Todd, thank you so much for joining us in this session. Have a good time, good fun. I hope you enjoyed that as well. I hope to see you in our next engagement and webinars and sessions that we are going to have. Thanks, Oded. It's always a pleasure. It's great seeing you.

Look forward to catching up again soon. Take care now. Thank you so much. Bye now. Hello, and welcome to the latest episode of Identity Security Unleashed for the AI era. I hope you had a good time watching the presentation between Oded and Todd Moore, the Global Vice President of Data Security Products at

Thales. Now that we are discussing data security products, I figured that it might be a good one to also introduce you to Akeyless offerings in that space. Now this is a part of a series of episodes that we have been going through to see the entire platform that Akeyless offers. What we have seen so far is that Akeyless is a platform that is designed for machine identity security,

AI agent security, and human identity security. But underneath all of it, the section that I just highlighted, you can see that we are built on a strong cryptography foundation. We call it Akeyless DFC, Distributed Fragments Cryptography. And this essentially means that the customer is always in control of one fragment of the encryption key.

So even Akeyless, as a cloud provider of all these security capabilities that you see here, will not be able to access your data. You, as the customer, are the only one in control of your data, while you get all the benefits of SaaS cloud native scaling, while you have control over your security. Within this specifically, we have several capabilities, including encryption, tokenization, virtual HSM,

multi cloud KMS. And today, we'll deep dive into some of those capabilities and show you in action as well. Now, let's jump into why enterprises need the cryptography foundation that we just talked about. As we scale across environments, managing security silos becomes the biggest risk. The slide shows why a unified multi-cloud KMS is

essential to restoring control and visibility. First, it's about security and compliance. By decoupling keys from one cloud provider, we create a multilayer defense that ensures data sovereignty and delivers a single, audit-ready view to meet regulatory requirements. Second, it's about operational agility. Security can't slow innovation.

By automating the key lifecycle and providing a standard path for database encryption, organizations can keep security moving at the speed of DevOps while reducing human error. Finally, it's about reducing complexity. Many teams today manage separate key systems across different cloud providers and on-prem environments. Consolidating these into a single unified platform eliminates these silos, reduces the manual overhead,

and cuts hidden costs. Ultimately, it's about moving from fragmented control to a single source of truth for every encrypted asset. So let's now talk about how Akeyless can help you with this. Akeyless transforms this theory of multi-cloud security into an operational reality. We do it through three core work streams that you see in these bullets. Let me talk about the work streams,

and you will be able to map it to those bullets as I talk about it. The first is unified cloud governance. We provide a centralized FIPS-validated KMS that manages the entire key lifecycle across every cloud. Using our virtual HSM, which we can even integrate with your existing physical HSMs, we automate key generation and rotation, ensuring that you never have unmanaged or stale keys sitting in clouds like AWS and Azure.

Second is modern data protection. We enable encryption as a service. Instead of developers building their own crypto, they use our APIs for application-level encryption and tokenization to protect PII like credit card numbers without breaking the database schemas. For legacy or high-volume databases, we provide TDE and KMIP support,

securing your SQL and MongoDB instances with zero code changes. Third, secure DevOps delivery. We extend our protection into the pipeline with automated code signing for your builds. And finally, beyond all this, I want to reemphasize this. I covered this at the beginning of the presentation as well, that we are powered by the Akeyless distributed fragment

cryptography technology, a patented technology that only Akeyless offers. With this zero-knowledge model, the full key never exists in one place, not even in our own servers, providing with a level of security that traditional vaults and other capabilities cannot match at all. Now that we have discussed all these capabilities with

Akeyless, why not see it in action? So I'd like to invite Dr Conor Mancone, a Principal Solution Architect for Akeyless, who is going to show the product in action. Conor, on to you. Hi, I'm Dr. Conor Mancone, and I'm really happy to talk to you about how our multi-cloud KMS solution is helping businesses protect their data.

And fundamentally, this is kind of the issue that we're helping companies solve, and this is a very common problem for corporations these days as they're trying to protect their data because it's just more natural for companies to have their data and their workloads in a variety of places. It was really easy to do this kind of thing when all of your data was living in a single on-prem network,

but now that companies are working on-prem, Azure, AWS, and GCP, and all of the places, you know, it lends itself to data fragmentation, and that's where Akeyless comes in. And that's what I'm just kind of showing here, real quick, to help see the problem. Let's say you have some data that starts off in Azure.

You know, customer data, whatever it is, some important data you need to protect, the natural thing that your engineers are gonna wanna do is encrypt that data using Azure Key Vault. And that's perfectly fine as long as your data stays in Azure. But, you know, as I was saying, it's less and less common for companies to be able to do that

these days when they have workloads running everywhere, you know, their own AWS, their own on-prem, or with a third party, perhaps that is none of these things. And that's where you have the problem because if your data is encrypted with an Azure Key Vault, you know, KMS with Azure Key Vault, then you can't share that. You know, you can't send that data over to, say, AWS or GCP or wherever,

not in encrypted form, because those other environments aren't going to have access to that KMS that was used to encrypt it. Simple as that. You don't have access to the keys, you can't decrypt it. So when you have those cases, which come up all the time, of, Hey, I've got some data I encrypted in Azure, and now I needed to go over to these other services living in

AWS or GCP, really, your only solution is to decrypt it. Send it over, even if you have encryption in transit, like you've already decrypted the data, and then re encrypt it in that other environment, and this creates risks. This is exactly what Suresh was talking about. It creates risks. It breaks, you know, you lose auditability because, you know,

now your data spends some time being decrypted, and now the encryption, the logs of when encryption and decryption happen exist in two completely different systems. And so these data silos that naturally exist between cloud providers and your on-prem environment create risks anytime data has to cross those boundaries, which is just reality.

It happens. It happens to everybody. It's pretty much a requirement these days, so you have to plan for it. And so this is where Akeyless comes in, and we have two approaches that can help companies solve this issue. Number one, which I'll show in just a little bit, is our KMS sync where Akeyless is completely in charge of the keys used to manage your data and it

actually sends a copy of those keys to any of your cloud providers inside of their native key management solutions. So now you've got your Azure Key Vault, and it has a copy of the key that you have in Akeyless, and you have a copy of that same key now shared in AWS KMS. And so this is this now you can start sharing data without having to decrypt it,

which means you get some better protection because you can encrypt your data with a key in Azure Key Vault, send it over in encrypted format to AWS, and then it can be decrypted there because your AWS KMS has an exact copy of that key. So this can enable data sharing and is fairly easy to adopt for teams, and so it's, you know, it's a big win for most companies.

The one disadvantage this does have, this approach is that you still have your audit logs in happens in Azure. Your decryption operation happens in AWS. So you no longer have those. You still don't have those unified access logs, which is really what you want for optimal security and minimized risks.

And so that's why the other approach that Akeyless offers is very straightforward, which is to just use our KMS natively, right, because this is accessible. Akeyless KMS is accessible to all of your workloads no matter where they're running, So your Azure workloads can authenticate to Akeyless using their machine identity, so no access credentials required, encrypt the data, send encrypted data off to AWS,

and then your AWS workloads can similarly authenticate to Akeyless with their machine identities and decrypt it using that same key. And since Akeyless is now the one doing both the encryption and the decryption, all of your audit logs are in one place, and you can make sure you're complying with all the necessary regulatory standards, whatever they happen to be. And so this kind of approach is really, I think, the gold standard of, you know,

how to do these things because Akeyless stays in charge of your data lifecycle. And as we discussed, Akeyless also protects those keys with DFC so that you have full control over your encryption keys, you have full control of your data lifecycles, you have all the auditing all happening in one place, and so you know what's happening to your data everywhere all the time.

And so it's as simple as that, and I would love to show you exactly what that looks like. So welcome to Akeyless. And for those who've never seen it before, we keep track of items, which are things like encryption keys and static secrets. We have access roles, which is where we assign permissions, and users and auth methods controls who can authenticate to Akeyless.

We use a folder-based hierarchy, which you'll see. And right now, I'm looking at my items, and the most important part right now is I have this encryption key that I'm gonna use for the demo. And so these things, since we use a folder-based hierarchy, everything is identified by a name. So this is my multi-cloud slash production key. And just to say out loud,

it would come over to authentication methods. This is the kind of environment I've set up for where I have workloads running in AWS and Azure and GCP and the on-prem world, which for us is covered with universal identity, and so my workloads running in all of these different environments can all authenticate to Akeyless and access these keys using their machine identity,

so no static credentials required. So let's see what this looks like, and I'm going to go very briefly to do a simple demo actually, from my terminal, because that's the best way to do this, and I'm gonna do exactly what I was talking about on those slides. I'm going to work in an Azure environment on a VM there. I'm going to encrypt some data.

I'm gonna send it to an AWS VM in encrypted format, and I'm going to decrypt it there using Akeyless KMS and without having to have any static credentials anywhere. So I'm going to go ahead and get myself logged in. So I'm creating a temporary SSH certificate. Akeyless is doing very good at that, so I can SSH into my Azure machine without needing a private key.

And then I am going to here, I have just a very simple script. We're not gonna really go into the details, but just because all it lets me do is use Akeyless to encrypt some data using that key that we were just talking about, multi-cloud slash production, and it's sending it off to an SQS queue in AWS. And I'm actually gonna go ahead and get AWS credentials using

Akeyless. It's gonna issue me a temporary set of AWS credentials so I can send data to that SQS queue in AWS. Then over here, I'm gonna do pretty much the same thing, and I'm gonna connect to an AWS VM, and on the other end, it's very simple, I'm just listening for messages inside of that SQS queue, and I'm once again using Akeyless to decrypt them using that same key.

And then, again, like I mentioned, I'm connecting to Akeyless using my machine identity, so there's no static credentials anywhere in this whole demo. So I'm gonna go ahead and start up my listener. And then here, I can just send data however I want. So, Azure over here, AWS over here, and Akeyless is providing the encryption along the way. So we'll say, welcome to Akeyless

Multi-Cloud KMS, and it's going to send that CipherTrust to my AWS queue, where it gets pulled down here and decrypted, and that's it. So I'm transmitting fully encrypted data. I don't have to worry about the fact that my keys are siloed in a single cloud provider because Akeyless connects the dots and brings that encryption and decryption capability wherever I need to run it.

So I can securely transmit encrypted data. I don't have to decrypt it, and I keep all my audit logs in one place. And so we can see that too on that last point. I can go ahead, and I'm gonna come find that key we were just talking about, and we even have an option here to view audit logs. And so I can view the audit logs for this key,

and you can see any connection that is making use of this key, and that could be this is my AWS environment is, you know, I can see it using that key to decrypt, and here is my Azure environment, and so I can see everything that's happening regardless of what cloud it happens in. And so this is what companies want. This is what they need to really protect their data

because, again, they don't have to worry about encryption silos, and they don't have to worry about audit log silos, and they have full knowledge of what's going on everywhere. So Akeyless will also help you manage all of your key versions, which is, you know, in order to comply with regulatory standards, you, of course, want to be rotating your keys on a regular basis.

And so you can rotate keys manually as needed, and you can also set up automatic key rotation on whatever schedule you want. And so everything you need all in one place. I also talked about that ability to send keys to the external cloud environments, and I think that's worth a quick demo as well. And so that happens right here in the provisioning tab.

So you can go ahead and attach this key to some external cloud environment, which is what I'm gonna do. I'm gonna go ahead and send this key up to KMS. And it's not already so I'm gonna just show you that I'm gonna send a new key up. So let's I'm gonna call it something like go for multi cloud. Okay? So, you know, there's not a key I have in here yet,

but I'm gonna come back to Akeyless. I'm going to set up external provisioning for AWS. I already have the connection set between Akeyless and AWS, and so I just have to give it a name for multi-cloud. And so I'm gonna go ahead and attach it. And so we're good to go. And the next time that key gets rotated,

it'll automatically send a copy of that key to AWS. And here it is, ready to go. Shows up in real time. Every time there's a rotation inside of Akeyless, it'll automatically push a copy of that new key to whatever cloud environment you need. In this case, I'm showing it for AWS, but it could just as easily be Azure, GCP, whatever.

And so, again, this is that second approach where ideally you use Akeyless KMS directly for unified audit logs, but you can also have Akeyless manage your keys inside of your external cloud environments for the cases where that's simply easier for your engineering teams to consume. So, however you want to do it, Akeyless can help you make sure and unify your KMS strategy to decrease risks,

keep your data encrypted, and also ensure that you have full audit logs to keep track of what's happening where with your data, which is what every company needs. That is fantastic. Thank you again, Dr. Mancone, for this presentation on Multi-Cloud KMS in data protection technologies from Akeyless. As I said at the beginning of the presentation, this is a part of a series,

Identity Security Unleashed for the AI Era. All of the sessions are available on our website for you to watch. We go through all the elements of the platform, and we also have thought leaders and CIOs from various industries participating in those as well. You will learn a lot about managing the entire lifecycle of secrets, NHIs, and identities all in one place through a comprehensive platform that does machine

identity security, AI agent identity security and human identity security built on the cryptography foundation that we discussed today. I hope to see you in the next session. Thank you all. Talk to you soon. Bye.

Episode 6: For Your Keys Only

Hello and welcome to the latest episode of Identity Security - Unleashed for the AI era. Over the last few weeks, we have been sharing various aspects of the Akeyless platform that is built to address the emerging threats and challenges associated with the rise of machines and AI agents. Today, we are going to spend time introducing you to managing the entire lifecycle of certificates with the

Akeyless platform. Just as a reminder, Akeyless platform has three core capabilities. It's a machine identity security platform that includes secrets, PKI and certificate automation, workload identity federation, and multi vault governance. We have AI agent security capabilities, which we announced as a part of the first episode of the series. Please do watch that keynote.

And, of course, we also have human identity security capabilities where we introduced you to modern PAM, the generation three of PAM. In today's presentation, we're going to focus on what you see highlighted on the slide. It's PKI and certificate automation. So let's jump into why we need a modern approach to managing certificates. The first challenge is volume and visibility.

It's a numbers game. With the explosion of AI agents and machines, most teams are effectively flying blind. You simply can't manage the sheer volume of certificates manually anymore. It's impossible to keep up. The lack of visibility leads directly to risk. When your engineers are stuck doing manual updates,

human error is inevitable. That means expired certificates, sudden shutdowns, a nightmare for governance and compliance. The third is cost. The traditional tools built to solve this are often heavy, expensive, incredibly complex to deploy, and they just weren't built for the speed of the modern DevOps era. And finally, this is an important piece.

Don't ever let a certificate lifecycle management vendor tell you that it has to be a standalone product. We call it the silo problem. We need to stop treating certificates like they are special. In modern cybersecurity, certificates, SSH keys, API tokens, passwords, all fall under the umbrella of secrets and machine identities. You'll find the innovation insight on machine identity

management from Gartner on our website. Check it out to see where CLM and PKI fall. Certificates share exactly the same lifecycle requirements, generation, storage, rotation, revocation. Building a tool that only does certificate lifecycle management creates a silo. Separating certificates from the rest of your secrets management strategy is inefficient.

Certificates are just secrets, just like credentials and keys. They have the same lifecycle as those. You shouldn't be forced to buy a standalone tool that only solves one slice of the problem. You need an unified way to manage all your machine identities. So in addition to these challenges that we just saw, we also have to prepare for the forty seven day certificate era. For years, TLS certificates have steadily shortened in

lifespan from five years to eight hundred and twenty five days, then to three hundred and ninety eight days. In the latest certification authority and browser forum, it has moved to forty seven days, and this represents the most dramatic evolution yet. The industry is moving to this lifespan, and it will happen within the next few years. Think about what it actually means for your team.

Right now, you renew your certificate, say, once a year. Soon, you'll be doing it eight times a year. If you're struggling to manage certificates manually now, imagine trying to do it when the workload explodes to eight hundred percent. You physically cannot hire enough people or update enough spreadsheets that fast. So this isn't just a policy update. It's a forcing function.

The era of tracking dates is over. If you aren't fully automated by this time, you aren't just inefficient, you're offline. Now let us see how Akeyless can help you with this. With Akeyless, we eliminate the manual grind by automatically issuing, renewing, and provisioning certificates directly to your endpoints. Whether you need a private CA with PKI as a

service or seamless integration with public CAs, our platform unifies it in one view. You maintain total visibility through comprehensive logging, tracking, and notifications, ensuring you never miss an expiration. Crucially, all of this is backend by secure storage using our patented Distributed Fragment Cryptography encryption, DFC. It's something worth looking up on our website on how it

technically works as well. This is designed not just to keep you secure, but keep your certificates within your control and is also designed to be quantum resilient, guaranteeing your data remains secure today and against future threats. In addition to these, Akeyless delivers a broad support for all your certificate needs covering everything from standard TLS

and PKI to SSH code signing custom IoT use cases. We provide a built in private certificate authority and integrate directly with public CAs to centralize your operations. But we go beyond simple issuance. We fully automate the entire lifecycle, rotation, renewal, actual endpoint provisioning, leveraging standard automation protocols like ACME, SCEP, EST.

This ensures that we have total control. Our platform runs continuous discovery inventory across hybrid cloud and environments. It gives you granular analytics and full audit logs while our proactive monitoring sends multichannel notifications to alert you of any expirations long before they can cause an outage. And finally, we talked about this problem,

the forty seven day certificate era. Akeyless automates trust and compliance to run this challenge into a competitive advantage rather than a headache. We provide zero knowledge CLM and PKI as a service for secure hands free renewals where private keys are never exposed. Thanks to the DFC technology that I talked about a few minutes back. This is truly unified platform,

managing not just dealer certificates, but also SSH keys, API tokens, machine identities. And to satisfy auditors, we provide full audit and compliance capabilities with immutable logs that integrate seamlessly into your SIEM tools like Splunk and Datadog. Now enough of me talking about the product and what it does. The big part of this,

episode is to see the product in action. I want to invite Mark Geurtsen, our solution architect from Akeyless, who will now show you the product and address some of the key capabilities that I just shared with you. Mark, over to you. K. Thank you, Suresh. Okay. Let's take a look what we will see during this demo.

What we're going to see during this demo is, how the Akeyless CLM capabilities work inside of our platform and how that works inside a modern identity security platform. So you will see how Akeyless can be a private CA and also how we can integrate with public CA authorities. A major part of this demo will be around how the automation works for certificate lifecycle management,

especially considering the forty seven day mandate. So we will see an example of how this works with a CST pipeline, such as GitHub actions, how this can be done with infrastructure automation tools, such as Ansible. We will also automate a certificate issuance and rotate that certificate to server that already has an extra expired certificate.

And finally, we will also see an example of how we can use Akeyless as an ACME server to integrate with tools such as Certbot. Okay. So here is the Akeyless platform. You can see the different products that are inside of our platform. And for certificate issuance, we have an we have an object called a PKI cert issuer. So a PKI cert issuer is sort of the interface that allows you

to provision your certificates. So up here, I have an example of our cert issuer. So with the cert issuer, you have to choose whether this can be a private CA, in which case, Akeyless will hold the private key or we make an integration with a public CA authority. Of course, the sign key is a DFC key, which means that only you have access to that key.

DFC keys can be of many different algorithms giving you quantum agility in case you want to in case new algorithms are being found that are quantum safe. Certificates can be used for different purposes. So certificates can be used for client certificates, can be used for service certificates, also client certificates. This PKI cert issuer is the object that we actually

interact with, and we control it also has an ACME server available to it as well. The cert issuer determines what type of domains are allowed. Also, it will store those certificates in a particular location. All stored certificates are, of course, encrypted with DFC technology. It controls whether we can auto rotate those certificates and also where we publish the certificate verification list.

So this is the interface that can be used to automate your whole process with. Let's take a look at how we can integrate with tools such as GitHub actions for CI/CD. So Akeyless comes with many different integrations, and one of we have many plugins available. We have an Ansible plugin available, which, of course, can be used for for PKI certificates.

We also have a GitHub actions plugin available, which can also be used for PKI certificates. And here's an example of how you can actually run that. So here's an here's an example of one of those GitHub actions. So what happens up here is you create a certificate signing request, and you then submit that certificate signing request

using the Akeyless GitHub actions plugin to to this PKI cert issuer. You can then keep continuing inside of your pipeline to provision this certificate along with your application. So here you can start running your workflow. So running that workflow and then obtain a new certificate. So now there's a actions pipeline running,

and you we can see the results up here. We can see that we ran the different actions that were required. We generated a CSR. We fetched that PKI certificate from Akeyless, and we can then store that into a file, save that into into the running workload,

and then provision a certificate along with the application. Instead of CI/CD pipelines, we can also do this infrastructure provisioning, so we can do this inside of Ansible playbooks, for example. So okay. So I have an Ansible environment ready. I do have an Ansible playbook available here. Let me show this Ansible playbook. So in this Ansible playbook, we we do the same thing.

We generate CSR. This comes from the Akeyless collection in Ansible. You can run it you can install that with Ansible Galaxy. You generate a CSR, and once again, you can just get a PKI certificate from Akeyless. So when we run this, you can see the different steps that are being taken, and finally,

we we get this whole certificate that's being printed out and can then use that to provision to our infrastructure. And, of course, other tools exist as well to automate this deployment. Akeyless comes with a bit of CLI to make all this possible. So every action you can do in the UI in Akeyless can also be automated using our REST API or CLI, also multiple SDKs. So we also have to get built to generate a CSR in the

platform with different options available. We can also then, once we have that CSR, obtain a PKI certificate where we just provide the PKI cert issuer and provide the required data to obtain this certificate. Okay. So let's let's go through an example of a certificate that's actually already expired and it already lives inside of

Akeyless and go through a renewal flow. So we just saw how this how the issuance flow works. Let's take a look into this renewal flow. Okay. So we navigate to a to a certificate that may have been expired. We have here a machine that's already expired. We can go to that machine, go into a browser, renew, and we see that the certificate date is invalid. So for that, we can go to our certificate,

take a look at our lifecycle capabilities up here. We can see that there's a certificate renewal option. We can also perform revocations. We can download the certificate as well if you want to manually provision. So for a certificate renewal, you could choose whether you want to make use of an existing key in case it already exists in Akeyless, or more common, generate a new CSR and key.

Creating a new key is better and more safe in case your key may have leaked. So when we click on renew, that takes care of the whole renewal process. So what's happening here behind the scenes is that there's a provisioning tab available on this certificate. And the provisioning, we specify where you want you want to place your

certificate, where you want to specify your key, where you want to specify your chain path, and afterwards, you can also provide a post provision command. This is a command that's being performed after you place your certificates in their locations, and this can be used to automate actions such as restarting my NGINX wrap shop, for example. All of this is is, of course,

orchestrated by the gateways since the gateway has connectivity to your applications. So now that I have renewed that certificate, I should be able to refresh the page and see that my certificate is now renewed and is now valid certificate issued by Akeyless. So what happens when a certificate expires? So we also have capabilities for that.

So we have an event center inside of Akeyless where all events are taking place so we can see when certificates are about to expire, when when a certificate is being provisioned, and you can track all those actions inside of Akeyless. Even from here, you can acknowledge those. You can take care of the certificate renewal right from this event, but you can also send those events to different applications. So you can set up event forwarders to ServiceNow,

Slack, email, webhook, or Teams. So for an example, we can go into there's already an event forwarder here at Slack. So we can go to Slack and see that we get new events every time that a new certificate has been provisioned. Akeyless gateway also has capabilities with the ACME protocol so that Akeyless gateway can function as an ACME server, and we can also use use certbot or other

tools to directly integrate with with the ACME server of Akeyless. So up here, we run a couple commands to obtain information about our issuer. Since our issuer is already enabled as an ACME server, we obtain a couple parameters such as an ACME disk display ID, getting an EAB output, get a MAC number, and then we can use tools such as Certbot to provision our

certificates. So Certbot is now running and takes care of the provisioning of that of that certificate, and that took care of issuing a certificate as well. So that can already be used by existing applications that rely on certbots. K? So Akeyless can be used as a private CA as

we've seen with the PKI cert issuer. We can also integrate with external CAs. So we have integrations with the GlobalSign, GlobalSign Atlas, GoDaddy, Sectigo, Venafi, and ZeroSSL. So what's happening in these integrations is that you have to create this connection using something like an API key or a secret,

and and they provide parameters that are relevant for a certificate validation process. For private CAs, you can make use of different key types. So you can make use of a key of a DFC key. Up here, you can choose whether you want to import a key or whether you want to have Akeyless generate the key. So you can make use of Akeyless as the root of trust, or you can import an existing CA,

which in many cases will be something like intermediate CA that's being imported and can then function as a certificate authority inside of Akeyless. Instantiating your root of trust inside of Akeyless is simple and easy. So all you have to do is start running a command called Akeyless generate CA, which spins up your whole PKI infrastructure, taking care of provisioning of the root

certificate and intermediate CA, and which can then be used to start issuing Leaf Certificates. Suresh, this was the demo. Oh, thank you, Mark. So what we saw today was using Akeyless as a private certificate authority, integrating with public certificate authorities, issuing certificates directly from CI/CD pipelines and

infrastructure automation tools, automating public certificate issuance, and more importantly, rotating to prevent outages, especially with the forty seven day issue that we talked about at the beginning of this presentation. Automatically provisioning a machine when a certificate is expired, we saw that one as well. And finally, using Akeyless as an ACME server with tools

like SIRBoard. As I told you at the beginning of the presentation, this is a part of a web series Identity Security - Unleashed for the AI Era. We have exciting sessions coming up including the one that you see on the screen with three of the greatest minds in the industry, Oded Hareven, CEO of Akeyless, Eric Fourrier, CEO of GitGuardian, and Lalit Choda,

founder of Non-Human Identity Management Group. I will be hosting them, and we'll be discussing how to manage the entire lifecycle of non-human identities. Please register for this event at the akeyless.io website. As you go to the website on the top, you will see the link to the registration page. Join us for more of these sessions,

and please do also review or, attend the sessions that we have already telecast. Please sign up for the upcoming sessions as well, and I'll see you there soon. Take care. Bye.

Episode 7: The Lifecycle Directive

Hello, and welcome to our latest episode of Identity Security Unleashed for the AI era. Over the last few weeks, we have had multiple sessions where we have bought thought leaders from the industry to talk about various aspects of identity security across machines, AI agents, and humans. Today, I have the pleasure to have some of the thought leaders from the industry to talk about the full life cycle of managing

nonhuman identities, NHIs, or machine identities. With me here today are Eric Fourier, CEO of GitGuardian Lalit Chouda, the founder of NHI Management Group and Oder Haravan, CEO and cofounder for Keyless Security. Welcome, gentlemen. Before we get started, let's go through a quick introduction of yourself in

your own words. Let's start with you, Lalit. Yeah. Hi, everyone. Lalit Chouda, founder of the NHI Management Group. Thirty years in the industry within the financial sector, running large global NHI, PAM, and I'm programs. My mission in life is to educate,

evangelize around protecting organizations from nonhuman identities. Eric? Hello, everyone. So I'm Eric Fouryes, you are cofounder of GitGuardian. So at GitGuardian, we protect companies against, like, leaked secrets everywhere. It could be encode messaging system, ticketing systems, and help them, like, maintain them, fix them.

We're also the largest GitHub application in the world with half a million developers using us and a lot of enterprise around the world, using our product. Fantastic. Oleg? Yeah. Sure. So I started my, time with cybersecurity around twenty five years ago in the Israeli defense forces specializing in identity and

access management, DevOps, DevSecOps, all around information systems and infrastructure, etcetera. Later on as a senior product project manager for CA Technologies, Again, the realm of identity and access management. Then time after after that is a direct to a product for a company named MoveIt. I was acquired by Intel,

and then started Achilles together, with our, cofounders. That's that's my background. Awesome. Thank you, gentlemen. Thank you all for being here. My name is Suresh Satyamurthy. I'm the chief marketing officer of Achillas Security, and I'll be moderating this panel today and learning from some of the best minds in the industry around nonhuman identities. Gentlemen, just before we get started,

you have been working in the industry for years. If that is the case, why do breaches continue to grow? This is data that publicly available where ninety one percent of organizations still report an identity related breach. Eighty five percent are still attributed to machine identities and secrets, and it continues to grow.

So, Lalit, why don't we start with you? What is the problem in the industry? We have all been trying to solve, but seems like breaches seems to be going up. Yeah. Look, great question. You know, clearly, people may have heard the term secret sprawl, I guess, kind of over the last ten, fifteen years with, like,

cloud, microservices, containerization, SaaS services, and automation. You know, we've just seen the sort of credential secrets for a problem just get worse and worse within the the ecosystem. And now we're seeing a lot more credentials that are kind of discoverable by threat actors externally. So that's probably one of the biggest reasons now that we've

got sort of hyper fragmentation in the environment with sort of credential secrets all all over the world. It's really easy picking for threat actors to discover those credentials. But, look, I I think, you know, in addition to kind of those traditional issues that we're seeing has kind of environments come more and more complex, fixing issues related to nonhuman identities and machine identities is very, very challenging to do.

I'll give you a real life example. About five years ago, we had an issue within one of our organizations. Worked at a big financial global powerhouse, and, we scanned for credentials. You know, we found in our initial scan one point three million, credential leaks, obviously, including false positives. Imagine starting from potentially a million hard coded credentials, how do you then go about fixing those

credentials, not causing operational impact? So even discovering them is one thing, then remediating them is another thing. So that's I guess, just some initial insights on why this problem continues to grow and doesn't get better. Eric, what's your take on the problem? Why does it continue to grow?

Yeah. So joining joining one hundred percent, Lalit, on the on remediation is our like, at GitGuardian, we say, like, detection without remediation is just noise. Remediation is probably taking at in the GitGuardian products, like, eighty percent of the value we deliver, and it's for companies. We we think it's a it's a major issue to to fix, like,

credential that has been leaked. And as as Leith mentioned, like, ten years ago, we had the ten, fifteen years ago, we had the microservice DevOps revolution. We had more and more services, more and more APIs. Developers were able to provision infrastructure, whereas, like, twenty five years ago, like, it was mainly, like, IT administrator responsible to,

centralized perimeter of different self hosted servers. But now, like, I think we're on new area with with AI where, like, now anybody can have vibe code a new application and provision API keys, do, like, services in Replit and Lovable that have access to to real data. So it's just, like, so much, like, the the risk, making any employee a potential leaker of secrets. Well, like, or three years ago,

we are only mainly monitoring developers. So that's actually a huge a huge issue right now. And on top of that, like, the agentique and AI agent have just multiplied the number of connection we need to make between different services. Like, if you if you take the examples right now and and you look at companies right now, everybody is trying to deploy this this AI agent.

There is actually no security guardrails, and we're giving access very, very privileged access to this AI agent. We're giving access to customer data. We're giving access to our internal knowledge base. It could be, like, Google Drive or Notion. We're giving them access to to databases, something product sometimes production databases.

And and to do that, we're actually using, like, secrets. And, unfortunately, there is no real strong protocol to give access to to this data for AI agents. So it's just we're just giving them more and more, like, static credential, just increasing the the secrets poll that was already a huge problem ten years ago, and now it's becoming a a problem that's ten ten times bigger.

It's true. The the rise of AI agents exasperates the problem. Oded, you have been in the industry, IAM and identity security space for years now. What are we doing wrong as an industry? Why does why does this problem continue to happen? I think that, first of all, the matter of us asking ourselves what have we done wrong, this is something that we're not hearing enough.

Given, you know, millions and billions of dollars that have been developed and invested, you know, by companies to the software vendors and cybersecurity vendors for a long time with IGA, privileged access management, as well as access management. Right? Everything was meant to secure the identities. We were very much focused on the human aspect for years.

There has been another element which was closed networks until around two thousand up to two thousand and five, maybe even more. Networks were not that open. When cloud appeared twenty ten, twenty, then things have started to even take even greater turn. We're opening the networks, those on prem networks, and this is where you see the spike of more and more

passwords to be revealed. Add to that the public code repositories, and then suddenly you get the boom of secret sprawling, automation coming up, infrastructure as code. Everyone has secrets. Now the phenomena is much bigger than what we can actually consume. So first of all, the reason why there's still a problem,

it's because that as an industry, they have not been able yet, to implement the enough with the guidelines and to educate enough with our customers of what do they need to do. And everything starts with cooperation. And the first thing that you know, looking from the above of how identity and access management should look like, today,

we're still in a position where application security have been, like, let's say, ten, twenty years back where security and developers or security and platforms production are not necessarily working together. Right? Application security actually have done it better within five years back, and we'll talk about it later on. But, this is a great time for us to improve that,

to better cooperation. But what the bottom line here is that the identity the identity teams and developers are not very much, in cooperation. And this was what brings us today to where we are to where we are, which with Vault sprawling, many different types of solutions to centralize the secrets, the fact that the secrets are not being rotated at all.

The complexity is even rising. As Eric said, Lalit mentioned the fact that it's not being done, and and Eric mentioned the fact that it's now being more complex. We're going towards, an apocalypse on that end. If we won't, we will not be able to educate better our customers to start talk about federation, identity provider, providing, tokens, providing secret list, and so on and so forth.

Awesome. Thank you. Let's dive into some data that, Eric and team have pulled together from a recent research. Eric, I did see your report on twenty twenty five state of secret sprawl. What would you like to share with the audience about the report and its data? Yeah. Thank you, Suresh. So so we're doing a report.

So every the guy has been scanning, like, public get up for the last, like, I think, five years now, and we we extract very interesting data from from this. And one one stuff that, like, really was very scary for me was, like so what we did is in twenty twenty two, we actually checked all the secret that had a a way to to check them using HTTP call and only to receive HTTP call.

So we realized, like, that secret that have been leaked in twenty twenty two, if we are looking today if they are still active or not. We have swast seventy percent of the secrets leaked in twenty twenty two that are still active today. So what does that mean? It means, like and it's exactly was exactly the point of of Lalit is remediation is extremely hard

and and leaks are not remediated. So you have still, like, seventy percent of the secret that are still active today, which is which is crazy. It's just a a treasure for for attackers to just take a secret available on the public space, breached breached into your infrastructures, and move laterally from there, like using other secrets,

scan your internal repos, your internal Docker images, your internal systems for more secrets, and just gaining more and more privileges and later be able to do, like, ransomware or even even stuff like nastier that putting, like, sometimes malware in in different component of your software supply chain. And you did mention, yeah,

you did mention earlier that AI was going to exasperate the problem. Do you have any data to talk about, what that is going to do? Yes. We do. So we we we did a study that, like, actually actually repos or developers using Copilot are forty percent more likely to leak secrets. And I think it's it's it's data confirming an intuition that's

pretty easy to grasp is, like, usually people are using, like, vibe coding and and and using this AI agent are are less careful about security. And and currently, like, these these LLMs have no galleries in place to to avoid that. So it's just, like, it's just amplifying the the problem in a in an in a in a terrible way.

And, you generate more code, so it's it's a double effect, yeah, which is which is kind of scary when you when you think about it. It is scary that secrets, that have been leaked that have been created in twenty twenty two is still still active. Lalit, your thoughts on this challenge and problem? Yeah. No. I'm gonna give you, like,

a real life example of something that triggered, like, one of the biggest NHI programs in sort of the financial industry. I got a call from my CSO and head of IAM, said, look. We've had a big incident. It's gone all the way up to senior management within the the bank. We think it's related to nonhuman identities. So what transpired was an IT person within the organization was inappropriately using a

nonhuman identity. They knew the password fields for a database account, and they were trying to do some updates in UAT, but they actually connected to production by mistake. So there, you've got some core issues. Right? A human using an NHI, bad. Lack of environment segregation between prod and nonprod. Lack of cycling of the the the the credential.

And then our CIO says, look. You need to fix this within twenty four hours. Reset the password. We start talking to the app team. They said, look. We don't even know where all of our code is referring to this credential. And we think we may have even given the credential to other teams as well, and we don't know who's using it. So understanding all your dependencies. Right?

Where is that one database credential used in all your source code, you know, is a huge challenge. So one day took us three weeks to find all those dependencies we found with monitoring and logging turned on on the database. Another eight applications were sharing the same credential. Right? All those teams had to move to their own, you know, dedicated credentials.

And then finally, the password could be cycled, you know. And that was many, many, many weeks of effort just to deal with one credential. And then amplify that, we had to fix over a hundred thousand credentials. And it took us four years four to five years to complete and tens of millions in in remedial efforts. So I think that's one area I think AI is gonna be transformational where, hopefully,

it can start to streamline some of those discovery assessment dependency and then fixing the code automatically. So I think we're gonna see some big improvements with AI to help us start to derisk, but it's it's a huge, huge challenge. Oded, have you seen any issues, similar to this with the customers that you work with? Definitely. We've had one of our customers, and and, obviously,

within Achilles, the ability to rotate is is, is that as a core capability next to dynamic sequence creation and just in time creation of identities. So for the ones we call it, the second generation, but we'll we'll we'll go into that later on in this in this panel. But we've had one of our customers to say it's not enough that you would rotate the password itself rather than we would ask you to also recycle a certain container

or a certain server. So we've added this functionality as a custom, capability that you can run all kind of activities after you rotate. And this is something that we found to be very, to be very effective where customers actually beyond rotation that require also recycle of those services in order to complete the recycle, the recycle operation. And this is something that quite often when when when the

industry speaks about, let's rotate and let's move on and let's and let's remediate, sometimes, they lack this kind of this kind of angle. But as we see the production as we see the production, teams in their eyes and the way that they connect, this is how, we look at it. Got it. Got it. Now, over the last few minutes,

we have been discussing the challenges and problems associated with NHI's secrets, the mismanagement of it, lack of best practices, the need for windows to do education. Now let's switch to remediation. Clearly, from, Lalit, the examples that you showed us, it it appears that solving one part of the problem, like, may not be sufficient, and and companies need to take an approach of a full life

cycle of, NHI management. Could you share with us as a part of your nonprofit what a full life cycle of NHI management looks like? Sure. Look. I I think we always get asked a question, you know, what's unique about managing NHIs compared to sort of human identities whilst some of the life cycle processes overlap around JML?

I I think for managing NHIs, it's much, much more complex. And we've clearly touched on some of those points already. I think the heart of it is, obviously, around how do you provision, and and manage, the NHIs. You know, typically, you know, credentials are created maybe by admins, maybe by automated processes.

And that, you know, in many different disparate sources, we don't have a common source of truth for NHIs like we do for human identities like our HR records. So you're gonna find NHIs are kind of sprawling everywhere within your organization on prem, across all your cloud environments, you know, your containers, and and your vaults, and then, obviously, in source code.

So the first thing you really gotta get to grips with is how do you provision your NHIs. You know, if you're still using static credentials, how do you ensure that these credentials are not shared with, you know, developers, humans? How do they go straight into a vault at provisioning time? And then just as importantly,

decommissioning those credentials when they're no longer in use. The the real challenge is obviously the discovery inventory. You know, how do you know what's out there? What's the size of the problem? You can't really start planning kinda your strategy, which will be multiyear until you understand all those endpoints. I think with cloud and APIs based services, those things are generally fairly straightforward to discover.

But when you're dealing with on prem environments, you know, where there's lots of endpoints, databases, Windows servers, Linux servers, and other sources, getting that full inventory is is really challenging. And and, clearly, part of that is you need to scan, your source code and apply all the context and try and join the dots. NHIs are typically, obviously, very highly privileged. So being able to classify them and understand, you know,

what permissions they have. Are they got admin rights, read versus write? What's the breadth of access? Do they have access to one server? Do they have access to thousands of servers? So you need to understand, you know, what's the risk profile because you're not gonna be able fix all these issues, you know you know, quickly.

It's gonna be multi years, so you need to take a risk based approach. Then comes posture management where you kind of once you've understood what you've got out there, you know, you need to do some hygiene. You know, have you got excessive permissions right when it should be read? Are your environments misconfigured? And you're gonna find lots of inactive

accounts or shared accounts. We've been at orgs where sixty, seventy percent of the NHIs that are in the environment are not in use. Right? They're stale, inactive, no lack of ownership. So that's one area that you can massively reduce the surface area of risk. But then comes on to remediation. You've also then gotta deal with those static credentials that are hard coded, whether you're, know, doing vaulting,

cycling, rotation. And then the next key part of the life cycle is really monitoring, you know, who's using these NHIs. Has someone externally, you know, got discovered your credentials and using them. But you're also gonna find, shockingly, you know, many, many of your IT staff using NHIs internally for BAU activities. So monitoring controls become key.

But then, really, target state, like, as Oded said, dynamic ephemeral credentials moving away from static credentials and having prevent controls, even stopping hard coded credentials going into source code. And and real time protection is really kind of the nirvana state you wanna get to. But, look, most of your credentials today are gonna be static. Right?

So you're gonna have to manage them, and get control of them whilst you work, you know, to more strategic I'm, approaches. Awesome. Lalit has a great framework for the life cycle, and he also has a training program that, if, audience are interested, could take it. But now that we have identified the need for the entire life

cycle, why don't we ask the vendors on our call to how they can provide solutions for it? Eric, he said Lalit mentioned that, you know, how do I even know where my secrets and identities are? What can you offer that can help our help customers find the secrets? Yeah. Thank thank you for for for the mention,

Suresh and and Lalit. I think I think what's really interesting on the just to to before, like, talking about what GitGuardian can provide, it's really interesting to see the evolution of of the category of, you know, NHI security over the years. Because when when GitGuardian started, like, six or seven years ago, like, we we really focused on secrets in code.

We started by finding secrets publicly leaked on on GitHub and then scan internal code base for secrets. And for a long time, we were attached to more code security or application security category, and people will say, oh, remediating a secret in code is exactly like fixing a a vulnerability in your dependencies or fixing the SQL injection. But it's it's totally different, like,

when when you think about it. Like, and Nalid mentioned it really clearly. It's like, when you when you fix a CA, vulnerability or SaaS vulnerability, you just have to fix the code. But for for secrets, you actually need to change the code, rotate, recycle the credential, which is an extremely difficult task that's, like,

split across multiple departments. Developers need to handle the code fixing depending on organization. It could be IT people, platform engineers that are responsible to to recycle and rotate the credential, and and you need to find, like, all the places where the all the workflow and the application where the secret is huge. So it's it's a very difficult problem that requires a lot

of integration and discovery, and that's what we try to provide with Guardian. So the first step is really trying to discover where your secret has been linked across multiple type of data sources. So we're able to scan source code, Slack messages, Docker images, ticketing system, like, Basically, every system that might contain secrets,

which is unfortunately a number that's really growing with time. And now you have, like, all the the AI pumped and and a lot of of places where you didn't imagine you could find secrets. You you have them. So we have more and more sources to scan. So that's the step one. But, also, we integrate with different providers

where it's what I what I call where, like, when a secret is leaked, what should I do as a company? How to securely stow it? So we integrate with great secret manager, like like, AQLS and and others, but but also we integrate with sources where, like, actually, the secrets are using things about, like, Kubernetes clusters, like, any type of of workflow

that's that's using the secret. So the the idea of it is really trying to provide to our customers the best context where, like, okay. Where is my risk? Where I can find the leak secrets? And also give them the ability to actually do the the remediation. So how how they can start safely the secrets and make sure, like, the workflows are are correctly using the the new secret that has been provisioned and and making sure

that actually using and following the best practices. We'll talk about it, but, yeah, dynamic credential, avoid static credential, not sharing secrets between dev, staging, preprogram, and prod, like, all these kind of of control that at the end of the day, make our customers safer. Got it. Oded, earlier in this, series, in the keynote,

you had done a couple of announcements on, Achilles and, its AI insights as well as AI agent identity security capabilities. So I I figured now would be a good time to remind the audience who may have not seen that presentation to go back and see it, but it would be great if you can if you can use this time to answer the question with, with what we have learned from those. Sure. So very quickly, and as you asked, you know,

what what does the vendor around the table has to offer in terms of actually answering what the life cycle of of of Lali just mentioned. And and Eric went specifically for the ability to detect those secrets and then to understand also their relation and so on and so forth and to provide a better understanding of where your secrets are. With Aculus, traditionally, we've we've been very focused

on the remediation part or actually managing the actual identities. So as you can see in front of you, those are the three pillars, the machine identity security, AI agent identity security, and the and the human identity security. Those are the ones that we are very much focused on with the ability to to store the static secrets where needed and protect them to automate the, the,

rotation of those secrets whenever they're needed. And then after that, for the ones that are interested and to help our customers to move on to the dynamically dynamic creation of those credentials and eventually to help them to go to completely secretless working without secrets at all. The identity provider itself and the federation is where we put the emphasis today, where we allow workloads to be

able to approach Achilles and to query for what is the identity I should use, and please provide me with an identity in order to access a certain resource. So we're doing that today with more than two hundred billion transactions a year, and we keep growing and growing with time. Akeyless is built on top of the cryptography foundation, of our own Akeyless DFC technology distributed

fragments cryptography that allows us the ability to also, take care of encryption keys, in a way that, basically prevents us from knowing, from having access to the encryption keys themselves. Therefore, we are providing a zero knowledge SaaS. So for us, any secret includes the credentials, authentication, and the encryption keys behind it because everything identity starts with cryptography.

On top of that and during twenty twenty six, we're going to expand our ability to integrate exactly, to a platform such as a GitGuardian, like Eric have mentioned, and to be able to also understand where exactly can we remediate better. And by that, to allow a thirties three hundred and sixty degrees of understanding of where the secrets are and

eventually to provide the full remediation. Okay. So I have seen posts from a a former Gartner analyst who said that secrets are like pieces of toxic waste, and they should be eliminated altogether. And that the approach that organizations should should take is more of secret less. And, Oded, the secret less is a term that I credit to you.

You started talking about secret list three years back even before, many of the industry started talking about it. So let's start with you here. What what is this, path to secret list that enterprises need to take? Yeah. So in in a nutshell, the ideal of going into a world where

there are no secrets rather than, temporary tokens so that there's nothing to steal, That's the ideal picture in which all of us would like to go to where, again, within the future, where if there is no secret, there's nothing to steal. Now everyone knows, and, of course, Dalit and Eric would be able to to tell you that this is an ideal picture where, eventually,

we will continue to have static secrets in our environments. But the ideal way is to basically to start reduce the use of those, rotate them, but eventually, to get to the point we are not even using the object of a secret rather than a temporary identity or a temporary token. So this is, in a nutshell, what stands within this understanding.

So if we will simplify it even better, a certain workload wishes to access a certain, let's say, database, right, then in order to do so, it requires a certain credential like we all speak right now today. This credential must be rotated. Right? But when it is not being rotated or during the time when it's being rotated, let's say once thirty days,

then eventually the identity is still there. There is still account on that database that is waiting to be brute forced. Right? So the industry is now starting to understand that it's not enough, especially in the day where AI agents now act much faster. And that means that we need to go into a realm of what we call third generation where the identity itself will be created for a certain transaction and then will be

deleted, after it is being used. And that's the concept of dynamic identities, right, where a certain workload require access to a certain database, then Achilles, in that example, goes to that database, creates a temporary access, a temporary account, and provides it back provides the credentials to the workload itself so that they are able to communicate.

And after the transaction has been made, then this is where, Akeyless is deleting this particular identity, and this is where it is not being used. And yet there is still an identity. A concept of federation, in a concept of identity provider, there's the ability to provide tokens, which means does not really need this provisioning of this account rather than the issuance of a certain token

with protocols like OIDC, OAuth, SPIFI Inspire is quite similar to that. But, basically, the secret list means that there's an identity provider that provides those tokens, and those tokens are expired after a certain time. This leaves with a greater hygiene, a cleaner environment in which you don't need even later to clean those identities that are not being used.

So this is the notion of getting there. Again, the industry definitely understands that it takes time to get there. The technology need to be there. All the different platforms need to support different types of token creation. And at the meantime, we need basically the ability to manage and to find all of those other secrets and to migrate them to that, better, better way of working with secret list

methodologies and dynamic identities methodologies. Awesome. Eric, your thoughts on secret list? Yeah. I think, Ode talked a lot about, like, the idea, and the reality is, it it will take a lot of time to to get there. And I like to say, like, at GitGuard, we monitor, like, all the, you know, all the API keys and and their popularity

among the different months. And we realized, like, in twenty twenty four, like, it was the the beginning of, like, OpenAI becoming really popular on the most, like, elite credential on public GitHub. And if you looked at even, you know, the the the LLM and all the LM providers and the GenAI vendors, it's they have mostly implemented,

like, static API keys with very broad, like, permission. So I think, like, unfortunately, most of a lot of the secret set they file is also done by the different vendors in the industry and the people providing the the secrets and the services. So we also need an effort here. And, also, in very large organization, you have all the legacy systems using a lot of of static API keys.

So I I strongly believe in the in a hybrid state for years. And and for vendors like us, we we have started to also provide more products about, like, okay. We detect click sequence, but we also, like, try to help our customers have a better IG now on their on their secrets management program and then their policies just to track, okay, like, how many long lived secrets do you have compared to dynamic credential?

How many of your secrets are shared between the different environment? Are you using, like, secret less or not, federated identity? So I think it's just an evolution of of when you think about it of how we can improve the the secret hygiene for of our customers and making sure they are not breached. Today, the the big things we see on the field is, like,

we still see a lot of liquid and shore is still increasing. It would probably increase for four years. I hope, like, Oded, that in in a couple of years or maybe in ten years, we were getting better at at secret less. But I think probably also the attackers with will evolve with that and will be able to be smarter and and at some point take care of, like and we we have seen attacks where, like

even, like, on on phishing, there were attackers were able to to to steal the the host token, even a short lived credential and and use it to perform calls. And I think, yeah, we'll see we'll see in the future of, like, smarter attackers even being able to to find really smart way to to hack a dynamic and and secret test credential. Even if I think for for a long time, for the next ten or fifteen years,

we'd probably have a hybrid model on both, and and that's what we need to do on vendors in the industry, like, secure organization having both workload and make sure at the end of the day, they don't get breached. Lalit, your thoughts? Yeah. Look. I think I agree with everything Oded and Eric said.

Look, I think with the AI era, with AgenTik, I I think that's gonna force everyone's hand to move a lot faster to just kind of zero trust principles, you know, with AI agents being autonomous, dynamic, you know, and, you know, dealing with requests from many kind of end users, talking to other agents, you know, and humans. You know, we have to move to kind of a real time model

for, you know, authorization, authentication, you know, based on, you know, the intent and the context of what someone's doing. And these agents are gonna become more and more autonomous and then just do more and more things. So the answer isn't, you know, that we still see today with people standing up MCP servers with static credentials and just giving effectively god or

root like privileges. You know, it's this is a recipe for disaster. So we do need to move aggressively towards dynamic ephemeral credentials, you know, zero trust, zero standing, and just in time kind of principles. But to everyone's point, look, we've been trying to solve the PAM problem for twenty years, and most people are still struggling with PAM for human

access and privileged accounts. Right? And, obviously, it's got more challenging with cloud and all the other changes we're seeing in the environment. So, look, yes, this is gonna be a long journey, probably twenty, thirty years before we really make, real inroads around dealing with static credentials. But I think with the onset of AI, it's gonna hopefully be,

you know, transformational to not only help deal with the risks from the attackers, but help us remediate a lot of the technical debt that we have much, much faster. And hopefully, with the folks like the three of you on the call, it's not that, much of a long journey and you help condense it for enterprise customers as well. So we have had the opportunity to talk about why the breaches

continues to rise, what are the underlying causes for it, What is the remediation approach that we need to take? But before we bring it home, I would like each of you to please share your advice to the audience on this call, which is I'm leaders, platform architects, DevOps engineers who are listening to this presentation. What is your advice for them?

Let's start with you, Eric, and then go to Lalit and then to Odin. So, yeah, my my advice to to to IAM leaders in CISO is really an insurance secret security deserve its own category. We need vendors able to tackle the problem. It's not only it's not it doesn't belong to code security vendors, cloud security vendor. We need specialized solution to tackle the issues.

And, yeah, that's the only way we can succeed. Awesome. Lalit? Yeah. Well, I would agree that you need to consider some solutions. Like, when I first ran an NHI program five years ago, no no solutions existed. So we had to do everything sort of from the ground up,

and now there are some great solutions out there. But my advice on top of that would be, look, you gotta step back and think about the fundamentals, you know, the one zero one basics. Right? Policies, standards, controls, training, education. It should be clear, right, to everyone in your organization, right, that creating hard coded, you know,

static credentials is unacceptable. At a previous org, it was could even lead to termination. Right? So it's gonna come top down. I think next, right, you need to get your I'm your DevSecOps, right, your app dev teams all working together. Right? But this is a joint problem. This is not just an I'm problem or dev psych ops problem. You know, you've gotta build the right architecture and tooling, you know,

through some of the vendor capabilities and other architectural changes because developers shouldn't have to think about secrets and thinking about hard coding. You know, they should all be automated, you know you know, as part of your, you know, SDLC, your life cycle processes, and your CICD processes. So getting the right architects together, you know, across all the different teams coming up with the appropriate working groups.

Right? So you can tackle this problem end to end holistically. You can't just have little point solutions here and there. You gotta think about your overall strategy to start with the fundamentals, strategy, architecture, and then think about what tooling can help you support that that vision. Fantastic advice, Odev?

Yeah. Well, I think that for I'm leaders and CSOs today, they can I think they can notice? And if not, then we as an industry, we will help them notice that this is now the time and age where we have a great opportunity to change things. We've we've never seen it, like, years back for years and and looking for on on on

different different types of tools that the identity and access management industry have provided, there's nothing like what we see today with GenAI. Okay? We've been years, we've been asking for application teams to change things and to integrate all kind of of cybersecurity measurements.

But with identity, it was always last in line. Identity were always last in line to speak with the platform and developers and to make the changes of the authentication schemes, of the authorization schemes. That was pretty much separate in different rooms. Right now with GenAI, there is no more developers to say that, oh, I can't open this code. I can't change this authentication because it's a

matter of asking GenAI to help us to code it better. Right? Now eventually working with the architects, working with the engineers to leverage what GenAI is helping us in order to make those changes within what we're about to see within the next two, three, four, five, and ten years, which is a massive, refactoring of the entire application,

within a certain organization. And this is a great opportunity for the identity leaders to make those changes. So first of all, advocate for the future, establish the identity provider within your organization, and, obviously, advocate for secret list within using the newer the new way to code, but that's for the future. In terms of the the present time,

start managing what you know today, which is the vaults that are existing today, the open source vaults that are happening that are being used, the cloud vaults that are being used, and many other different pockets within the CICD processes, within infrastructure as code. There are a lot of places that are being known you can plug in and start managing those secrets, as is.

And the third piece, obviously, is start understanding what you don't know using discovery, using detection tools, using, the ability to understand better where are the gaps that you cannot see today. Thank you. Oded, Lalit, Eric, thank you all for being here today. Thank you for this fantastic session and sharing your

thoughts on this. Thank you all for being here today, and please visit the episode series website to register and watch the rest of the series as well. Thank you again. Talk to you all soon. Thank you, Suresh. Thank you, Suresh.