Data Security Platforms in the Age of Agentic AI

Welcome to the KuppingerCole Analysts chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole Analysts. My guest today is Alexei Balaganski. He is taking care of all things cybersecurity as a lead analyst. First of all, good to have you.

Hello, Matthias. It's good to be back on the show again. Right. It's good to have you back. You've been traveling quite far away. You've been to the US. We will most probably cover that a bit later. But today we want to talk about a topic that in the first place sounds a bit close to what we did in the recent episodes. We want to talk about agent security, AI security, but from a kind of different angle. We start with a thought experiment. Imagine you are a team lead and you are asking your company's AI assistant how your team budget looks this quarter.

You're getting your colleagues' salaries along with the results. Nothing got hacked. The assistant meant no harm. But you still get information that you're really not supposed to look at.

Alexei, how realistic is that? This is not only totally realistic. It's what's basically happening all over the world, considering how a lot of companies have set up their AI assistants and kind of their AI infrastructures in general. For a very simple reason, that AI assistant can see all the data, not just the stuff you are supposed to be seeing, but literally everything. Why? Simply because they have two broad permissions. And they got their permissions through probably an existing technical service account, which some other applications were using before.

And the problem is, applications knew how to filter the business stuff. AI does not. So there was no attack. There was no malicious intent or prompt injection, anything. Everything worked as designed. But you probably asked your question a little bit too broadly, and the AI happily delivered a little bit too much information. So that's how it works. Right. So if the agent cannot decide, isn't that just a badly configured chatbot when it comes to access configuration? So traditional IAM access management?

Well, I guess it depends on how you understand traditional IAM. But the problem is not that it's badly configured. The problem is that it has never been configured properly. It's just how it comes out of the box.

And again, in most scenarios, unfortunately, it comes out of the box with two broad privileges or just blanket access to anything it can reach through that service account. Right. So I think you've hinted at that already. But why did this work in a non-agent world? So databases have always had this type of service accounts. You've mentioned that it wasn't the program that did the query, but it could have had the access anyway?

Well, yes and no. I think the easiest way would be to just walk you through a somewhat silly real life example. Imagine you are checking into a hotel. You come to the front desk, and the guy at the desk gives you your room key. Only you can now access your room, which is fine. But there is also a master key, which that guy also has. And he can open any room with it. Why isn't he stealing stuff from all the guests?

Well, because he is a responsible official person who knows the rules. And of course, he kind of stays behind the desk when he's working. So in our kind of IT world, that was the metaphor for a business application. So business applications traditionally did all the authorization logic. They just knew that you can only access your own salary data unless you are a manager or unless you are in the financial department and stuff like that. So all those rules were hard-coded sometimes, or hopefully at least defined with some kind of a policy language within the application.

The problem is that nowadays, all those MCP servers and agentic APIs and all the kinds of direct access to the data, they bypass the applications. They can go straight to the data source.

And again, they have all the blanket privileges those application accounts had. So unless you completely change, if you will, your IAM in your business application stack, you are facing the same problem, potentially. If you continue humoring that hotel analogy, imagine that instead of the professional front desk manager, you hire an intern who basically never tires. He works all around the clock, never makes any lunch breaks, and he happily follows any command, even just if you slip him a note under the door.

That's basically an AI, and you just slip him something malicious in a prompt injection, and they will happily oblige. Because no sense of moderation, if you will. Right. So if we go back to this notion of the agent that produced this, yeah, a bit overreaching results, since this agent is not properly specified or detailed in what it can or cannot do, it's most probably likely that these agents will have to have more access than they need for a single call because you cannot anticipate what will be the next agent request that you send to it.

So on the one hand, we have to, or do we, have to assign too much access because we don't know what the next question will be. On the other hand, it's about guarding that agent during execution that it does what we expect it to do. So this dichotomy is something that needs to be solved, and I think it should be solved with tools. Am I right here? And is this something that we can continue discussing now?

Obviously, it has to be solved with some kind of security control or access control, or probably a combination of several controls. The problem is, where do you place those controls? Because again, a typical business application stack nowadays is pretty complicated. It has lots of layers, starting from the very top where you have all your kind of end-user facing business logic, all the way down where you go to low-level data access or even file systems and hardware. And you cannot just place one control somewhere high in that stack and expect that everything will continue to work as expected.

But again, the introduction of new agentic architectures and new interfaces like MCP has completely disrupted the established stack. So now you have basically an old building which still has guards at the entrance gate, but all the side doors and the back door are wide open, and there is nobody guarding there because, well, they never thought about it. You were never supposed to get into the building through the back door, but now you can.

