AIdentity’s Answer to MCP Server Incidents

Hello, good morning, good afternoon, and hello wherever you are. Welcome to our live webinar, Securing Your Organization Against AI-Driven Identity Threats. We're quite excited to have you here as we explore why traditional IAM falls short and how IA Identity restores some accountability. With me is my esteemed friend and colleague, Andre Priebe. Andre is the CTO of iC Consult. iC Consult, if you don't know it, are one of Europe's leading IAM consultancy organizations, and it's a pleasure to have him here.

Hello, Andre. Hello, Jonathan, and thanks for having me. Excellent.

So, without further ado, I'm going to kick the webinar off, and before I do, just a quick housekeeping point of view. First of all, for all of you out there, and those of you saying hello in the chat, thank you, you are muted centrally. We are controlling these features, and there's no need to mute or unmute yourself. We're going to run a few polls during this webinar, and we'll discuss the results during Q&A.

So, of course, there will be a Q&A session at the end of the webinar, and you can enter questions at any time using the Livestorm control panel. There's a little button marked questions next to the chat. We are recording the webinar, and the recording and the presentation slide decks will be made available for download for everybody who registered in the coming days.

So, without further ado, let's go into my section. These risks are happening now. These risks are happening now. This is not theoretical. This is actual, and this is not imminent. It is immediate.

So, everything we're discussing in this webinar is happening now, and I'm going beyond the kind of little jokes I made back in May when I laughed and said, oh, wasn't it funny that I spent two days coding an MTP server to connect to my personal Gmail and look at the carnage it resulted? No, we're talking about enterprise critical system impacting events.

And so, I would like to ask all of you, just take a couple of minutes on this, how confident are you in your organization's inventory of AI agents and MTP servers? There's a poll button down there. I see a couple of you have found it already, and it is, are you very confident, somewhat confident, not confident, or we haven't started tracking them yet?

Of course, we will be checking in at the end of the webinar, seeing what the results may be after that. So, the first poll is open. Please do participate, and I'm going to give you a few, a couple, maybe a minute or so to do so.

Actually, I'll probably be quicker than that, but at this point, I kind of wish I brought my guitar along so I could play some interim music. The reason we ask this, obviously, is to understand, yeah, where people, you know, what people's initial impressions of their security posture is as regards AI agents and MTP, and the results are, you know, quite varied.

Okay, and so, if any of you wish to participate in that poll, then we've got a couple more seconds to do so, but I think I'm going to continue shortly with the rest of the webinar. So, what is the problem with MTP?

Well, this sounds counterintuitive. It sounds very simple, but MCP actions occur at machine speed, not human speed, and so the challenge is how do you balance the agentic action against a human approval queue, and clearly, the answer is a one-sided competition.

So, the MCP servers where the linking tools, triggering actions, making decisions happen super fast, whereas human governance, and for those of you who've, I don't know, been to the post office to register a change of address, you know that governance takes days or weeks. Agent cycles take milliseconds, and so what happens? The gap creates blind spots where incidents become invisible.

They're overlooked by us humans due to the mountain of events that we're dealing with, and any of you in SOC are familiar with alert blindness, and incidents become invisible until, well, I was going to say deteriorate, but in fact, until they detonate. IAM, as we traditionally know it, is falling short, and if somebody is repeatedly trying passwords, for example, eventually, they'll get tired. They'll go for coffee. They'll take a bathroom break. They'll take a sleep break. AI agents don't. They don't fatigue. They don't slow down, and they do not question suspicious requests.

So, let's turn to the protocols. Well, OAuth, we all know OAuth2 very well. It was designed for delegated human authorization. It was not designed for autonomous agents. Service accounts, and we all know and know the problems of these already, according to our enterprise security postures. These service accounts lack context. They lack behavioral context, whereas we can predict what a Jonathan Kerr human actor will do because we have a behavioral track for him.

We don't necessarily have that same track for service accounts, and even say static scopes, well, yeah, just don't adapt to runtime context. So, as we know, if you plan out a scope of action for a service account, that will last right up until the point where the account goes live and is to use, in which case you'll have a change request, and we don't have the concept of agent intent. I'll say that one more time. We don't have the concept of agent intent. We don't know what these things plan to do, nor do we have clearly defined task boundaries. It's an agent. It's a piece of software.

Surely, it's going to do what we programmed it to. Well, no, because these are autonomous.