And a lot of agents just walk in and poke around and ask for stuff they're not supposed to be asking about, and there is nobody inside to protect against them. That's kind of the whole problem.

And again, the agent doesn't have to be malicious. You know, there is a lot of discussion about agentic intent nowadays, how you're supposed to anticipate what an agent is supposed to be doing, and somehow before it actually does it, you measure how real intent drifts from the supposed one. This is a fantastic and very sophisticated kind of topic to discuss in a separate NLS chat episode. Unfortunately, we are nowhere near solving this problem yet. So now we are stuck with much less sophisticated, but hopefully much easier and maybe even like existing controls we can use instead.

And by the way, I just recently published a blog post where I talked about security by obscurity and how we are now facing the end of that era because, you know, the whole reason why all these old-school solutions worked so long is that for many scenarios, many use cases, an attacker simply had not enough resources, time, money, bandwidth, whatever, compute, to just kind of poke everywhere and explore every potential crack in your walls. Unfortunately, with AI, now this is completely broken.

Now they will absolutely poke everywhere and explore every crevice, if you will, and they will find all those holes and they will not even exploit it for a specific reason. They'll just poke too deep and break something. And this is what's happening all the time nowadays. Somebody is basically walking past your defenses and they just kind of shake your defenses too strong and then they just break and your door is now left open, if you will. So there is no security by obscurity anymore. You can no longer afford hoping that a hacker or just kind of an agent will walk past your door.

They will not. They will knock on every door, they will break every window, and they will steal everything they can reach. That's kind of the new norm, if you will. And this is why we have to completely redesign or at least reconsider our risk management across the entire field of data protection and cyber security, because there is no way we can live with those assumptions any longer. And this is, by the way, what I have addressed in a leadership compass on data security platforms. This is kind of my favorite topic I've been doing regularly for about 10 years now.

When we started back then, it was called database security. It evolved to big data security and now it's just called data security platforms. The definitions change, the scope grows, but the whole underlying idea is still the same. You have to protect your data. You have to place those security controls as close to your data as possible. Not on the application layer, not on an MCP layer, not even on your network layer, but ideally directly at the data source.

Because if you do it like that, you can guarantee that any kind of request to the data won't be able to walk around, to get around that control. And this is what we're actually going to discuss today. Exactly. If you look at this leadership compass, you've mentioned earlier that there are technology, they are not that sophisticated, but they work, they are efficient, they are applicable, but they are more traditional.

If we look at this data security platforms, and you've mentioned the evolution of just the term of this leadership compass, I expect that the products, the vendors, the tools that you're looking at also have evolved and especially reflect what you just explained, this new type of access that comes with agents. Is this the case and what has changed since last year?

Well, I guess the biggest change I have to mention is that basically we now have twice as many covered vendors than last year. And it's not because so many companies suddenly decided to do data security.

No, it's just kind of, again, kind of all those new risks and pressure from the AI disruption and whatnot that just made so many more businesses understand the absolute need, the crucial role of data protection in their future survival as a business. So of course, everybody now understands that they need a data security solution, probably even more than one. And of course, all the vendors are happy to oblige. And they are kind of getting into this market from all possible directions.

So vendors, which a few years ago called themselves something else, data activity monitoring, access management, data governance, security posture, whatever, they are all basically trying to expand and offer you as a potential customer some kind of a platform solution, which at least promises to solve all your data security problems from a single hand. And it's kind of interesting to see how far from maturity this market segment is after all those years of development.

Because again, the world is changing and it's survival depends more and more on such a very simple idea that you have to protect your data at all costs because it's your most sensitive resource. So everybody wants to get a piece of the pie. This is why it's such an interesting development. And I would be happy to walk everybody through all the details. We will probably have a webinar covering this, by the way, pretty soon. So watch our website for that. But absolutely, the market has grown tremendously. But even more tremendously have the expectations of customers have changed.

Because again, just a few years ago, everybody was talking about data security posture management, DSPM. And I can tell you honestly, this is my kind of pet peeve. I hate the term. I have always said security posture management is meaningless. It's like somebody telling you, hey, your house is on fire, period. They won't give you a fire extinguisher. They won't help you to fire down. They just tell you. This is what security posture management tool traditionally did.

Obviously, this is no longer enough. Customers are looking for enforcement solutions, which cannot just detect something is wrong, but actually protect you from those findings. And of course, for a couple of decades, data discovery was an offensive feature, a standalone capability, which quite a few vendors just kind of built the entire business model on.