So, we have, as you say, requirements for authentication, authorization, session duration, account velocity, and behavioral baseline, all of which know and we understand how to limit these for human users. But, as I said, API keys are often hard-coded, and I know JWTs are a better thing, but still, hard-coded keys are a serious limiting factor. Authorization, as again, static scopes are rarely reviewed, and so they tend to be quite wide. Session duration, well, we don't expect an authentic, an autonomous AI agent to ever go to sleep, so they tend to be persistent.

They tend to be indefinite in length, and, of course, the velocity of the actions. We're going from 10 actions per minute to 10,000 per minute, which, of course, to many sounds like a good idea, but it does mean that, of course, it's impossible to track and authorize each action.

And, as I said, we understand behavioral baselines. We understand how software engineers behave. We understand how industry analysts behave. We understand how salespeople behave. We don't really understand how agents will behave, so they are unknown and unpredictable.

And so, this could all be hypothesis on my part, but, no, in 2025, we have real incidents and real damage to talk about. So, the postmark MCP package exfiltered emails to an attacker server, and this was, to be fair, a deliberately malicious MCP, but, nevertheless, it was able to exfiltrate emails to an attacker server with nothing stopping it.

CVE, so Common Vulnerability Exposure 2025-6514 found a critical remote code execution in MCP remote. So, remember, MCP remote is a package that is used by many software developers to develop MCPs.

Remember, MCPs often operate with very wide privilege indeed, if not infinite privilege. And so, a critical remote code execution means you have just granted an unknown entity the ability to execute arbitrary code on your enterprise infrastructure.

Asana, for those of you who use Asana, have the opportunity to connect MCPs, and not only did they expose data, but they allowed data to be leaked across different tenants. Again, MCP don't tend to have the idea of tenant boundaries, as I've said previously.

SQLite, the MCP for that, allowed SQL injection, which some might think was a bit of a limitation, and, indeed, allowed 5,000 forks of vulnerable code from Anthropic, who, of course, have had other problems in their security. And, of course, we're seeing tool poisoning attacks, so hidden instructions within tool descriptions. And some of you may have seen my demos, where I put up an emoji, and all of a sudden the AI says Jonathan K is the best analyst in the universe, and that kind of thing.

Well, of course, if you have some more malicious hidden instructions, then the impact can be quite serious. So, I'd like to take a close look at MCP attacks, and, in particular, the postmark MCP attack.

So, the attacker published a lookalike package to NPM, which is the Node JavaScript repository. It has many problems, but this is a particularly serious one. The package appeared legitimate. It had the correct branding, and it had similar functionality to another package.

However, it contained hidden code, which forwarded all email content to the attackers, which is disappointing. And there was zero visibility to this in our traditional monitoring. Sims did not pick it up. Intrusion detection systems did not pick it up. Let that one sink in. It was discovered by accident, not through our detection mechanisms. It was discovered by accident through bounces.

So, again, a properly determined resource attacker could still be exfiltrating now, and nobody would know. I'd like to turn to another area.

So, I talked about some technical issues. I'd like to talk about a problem which we've seen in other parts of IT, but, of course, it's coming to us here in the world of agentic AI, and that is a shadow workforce problem.

And, in this case, we're not talking about buying unapproved software. We're not talking about, indeed, hiring unapproved workers. We're talking about some business units deciding they can spin up an AI agent, because it's really easy, without any kind of governance, without any cybersecurity sign-off, inspection, or need approval. And the survey data that's been gathered shows that 91% of organizations are using AI agents, and 44% of those lack formal governments. I strongly suspect that many of the remaining percentage also lack any governance. I just didn't want to say.

Each agent equals a potential non-human identity with privileged access. There is no inventory. There's no classification. There's no life cycle management, which means these privileged actors are essentially operating unsupervised, which should give any of us in the cybersecurity arena some cold chills down our spine.

So, with that, I'd like to hand over to my colleague, Andrei. As I said, he's a luminary in this field. He's an expert CTO for IC Consult. Thank you all very much for listening, and I'll talk to you later on in the Q&A.

Jonathan, thank you so much for the introduction, the very exciting content you share. I think that's quite eye-opening to see how many things are already going wrong regarding MCP, having in mind that this is a quite new protocol, but heavily adapted in the industry out there.

Yeah, well, Jonathan brought a couple of MCP-related incidents, and I just want to focus on one single incident and really highlighting the differences MCP brings to us from an identity and access management perspective compared to the traditional approaches. So, therefore, let's focus on the traditional approach and then figuring out how the details look like.

So, let's pick a very simple use case. There's a ticketing system, and users are sending mails to it, opening a ticket, and then someone works on it and provides a soft resolution to the end user.

And, of course, there might be SLAs in place that define how fast the response to the request has to happen, and then it might make sense to, well, calculate if all SLAs have been met. And there's a script to do that. The script is just reading all the tickets and details of the tickets from a ticketing system, making the calculation stuff, and then just writing it into a reporting database. And for that, it would be absolutely sufficient to just have the privilege to insert into the database.

But we all know, even if there's zero trust, at least privilege, this kind of thing, it happens quite often that an account, a service account especially, has too many privileges. Is this a problem?

Well, it is not a problem as long as the account is not breached. After the detector gets access to the secret, we have a problem.

So, let's look into that from a risk management perspective. So, is it possible for the attacker to get access to the credential of the script?

Yes, of course it is possible. It is very likely, but I don't think so. Physical access to the system might be required, or it might be required to run a malicious process, whatever. And what is the impact?

Of course, it depends. Having in mind that this service account has too high privileges in the database, the impact can be major. But we can do things against it. We can make sure that the secrets are rotated, for instance, and we can apply the least privilege. And honestly, if the account just is allowed to insert additional data into the database, it still might be a problem, but likely the impact is not too significant anymore.

Okay, now let's move on into the new modern MCP world. And I would like to highlight very few of the foundational differences when it comes to the model context protocol. By the way, very recently, Enthropic handed over the development of MCP to the Linux Foundation. So it's really a great step that will make the MCP protocol that is already adapted a lot in the wild even more successful. So that's really great to see that. But anyhow, back to the point. So end users opening some ticketing, and then here now comes the difference.

If you're talking about MCP, we have an MCP server and an MCP client. The MCP server is, for instance, offering resources. And the large language model that is running on the MCP host, so here, is using the MCP client to get all the required information from the MCP server. Now that is then processed. And in that case, so the end user, the person in charge of the reporting was giving the instruction, please calculate if the SLA has been met. So it's then updating the database on that.

And here, another mechanism is used. It's the MCP tools method. So we have resources, typically for retrieval augmentation, so bringing the content to the LLM, and MCP tools to trigger more complex actions to the MCP server. In that case, a different MCP server, database server, like the SQLite from the example Jonathan provided to us.

Okay, and the MCP server is providing the functionality to update reports. Okay, all good.

Now, and this is another real life example. Now, it is, of course, possible to inject prompts into that flow. Kato Networks made a proof of concept against Atlassian Jira, and there are capabilities to inject a prompt from an end user perspective. And that's now what's happening here. So there are some mail going into the ticketing system. In step number two, the MCP client is receiving that data, and it's now working with this malicious prompt that tries to trigger an illegal action down the stream.

Okay, but if the reporting database server is just offering the possibility to update or create reports, the impact might not be too worse. And here now, here comes the likely most important aspect regarding access management, at least privilege. And this is a dynamic, the dynamic MCP brings into that game. And you can't compare that to a REST API. Because what is happening if the database server is offering additional REST API?

Nothing, because you are not calling it actively, right? And this is now the difference. So the MCP server gets an update and is providing an additional tool. Nobody is telling the developers of the AI tool on the left about that new functionality.

Still, it will be used automatically if the LLM decides that this makes sense. And the new functionality might then be used for deletion, manipulation, or reading of other reports. So we just don't know what will come in the future.

And now, let's look back to our RISC perspective here. So first of all, we are adding a massive attack surface here, because of introducing large language model. It's massive. It's there, a lot of attack patterns out there. Have a look to the top 10 LLMs to get some kind of inspiration there. Jonathan provided a couple of incidents as an example. So that's quite important to understand this. So whenever we are really accepting some input, this is on a different leak than what we know from traditional injection attacks. That's a completely different leak.

And then the other aspect that is affecting the impact is the dynamics of MCP tools. You're developing a tool, you're testing it, security tests, and all these kind of things. And down the stream, the MCP servers bring additional functionality. And from that day on, your tool might use that functionality without having any adaptions on the client side. So this is the level of dynamic that drives the impact of the RISC we are talking about here. So have that in mind.