Nowadays, it's a table stakes feature. Every platform includes it by default. Some do it better, some not so well.

But again, this is now kind of a prerequisite for any data security solution. And of course, protection nowadays means much more than just data masking or even encryption. Because now you have to think about protecting your data in use or applying all those data sovereignty controls in your hybrid cloud environments. And of course, you have to do something with those rogue agents. So there is a lot of interesting developments in that space. Right. So we see some development that is like adding the R to ITDR.

So the response, not just knowing what happens and understanding and being notified, but really just also taking the next step to be operational, to say, okay, I can act with that. So that would be also an evolution that you witness here, that this is expected by the buyers to say, okay, it doesn't help to know that something's going wrong. It would be nice to act upon knowing that something's wrong. Right. Right.

And when we started with the agent that did something not really wrong, but inappropriate, do these platforms, the more than double the number that you analyzed, do they actually handle them properly? Is this a problem that is on their radar?

Well, obviously they all claim they do. This is the biggest selling point in 2026, dealing with agentic AI and securing whatever you have from agentic AI or your agentic AI from whatever attacks you. The problem, of course, is that you have to understand what's behind that claim. Almost every platform can monitor non-human access to the data, which is useful, but definitely not enough. Because again, it gives you information that something's bad happening, but especially at scale and speed of agentic, of machine access, you cannot just revisit the finding a week later.

You cannot even probably stop it a minute later. You have to do something in real time. So there are multiple ways of doing this. The most obvious one is monitoring the session and applying some kind of a mid-session step-up authentication. If something's looking suspicious, ask it to authenticate again, because maybe that session was hijacked, maybe it's a rogue agent which is working with a stolen token, whatnot. That step is like the minimum viable solution for agentic access management, if you will.

So again, of course, this was one of the areas we specifically asked the Windows tool to tell us about, and it's probably the least well-evidenced areas in this report. Because again, every vendor tells you that they can monitor AI access, at least as well as the human access. The problem is not just how do you prove it, but is it actually good enough? Because again, it's not just the scale and the speed which are dramatically higher.

There are also solutions which work for humans, like biometric, for example, but they don't for agents, because there is no behavior profile you can establish for an agent. It works so fast, it doesn't make typical human mistakes, or it makes a different kind of mistake, if you will. It's very difficult to see an agent is doing something unexpected. So I guess the biggest takeaway from this would be if somebody is trying to sell you a data security platform, and they are talking about agentic security, ask for a demo. Never take that claim at face value. And of course, why is this happening?

Because according to the one source everybody likes to refer to, the IBM's custom data bridge report, nine out of ten organizations had an AI-related because they never had the appropriate AI access controls in place. So this is something probably like at least 90% of businesses actually still need to invest in. I have to ask that question, because this is a discussion that I have a lot with my advisory customers as well. Step-up authentication, strong authentication for an agent sounds a bit weird.

So I don't expect the agent to find their mobile phone and find their authenticator app, and as you said, do a face recognition or a thumb recognition. What does it actually do to provide a stronger means of authentication to prove that it's still the one that you expect to do the interaction?

Well, there is one simple answer to that, which everybody will probably give you. It needs a human in the loop. So if something like risky is observed, a human has to step in and do some kind of a manual approval. But does it scale?

Yeah, I'm a little bit worried about this approach exactly because of that. It would work in certain scenarios where an agent can wait, but unfortunately there are a lot of scenarios where it cannot for a very simple reason, speed and scale. If you are working on financial transactions on a stock exchange, you cannot expect a human to step in and validate every transaction, which takes microseconds usually. A more sensible approach, which is being discussed now and actually being developed into standards, is a very narrowly scoped and short-lived workload identity.

Some kind of a token, but not a token which gives you a broad and long-lived access to everything, but a token which only gives that agent the right to execute a very short and specific task. And of course, there has to be some kind of a solution which would issue those tokens for every task they need to execute. This is an extension of what has been developed in the last decade for APIs, but again with a much higher speed and scale and unfortunately a much more sophisticated level of policy management.

But there are some interesting developments in that area which we could cover in a separate podcast, if you will. So we have to have something in place which would protect from agents doing stuff. They are technically allowed to do, but not supposed to. Whether it's being malicious, whether it's being some kind of injection, whether it's being some other type of coercion, if you will, or is it just happening because the agent is not smart enough, doesn't matter. It's not about intent, it's not about behavior profiling, it's not about anything like that.