And now, let's talk a little bit about what we all can do today to move it on. So authentication, authorization is the foundation that's crystal clear. If you look into the MCP protocol, and partially the same things apply to A2A, so the protocol used for agent-to-agent communication, it's somehow similar. So if you look into the specifications, the methods recommended there are topics like MTLS or API keys or basic authorization, or OAuth when it comes to authentication authorization. And crystal clear, OAuth is the way to go here. And it's by far not solving everything.

But even today, you can bring capabilities that will be required in the future to deal with the MCP complexity. And I want to highlight just a few of the things I would recommend you to work on. So first of all, OAuth 2.1 alone is not helping a lot here. But what you should do here is, first of all, having a proper scope management in place. That's something that should not be static. But you want to provide it together with solid translations and explanations. What is the scope about? What does it do? And versioning, clear ownership, who is managing that scope and takes care of that.

So you have to have that in place on a scalable level. Because every single application that decides to provide MCP server capabilities must manage scopes accordingly. So this is important. That has something that has to be really working at scale in your organization. Then the next topic, an OAuth extension called rich authorization requests. This is about reaching out to the end user. In that case, the person who is, well, where an agent is acting on behalf of the person, reaching out to it, out of band, and asking for authorization for a specific scope.

And this is something that is necessary, especially having that kind of A2A scenario in mind. So without that, you won't have any direct end user connection at that point in time to make any approvals. And you don't want to develop something completely proprietary.

Also, I doubt that the chat functionality on the MCP level will really help to solve that problem. Because it isn't meant to do approval by nature. But OAuth comes very close to that.

And then, from an end user and usability point of view, having that kind of MCP scenario in mind, where you have the MCP client, also the AI application, and that is then reaching out to five systems for retrieval augmentation via MCP. Do you want the end user to log in to every single of these five systems and giving the consent to use it for retrieval augmentation? Imagine the user journey. You don't want to have to do that. So there's one new protocol coming up.

It's a cross-application access protocol, XAA, that allows to deal with these kind of scenarios from an administrative point of view, instead of making the end user in charge of it. Therefore, I highly recommend to focus on that. The good thing is, it's leveraging extensions that are already there and well known. So go for token exchange, for JWT profile, for OAuth client authentication authorization grant. This is the foundation used for XAA as well. So something where you can already start working on today to provide that in your enterprise. All right. That's the easy part.

Take away, build the foundation now, and now let's focus on a more complex part, and this is about the authorization aspect. As I said before, the dynamic and non-deterministic nature of MCP makes it absolutely mandatory to take the least privileged barrier time really serious. As explained before, this is a complete different animal compared to service accounts used by scripts. This is important to understand that without least privilege, things will get very bad without having the service account compromised.

But just because of injection into the prompt context, and that's something we will not be able to prevent that totally. And then another important aspect, MCP servers. So the applications providing the MCP interface to the outside world, typically they're integrated with an identity provider, having some basic authorization functionality in place, typically based on roles. They are not built to work in a kind of on-behalf-off way with user content or with approvals. So that's something what the identity access management has to cover. This is important.

We can't offload that complexity to the application owners. They are not the authentication authorization professionals. They're focusing on business functionality. So therefore, identity access management has to tackle that challenge.

Okay, and then zero trust. I think it's very well known to most of us here. Zero trust is something that has to apply now to the agent world. There's no way beyond that. And I would like to highlight one aspect. As you remember, in the zero trust architecture, we have that approach of having a policy enforcement point in front of the resource and a policy decision point in charge of making the decision for authorization. So there is this upcoming category of MCP gateway or MCP proxy components, and they are perfectly positioned to be that policy enforcement point.

And to adding that layer of protection, we can't expect the MCP servers to do by themselves. So this is, from my point of view, will be a crucial component of a modern identity access management infrastructure that is able to build guardrails for the agentic world out there. And now it comes to the last topic I would like to highlight, and this is about visibility. So if you look into the different phases of the cybersecurity framework, from the perspective of digital identities, then very often the things we do today are in the protect phase.

So we would like to enforce MFA to make sure that only users that have the privilege, role, group membership to access a special resource are able to do that. And the same applies, of course, to service account or agent making sure it's authenticated and authorized in order to access it. But how do we protect what we don't know?

Therefore, it is absolutely important to also focus on the very first phase, the identification. You need to get aware of the agents out there. And this is the area in which identity security posture management helps us. It's about analyzing, discover, identify what's going on there. And that's, therefore, the next building block that I would like to highlight. And that's also something I would recommend to work on today if you didn't have that in place already.

Let's look into that from an architectural perspective because ISPM is quite a broad topic and we have to develop a good understanding of what exactly are we talking about. So first of all, the one category ISPM is focusing on are the identity components itself. And this is a perfect place to already discover agents because they are behaving in different ways than human beings. And also in that kind of on behalf of scenario is something what happens directly related to the identity provider component.

Also, that's a place where you get the insights into the privileges related to an end user or an agent and where you have the lifecycle in place. And if you don't hire your agents with an HR system, then you need to have a different process there.

Typically, it is about getting a crystal clear understanding. This is an agent and this is a person or the department in charge of that agent. And by the way, these are the privileges that agent has or can get. So that's just really about the identity components analyzing it. And then the active directory. This is not just an agent topic. It's also to understand how vulnerable are my accounts there. Are there accounts with too high privileges that shouldn't have these privileges because it's something what I expect for tier one account, but not for standard user account, for instance.

So these are things where ISPM helps. And to highlight the other aspect, now we are talking about agents running in your organizations. But as Jonathan pointed out in the example, there are also agents out there that are used by attackers and we have to develop a much higher resilience inside our identity access management world. And this is something where ISPM really helps to understand that tech surface, to understand the configurations, understanding all the identities, doesn't matter if human being or human identity out there. Then the third area, the cloud focused ISPM capabilities.

So what are cloud providers out there that might offer agent capabilities or resources or MCP service. So be able to discover and detect them. And then there are the custom build application and area you would also like to focus on. So ISPM is really that single pane of glass that allows you to identify and see what agents do I have in my organization and to have a clear ownership to them or do I have to work on to identify who is the owner, who is ultimately in charge of maintaining that agent. All right. So what can you do?

And I would like to highlight that it's of course possible to get these capabilities, not just as part in addition to the identity access management product you are using, it's also possible to getting that as a managed service, what is offered by us, but of course also by others. So really thinking about that kind of building block. And at the same time, having in mind that there are other phases of the cybersecurity framework, you would like to make sure that someone is taking care of this identity threat detection and response category.

So really getting aware of attacks ongoing and identity recovery capability. So bringing the identity layer back to life as soon as an attacker really reached the goal and is able to shut down the ID, Android ID, identity provider, whatever. So to summarize it, before we come to the Q&A section, first step is really working on your OAuth foundation and understand what gaps are there right now and bringing in the additional capabilities required for agents. The good thing is the protocols are out there. These protocols are typically not completely new. So that's very, very important.

Then next thing, work on the authorization layer. Also think into the different categories of fine-grained authorization. To highlight here, my take is that the AuthZen initiative of the OpenID Foundation will play a crucial role when it comes to agents because that's something what we need for the policy enforcement point, policy decision point approach to work at scale. We don't want to get into kind of vendor lock in here. We want to have open standards in place for that kind of architecture pattern that we absolutely need to run in AI-focused IT.

And then third point, really look into the ISPM capabilities. Get that single pane of glass to understand what agents are out there, to bring them under control, under management, because just try to establish an organizational governance on agents that just won't work. Okay. So then last point, really kind of call to action. So if you want to, or what you really should do today is make identity access management part of your organization's AI journey. Don't let them build technical debts from a security perspective that you will have to work on for years to get the bank under control.

Be part of that journey. If you want, then reach out to us. We are happy to provide complimentary sessions on AI and how that relates to identity access management to really make sure that the understanding is there in the organizations, or providing a package that helps to build guardrails for AI based on identity access management, because this is a discipline that is in charge of making AI secure that won't be solved by any other IT discipline. And with that, back to you, Jonathan, and exciting to see if there are questions out there. All right.

Well, Andre, my expectations were fully met, and I was not disappointed at all. Thank you so much for that. I always enjoy listening to you, and I learned a lot. So it's much appreciated.

So, audience, we have, I think, one question in the Q&A box. So, Andre, what I, sorry, Andre, this is a question from Alfred. I suggest that we debate this together. Wouldn't it be better to block all agents until a strong security layer has been established? Better is a bit of a movable feast in that. It's doing a lot of heavy lifting in that sense. Because what's better?

Is it, again, there's considerable debate about this, and people say, well, you know, the only risk greater than implementing AI or not implementing AI is the risk of, yeah, we can't afford not to do these things, will be the obvious pushback. And again, without very strong evidence, it's very hard for a security leader to say that, to say, oh, yes, we'll block everything.