It's just you have to ensure that the agent can only access and execute what they are supposed to. And this is probably the biggest challenge for the future in this industry, if you will. And this has to be continuous and this has to be event-driven.

And again, it has to scale to potentially millions transactions per second. I have no idea how far this whole thing will grow in the next 10 years, but it will probably be too fast for human approval, even in the next year. Right. I'm not a believer in this human-in-the-loop thing at all. But if we go back to your image of the hotel and the front desk and the intern, of course, who is probably doing everything all the time, where does this move the front desk in this picture?

Where should authentication and continuous authorization actually take place to make it as close to the action as possible? Well, again, I think this is a discussion which is more complicated than it sounds, because a lot of people just understand the basic terminology in very different ways. For example, a lot of people just love to talk about guardrails. And in a sense, a guardrail is a sensible kind of introduction. The problem is a lot of people would say a guardrail is something which you apply to an AI model pretty high in your stack.

Basically, you define a set of controls which tell an AI model or an agent what they are allowed to do and what not to do. But of course, this is kind of ridiculous. It's like you trust the agent that they will follow the rules of the guardrails, but there is no way to enforce those guardrails lower at the stack. So if somehow those guardrails are compromised through prompt injection or through accessing an unprotected interface or something else, they are completely inefficient.

So yes, they are still useful in a way, but they're definitely not enough. Ideally, we are talking about data security. The closer you are securing your data to the source, the better. So if your data lives in a database, for example, in a relational database, then obviously, if you can apply those controls directly in the database engine, that would be perfect. If your data lives in an object storage in the cloud, probably you have to apply those controls on the cloud infrastructure level if you can, or if you cannot, maybe on the network level.

Again, as close to the actual data you're protecting as possible. And it has to be implemented in a way that there is no workaround.

Again, what's the point of building another firewall if there is absolutely a way to bypass it and just connect to whatever, like a second administrative network interface for your cloud tenant. So on a kind of conceptual level, it's actually a very difficult and broad discussion. It has to be a collaborative effort between cloud service providers and maybe storage suppliers and network hardware developers and database vendors and whatnot.

But again, we can simplify it to a smaller scope if you focus on, for example, protecting databases. And in the leadership compass, we have covered three architectures for that. The easiest one is basically agent-led assessment, the traditional data security posture management.

Again, you can deploy it in one day, probably. You only need a credit card and a few cloud credentials for that. But since it does not sit in line, it can only observe and notify you about issues. And it's still your responsibility to fix them. The next level is to put some kind of an inline agent, proxy, connector, firewall, whatever, which would intercept any kind of access to that data and apply controls. Block access, mask data, limit data scope, and so on. The problem, of course, is you have to deploy multiple agents and connectors.

You have to build high availability architectures to prevent bottlenecks. You introduce additional latencies and so on.

Well, it is difficult and costly. And finally, there is this approach, which grows in popularity, is you orchestrate.

Basically, you take several existing data platforms, which already probably have their native access controls, and you just allow the customer to write one single policy, which you would then translate into three or five different languages, which you would automatically export to those target platforms. It is, again, a very popular and very easy solution. No runtime overhead. The only problem, it would only work as well as the target platform. So if your target database cannot do fine-grained access controls, well, you're out of luck.

And, of course, a proper data security platform should be able to combine all those three approaches. You mentioned earlier that, yeah, I just returned from Las Vegas. I've been there last week, and I've seen an example of how this architecture is actually applied by one of the vendors operating in this market and actually, by the way, covered in our leadership compass.

Basically, you ask that question. You started our episode with, hey, give me some employee salary data. Agent happily obliges. But then you basically introduce that low-level database core access control, and now the agent simply does not have access to that information because it no longer accesses the data through a service account. It's actually bound by the same entitlement that you as a human has had before. So you just get zeros for all those numbers because, well, obviously, you are not supposed to know other employees' salaries.

So, again, kind of within a specific closed ecosystem, it's actually pretty easy to implement. The bigger question is, how do you do it across a truly hybrid and truly heterogeneous environment? Right. So you would narrow down the access to the actual user, but that, of course, would mean that you understand what the user is allowed to do. But once that is achieved, that sounds simple. That's a proper approach because we should be good at applying access controls to users. So why isn't everybody doing this?

Well, again, this is a very technical level problem. It's a very unglamorous, very plumbing level problem. First of all, you have to know who the original user was at every layer of the architecture, which is pretty easy at the top end. It's kind of a solved problem at the very bottom end, at the database level, at least for some databases. But everywhere in the middle, you have somehow to kind of transport that identity with you across all those layers.

It has to work the same in an application, in a legacy application, in an API, in an MCP, in whatever service mesh you are running to support your multi-cloud application. It's simply you have such a broad zoo of different disconnected tools that speak different languages, that support different standards, that it's just difficult to maintain this visibility across all the layers. It's doable. This is actually what the entire concept of Kupinger calls identity fabric is about, right?

In the sense that you have to combine those tools in a way that they still speak the same language and communicate together and actually are able to transport that identity context through all the steps in our request. So it is difficult, but it's doable.

But again, it's very difficult. This is why you can either do it relatively effortlessly on a small scale, or you have to spend a lot of effort to do it properly in heterogeneous environment.

And again, the second problem is with so many systems, you have to maintain so many policies. And it's not just a policy, again, in the sense just doesn't mean, hey, nobody should be able to drop our database, which is a great business level policy, but it would probably require you to translate into hundreds of individual rules on different levels. For every database type you support, for every cloud infrastructure type, for every firewall and whatnot. And to write and version and maintain and orchestrate all those policies is very difficult.

And to detect the drift in those policies applied across the system is even more difficult. So it's just too much work. Very unglamorous, very boring, very automatable, but still difficult work. I'm a bit scared to ask, but the usual answer, if there is something that is too much work and nobody knows who should do that, then the typical answer for today is, then let AI do it. So this translation into policies, the translation into the right policy for the right platform, is that a task that these solutions or the concept behind them try to be solved by another AI? So AI controls the AI?

Yeah, who watches the watchman? That's kind of the old question.

Again, I am absolutely not against using AI. I am using AI every day myself.

There is, however, one subtle difference in it. I guess it's exactly the same here as in software development. There is a difference between white coding and let's call it spec coding. One is basically saying, hey, make me a clone of Adobe Photoshop. That's white coding. And another one is when you actually sit down, you define exactly what kind of a business task you are solving. Then you write a detailed instruction for AI to implement this algorithm, for example. Then you let it execute it. Then you use probably a different AI to write a set of unit tests. Then you run all the tests.

Then you use the third AI to orchestrate your application deployment. And then you test deployment. And basically, yes, if you have an established CI-CD pipeline, it's perfectly fine if parts of that pipeline are executed by AI. But there still has to be validation, testing, but more importantly than anything else, human responsibility behind every decision. You can do the same for policies. Absolutely. You can absolutely automate creating policies or other orchestrating policies and distributing and validating the drift and whatnot.

But still, somebody has to come up with declarative rules. Somebody has to test those rules that they are actually consistent with your intent. They do not violate compliance frameworks and that can align with your business goals.

And well, can you trust an AI to do that when not just your salary is at stake, but your entire business or future existence? I hope not. Okay.

Yeah, that comes very close to my expectations to say, okay, yeah, why not? But there are a lot of whys that should be taken into consideration. You've mentioned that. You do the analysis in that market segment for quite a while. You talk to the vendors just recently to produce that leadership compass, data security platforms. The answer to the question that vendors will hate, but I think our audience will like, what is still missing? What has nobody solved yet across the whole market?

I expect there to be really blind spot, blank spaces, gaps that need to be filled where we need solutions that are not yet there, right? All right. So first of all, you're right. The scope of the report is evolving every year. For example, this year we have added a section covering agentic AI access, but also this whole quantum readiness topic, because well, this is just something everybody is asking about. And those are at least already being addressed by the vendors. There is already some developments we can observe and hopefully it will be solved in the future.

But there are also additional areas where there is not so much development yet, I guess, simply because there is not so much conscious customer demand, perhaps. That can give you just a few things to think about. For example, when you are protecting your data, you are not just focusing on your actual production data, your Coca-Cola secret recipes, if you will. You also have analytical copies, test data, development data, sandboxes, archives, vector stores. The data is constantly being copied, transformed, loaded, retired, and unfortunately not always properly disposed of.

You have to cover all those copies. And to be able to do that properly, you have to work on your data lineage. You have to know where your data comes from, what requirements apply to the source, how it changed later, and what changed in the requirements and policies, and where it will eventually stop existing and why.

So yes, this goes beyond the established cybersecurity scope and a lot of data security experts probably say, well, that's not our job. That's for the compliance department, or risk management, or even the financial department to think about how they have to keep those copies of invoices for 10 years minimum or whatnot.