So, there is, I think, a, I think there is a feeling that, yes, it's better to block things. But in reality, we know that if we as security leaders say, hey, no, you can't do this, all that will happen is we will encourage the shadow MCP growth out in business units, which is, you know, hard to control. What's your thought, then? I absolutely agree to your point. It's about leveraging AI is today about getting a competitive advantage, or keeping up with your competitors, right?

So, even if from a security perspective, I would absolutely agree to that point, better block it all before building all the technical depth. But I have a picture in mind, guy standing on the rails and the train is, the heavy train is coming and says, oh, stop, stop, don't move on. Right.

So, it's, it will not be possible to stop that AI train. Yeah. It's too fast. And it's too heavy. And therefore, we have to focus on building and providing the tools to make it as good as possible, as of today, knowing that we won't make it perfect, but as good as possible. Yeah.

So, you reminded me then about yet trying to stop the train. I remembered that in my younger days, I had a martial arts friend of mine who said, Oh, yes, I can stop a train with my key. How did you? How did you learn this?

Did you, you know, start small on bicycles and work up but the the question I think is, as you say, is this is the this is something that has a lot of impetus, a lot of momentum. And what we can do is encourage good governance. What I think we can't do, as you say, is expect to stand in the front of a train and not get flattened. And by the way, I have seen one question in the chat from Maurizio.

Thank you, Maurizio. Yes, I can confirm the recording and the slides will be available in the next couple of days.

So, no panic there. And I have a second question.

Actually, looks like I'm going to take one from Jan, actually. Jan asks, unifying agent identity management or governance. Do we do that across the hyperscalers or per hyperscaler? When we answer that, we can talk about containers. What's your thoughts?

Yeah, first of all, thanks, Jan, for listening and participating and bringing up that good question. So, of course, the hyperscalers are heavily working on solutions that are focusing typically on the ecosystem or having in mind that Microsoft released last month their NFR agents. But honestly, my take is that complex enterprises will always have a scenario with multiple hyperscalers in place on one thing, and you will leverage MCP servers that are provided as a SaaS and not directly related to one of the hyperscalers.

So, therefore, my take is that this will be a discipline where we have to bring solutions that are working across hyperscalers and include SaaS services that are not typically will not be able to just focusing on the one hyperscaler of choice in most cases. I mean, my thought was if you have identity management and governance per hyperscaler, you run the risk of inconsistency developing across the hyperscalers. And as we know, inconsistencies in governance are the chisels that attackers use to gain entrance. And while I have this, I have another poll here, which I'd like us to take a look at.

So, given what you now know, what you've heard from Andre and from me, perhaps, I'm going to ask you to bare your souls a little bit. Have your organization experienced a security incident involving an AI agent or automated tool?

Yes, confirmed incident, or yes, suspected incident, no, which is a brave answer, I think, or possibly quite a realistic don't know. And all of those are quite interesting. And obviously, I'd like to see those.

So, while you are answering those, I'm going to see if I can get another question. So, I've got another one here from Alfred. There was a lot of content for MCP.

Gosh, we did what we say on the tin. What are your thoughts on A2A regarding IAM?

So, for those who don't know, A2A is the agent-to-agent protocol. And that's actually quite a good question. How does A2A wire into an IAM framework?

Yeah, so my thoughts on that. So, I would say, first of all, the adoption of MCP is, according to what we see in the market happening, what we're discussing with our clients, is even higher than A2A.

Also, it's typically, I would say, from a kind of development perspective, a step that typically happens first. You have your chatbot and then adding via MCP retrieval augmentation sources and now also tools to it.

Yeah, so it's getting richer. A2A is then the next level, right?

So, it's about having an agent that's talking to another agent that is talking to three other agents to fulfill the task the first agent was giving to him, right? And this is a kind of network, a mesh, and the level of complexity is even higher because the end-user context is quite often there and the MCP scenario completely disappears.

And also, the level of predictability is even shrinking because the agent can bring new functionalities and the guy in charge of the very first agent doesn't know about that. So, that's a kind of massive change that is coming up to us. And what we really need to have there is a really scalable approach for the topic of not just authentication, being in mind that the numbers will grow dramatically, but especially authorization, lifecycle management, governance, these kind of topics.

Yeah, I like that. I like that answer and I think you're much closer to the sharp end of this than I am. But one of the things that occurs to me is that if you haven't got your IAM model and your infrastructure set up for MCP, introducing A2A will not make it better and will make it possibly exponentially worse as you'll have MCPs talking to MCPs and you will lose all control. You have to address this at the point now where people are starting to bring in MCPs.

You have to make sure that you have and essentially you have protection of the AI from the organization as well as protection of the organization from the AI. Because at the point where you have A2A, it's basically AIs talking to AIs. And if you haven't implemented governance control, then life will be challenging.

So, I'm not sure we've got more questions in the pipeline. What I would like to do is quite quickly go over the poll results, if that's okay, Andre?

Oh, absolutely. I'm excited to see the results.

So, I have here in my window the results. I think everybody, if you click on the poll window, you can see the results now if you've participated. But let's quickly go through.

So, our first poll was how confident are you in your organization's inventory of AI agents and MCP servers? And 40% of you said not confident. This is before we obviously began our presentations. And 33% of you said you are somewhat confident. And 27% of you were brave and honest and said you haven't started tracking yet. None of you said that you were very confident. And I think that is a realistic answer. And I think it is true that we are in the stage where we don't know yet really what we don't know. And we're not tracking these with the rigor and robustness that we should be.

I don't know what your thought is on that one, Andre. Yeah, not a surprise at all. Not a surprise at all.

Also, having in mind that partially it will be very, very challenging to really get a good inventory of what agents are like. I think especially the things that are running locally, right? And then having access to file system, to programs.

Yeah, that might be challenging depending on the maturity of device management you have enrolled into your organization. So, a couple of disciplines that have to work together to build that kind of inventory.

Yes, I tend to agree. So, I'm going to quickly go through and then I see we've got some more questions coming to the chat window.

So, thank you, folks. I think we just said what about now of a poll too. But my question was to all of you was has your organization experienced security incidents involving an AI agent or automated tool? 56% of you said don't know. I'm going to set that one's sinkings into all security professionals. 56% said we didn't know if you'd have a security incident. 33% said no, which is heartwarming. 11% said a suspected incident. And 0% of you said a confirmed incident.

Again, the thread I'm pulling out of both those questions, Andrew, I don't know about you, is as you said, we lack control. We lack visibility. We don't know right now what we don't know. Absolutely. I think that's something that really underlines that aspect that first of all, we have to get that visibility in order to really make it right. And at the same time, I would highly recommend to also start working on the front, bringing all the foundational elements in place because they are not waiting for us. AI guys are not waiting for us in all areas.

It doesn't matter which IT discipline you're looking at. The innovation is happening with AI and they're moving fast. They are moving so fast. Incredibly fast. Yeah. Incredibly fast. So Danielle, thank you for your question.

Danielle, thank you for your question. Concerning the risk of data leakage when an MCP server returns information to an MCP client, which would be the AI, running inside proprietary LLM, so OpenAI, Anthropic, or Gemini, and possibly Alarm and others. But since these models see full context, how do we prevent sensitive data from being exposed?

Well, one answer might be, don't let them see the full context. Let them see the context as relevant.

But again, I don't know how possible that is. Certainly we know LLMs thrive. The better context they get, the more complete an answer they give.

But yeah, what's the balance, Andre? Yeah. So I think first and most important, provide within your organization access to an LLM where you have confidence that this data isn't used in any way you don't want it to be used. So if you don't provide that kind of LLM accessible for all the different use cases inside MCP clients, but also in a different context, if you don't provide that, users will take it from where they get it, directly from OpenAI, from Google, Anthropic. So I think that's the one aspect.

And then it's really thinking about, if you allow this kind of communication happening with an LLM that is not under your control, if you're preventing and blocking that completely, that might be the better way to deal with that before risking that really confidential data from your organization is exposed to an LLM out there. Quite so.

Well, I think we've, let me just check. I think we've gone through all the questions. First of all, to the audience, thanks to all of you for participating in this webinar. It really does mean a lot to us. We do enjoy doing these webinars. So thank you very much. And secondly, Andre, thank you so much for being on the webinar, being so erudite, giving us the benefit of your wisdom, your time. It's been an absolute pleasure having you on here as a co-presenter. Thank you.

John, thank you for having me here. I really enjoyed that conversation together with you and all the great questions from the audience. That was really exciting and I enjoyed it. So thank you so much and have a great day, everybody.

Thank you, everybody.