But yeah, it is still pretty important. So you have to have data catalogs.

Again, you have to maintain data lineage. This is something which not a lot of data security vendors are even planning to support yet. The term governance, again, it's kind of my pet peeve, because so many different people understand it completely differently.

But well, you still have to do it somehow. So you have to know what's going on within your data security platform, who's responsible for what, and how to manage, how to control it. Whether you call it governance or something else, you have to have established processes for that. And the problem is that not a lot of solutions come with those established processes and practices and guidelines out of the box. And the later you start thinking about it, the more money you have wasted, unfortunately.

And of course, there is always this thing which people tend to talk about, but somehow forget when it comes to implementation, the audit trail. How do you prove to the auditor later what has happened, why did it happen, who was involved, at whose authority and on whose behalf, what data was affected, whose data was affected, and so on and so forth. And how can you prove that this audit trail was actually not tampered with, that it was immutable, that it was complete, and it was still accessible for, I never say, years later.

This is very much a non-technical problem, because again, on a technical level, it's solvable. But solving it perfectly comes with such a huge budget that not a lot of customers can actually afford doing it properly. And even immutable audits raise another issue, because sometimes audits need to be deleted as well. So immutable would then prevent deletion, which is another challenge not to be covered in that episode. Even this simple word, immutable audit, which sounds pretty straightforward, comes with a challenge.

Alexei, before we close down, and I say it all the time that I don't like this final question, so what to do on Monday? But what to do on Monday? What should organizations actually start with now that we have walked through this large area of data security platforms to prepare for using them properly, to doing the right steps to understand where they can benefit them?

Well, again, some of these recommendations are trivial. Data discovery classification, again, this is something which we've been preaching for two decades, and people before us probably did it even earlier. You have to know what data you have and where.

And again, you have to not just know the sizes and whatnot, but also the lineage. Where the data came from? Was it something sensitive? Was it a copy? Is it a vector store? Is it a lake house which keeps a copy of your transactional data? Is it a test environment? You have to account for all of those.

Second, as I mentioned earlier, kind of ideally, you have to design for enforcement as close to the data as possible. Yes, you still need firewalls and you still need guardrails, but do not think of them as your primary line of defense.

Ideally, your data access should be like zero trust access, if you will. If you remember, again, we've been talking about this for years, trust no one, prevent implicit trust, validate every request, never trust that an open session is safe. And this is especially important for agentic access, because again, at that scale, it's very difficult to prevent abuse. When you just discovered that it actually started two days ago, now it's way too late to fix anything. And the only cure is basically make those decisions per request.

And again, do not take any vendor claims for granted. Do not look at labels, look behind them, ask for demos, ask for proofs of concept, ask them to actually demonstrate how they handle those agentic scenarios, not just look at wonderfully created PowerPoint slides. And finally, if you're actually going to read our leadership corpus, I recommend you not to just have a look at those top leaders, because again, those leaders are great solutions, but for your specific scenarios, it might be too complex or too expensive, or you are simply supposed to be looking for something completely different.

And a very small but lean and specialized solution from a much smaller vendor can be a much more sensible, economical, and just better solution for your specific needs. So I invite you to read through the entire list, including vendors to watch. And if you have any open questions, feel free to contact us and ask questions. Exactly. So that would also be my final point for today. Where can the audience learn more? You've mentioned the webinar that should be either still in the planning and registration is open. So please join Alexey in this webinar and ask questions there.

Apart from that, of course, the actual source, the leadership corpus data security platforms, it is out now that we are publishing that episode. So you can have access to that. Anything else, Alexey, that you would recommend where people can get another view of this topic from different angles? Your blog? Absolutely. We do have quite a lot of interesting publications in our library.

Blogs are, of course, free to everybody, but I also recommend a couple of leadership briefs, which you need to have an account to read. But again, you don't have to pay anything for that. And of course, we did cover a lot of adjacent topics in our earlier endless chats. So definitely look at those. So I guess the takeaway from me, the punchline, if you will, would be, do not ask the question whether agents can reach your data. Think whether your data can say no. I don't add anything to that.

Thank you, Alexey. Thank you very much for that extended episode, but it was worth it because you spent extended work on producing that leadership compass. And there will be more information to be shared, especially in that webinar. And if it's over, just re-watch it because it will be valuable as well.

Thank you, Alexey, for being my guest today. Thank you for your efforts in putting this leadership compass together. I know how much work that is. And I'm looking forward to having you in another episode very soon.

Thank you, Matthias. Thanks, and bye-bye.