Defusing the MCP ticking time bomb

hi, everyone. Welcome to today's today's event. Actually, I re renamed this title a bit, diffusing the MCP ticking time bomb.

So we're gonna really gonna drill down into really some of the risks around around MCP, some of the ones you may be aware of, some of ones you may not be aware of.

We spend a little bit of time on the on the challenges, and then jump into some demonstration. But before I get started, just a little bit of background. So, I'm your host and speaker for today's event, Porto and a market strategy with Tray.

About thirty years, in tech, a former former software engineer, and spent a bunch of time at, various companies, you know, NetSuite, Workday, Friday roles, part leadership roles, engineering roles. So I'll be taking you through a little bit the the background on on MCP and think think about. And then I'm joined by Luke Smith, solutions engineering with with Tray. Luke, you wanna give little background?

Yeah. Absolutely. Yeah. Great to great to have to have everybody on the the session. My name is Luke.

I'm a sales engineer here at Tray. So I'm very much working very closely with, you know, our pre, post sale customers on their sort of AI journey, so all of the pieces that come with that. In various previous lives, I started my kind of roles and careers at Microsoft, then switched on over to Tray, which has been really exciting working with our customers. So I'm looking forward to taking you through our functionality around MCP today and answering any questions that crop up.

But back over to you, Paul. Let's let's get the show on the road.

Hey. Thanks very much, Luke.

Just to can I can I run through the general a little bit? So we'll spend a little bit of time on the MCP challenge. So, I mean, if I'd have asked you maybe this time last year, you know, what is what is MCP?

You may or may not have known. Right? You know, this time last year, was emerging standard. Right?

Natural fact, it's one of the fastest adopted protocols in history. Right? You know, REST and, you know, SOAP way back. You know, those protocols played out adoption played out over the course of years.

The MCP has played out over the course of, months. Right? And in many cases, you know, security and governance really hasn't kept pace, and we're we're gonna spend some time on that. One of the things I'm gonna get at the end of this you know, Luke mentioned to be covering a demonstration. One of things we'll also be covering providing the end of this, we actually have a limited time white paper from Gartner that we'll be sharing as well, and it's not widely available. And so you'd be at a I'll I'll give you the link to go ahead and download that that piece as well after the event.

We'll spend a little bit of time on keys to managing MTP. Right? So as I mentioned, it's the emerging standard. Right? Well, it's it's the emerging protocol. It's still, you know, under being iterated by Anthropic. Right?

And but I'm gonna talk about, you know, how you can start to get your arms around around MCP. Because, ultimately, you know, you may not think you're using it, but I know, if you're an organization of any size, I guarantee there is someone within sales or marketing or or or product that is already using an MCP service with, you know, their core deployment or, you know, whatever whatever whatever the agent of choice is. And I'm gonna spend some time on the demonstration as well. So Luke's gonna give you a live demonstration as well of of what governance looks like.

Alright. You know, I say I I can't name this session rename this session to to to ticking time bomb. Right? And so one of the things, yeah, one of things really to think about here, and this is a stat from from Gartner. Right? You know, by twenty twenty seven, cybersecurity instance tied to prompt injection, you know, data access or or agent misconfiguration would impact forty percent of enterprise MTP deployments. Right?

And so, you know, in actual fact, the the most common attack vector that that we see on with MCP is is permissions. Right? Often, what we see is the organizations really scope permissions far too broadly. They use things like, you know, service accounts and admin accounts, for example, to authorize the MCP service.

Right? And it and it gives broad scope. Right? So and, obviously, they're more creative for these side of things like, you know, direct and indirect prompt injection.

You know, things like, for example, you know, I want this agent, you know, that you know, pretend you are this and do this and those kind of things.

And even things like data access to file systems as well. But, you know, ultimately, you know, if you don't get your hands around it, right, it's really a it it's really an area of exposure. And the way MCP changes well is that everyone's thinking about the model, right, and the the the scope of privileges that the model has. But, really, MCP really expands that attack service as well.

Right? It's not just the model. Right? It's what the model can do. Right? And and MCP really expands the capabilities that the that the model can ultimately perform.

Right? Because it can access your your systems, your file system, whatever the MCP is scoped to to perform.

So in terms of, like, you know, will it be you? Right? And so, you know, one more stat from Gartner. You know, at least one major MCP related vulnerability, high profile data breach.

Right? We've we've already seen there's already one from a a leading management consulting firm that had an exfilm from our from a set of from an agent. And so you're always starting to see some of these things, but, you know, that there's you know, some of the challenges here, it's just like it's everything from from governance. We can expect to see, you know, regulatory aspects around this as well.

Right? There's just a, you know, a huge amount of risk and exposure around this.

And so, you know, what some of the areas to think about, right, it's it's you know, I can't term it as the the the wild west. Right? And there's a few things. Right? The the first is stat here from Queen's University, right, which is ninety percent ninety two percent exploit success when using ten unmanaged MTP unmanaged MTPs.

And so what unmanaged MTP is is is where you can go off to MTP registry. I'll share an example of it later on. Right? And just basically go ahead, you know, get the MCP URL.

You know, bring it into Claude. Right? And, you know, Claude has that skill. It it reads the context and description.

Right? And it goes and adds that to his skills. And after that, right, you know, when you issue a issue a prompt, it'll go ahead and use that, the MCP service. What what they found is that when you use multiple unmanaged MCP services together, right, maybe you have an MCP service for accessing, you know, some, for example, your CRM or maybe it's your, you know, your internal repository, those kind of things.

Right? The the the the the range of exploit opportunities, you can get much more creative, you know, with the prompts, and you get those nondeterministic aspects of the MCP service being used in in concert together that opens up a potential, you know, vulnerability.

The the second area is just the sheer number of MCP servers that had critical vulnerabilities as well. You know, often when you look at the the developers that are behind this, right, you don't know the heritage of the of the MCP servers being built. Right? You know, who has developed it? You know, what's the trust model around it? Right?

You know, is it being actively maintained? Right? Has it been through, you know, security review? Right? And so what they found was that about thirty three percent had had vulnerabilities around it.

And then the final area, actually, from Encrypt AI here, right, is that about five percent were vulnerable to, you know, tool poisoning attacks. Right? And a tool poisoning attack is basically where someone's manipulated the tool descriptions, manipulated the parameters and metadata. Right?

And so what it basically does, it tricks the LLM to use use the tool in a malicious way. So, you know, there's everything from, you know, everything from, you know, prompt injection, right, where you might say, for example, you know, pretend you are this, you know, ignore previous instructions. Instead of this, do this. Right?

There's prompt injection. There's indirect prompt injection where you might, for example, have white text, right, on a web page. Right? And the MCP tool reads that.

Right? And then they have some hidden white text with instructions. You know, tool poisoning, you know, I mentioned earlier, where basically the the tool descriptions and parameters, you know, basically in the MCP service, you know, trick the MCP's the LLM into performance like you shouldn't redo. And also privilege abuse as well, which is the really common one, which I mentioned earlier, misconfiguration, which is around excessive permissions.

Right? They're they're using broadly scoped, you know, service accounts, right, that ultimately grant the MCP service way more authority, right, than it really should have, perhaps when it's accessing some of internal systems. Right? And what we often see is that business users, when they use when they deploy an MCP service, you know, they might quickly authenticate.

Right? And they don't realize necessarily the level of level of access they're granting. And then they share that with someone else. Right?

And then and then, you know, that that that privilege has been has been shared as well. So really got a variety of of of of exposure in your areas.

You know, I just I just kinda thought I'd share this one quickly. Right? This is for MT MTP market. Right?

And this kinda gives you a feel. You know, thirty one thousand MTP servers. Right? You know, it it it crosses the the gamut.

Right? Developer tools, API development, your data science, productivity.

So, you know, thirty one thousand now. If you ask, well, what are what's the what's the, you know, the heritage of those servers. Right? You know, where do they come from?

Who wrote them? Right? It's really hard to trace that, but, yeah, it makes it so MCP makes it very, very easy to go out, grab the MCP URL, right, and access it from Claude, for example. But ultimately, you don't know necessarily what's embedded in the MCP service.

You don't need to trust model as well from the IT side of things.

But so that's that's MTP. Right? I mean, fantastic protocol. Yeah. It really enables your, you know, agents to reach much farther and flatter actions.

Right? So it's something, know, we we we wanna use. Right? But you have to you have to surround it with a with some level of of governance, if you're coming at it from a from an IT perspective.

So, you know, we speak with, you know, hundreds of customers and and businesses, yeah, pretty regularly at Tray. And so, you know, I think, you know, everyone is familiar with, you know, shadow IT. Right? You know, whether it's people building, you know, integrations, you know, behind the scenes or, you know, automations or those kind of things.

Right? Shadow IT is where your business is doing things that isn't necessarily, you know, yeah, managed by the IT team. Right? And so what we kinda see a little bit more and more is, you know, Shadow MCP.

Right? And so, you know, what what Shadow MCP is that it's someone in the business team. Right? They are you may you may wanna, like, a technology jockey, right, within your within your business, within sales or marketing or maybe, you know, some ops role.

Right? And they're in they're using Claude. Right? Maybe they're using Claude code. Right? And they ask, well, why why can't, you know, why why can't my why can't Claude, you know, go ahead and access, you know, my CRM?

Right? Or right? Or or or why can't it summarize this web page? Right? And so that that's a request, right, that goes in.

Right? They they might ask for for IT. Right? Well, can you can you help can you help me out with this?

Right? And, you know, and and IT is is is backlogged. Right? And everyone's competing for for IT.

And so what we often find is that teams won't wait. Right? And that's really step four. Step four is the point where the risk starts to open up.

Right? They go ahead and basically, you know, register the MCP with Claude. Maybe if there are intelligent things, they they build the MCP servers themselves, right, using, you know, JavaScript or Python, right, or some tool they they've used internally. And at that point, you know, governance gaps follow.

Right? You you have situations where the tools in combination, you know, pave in ways that, you know, one thought about. Right? As I mentioned earlier, you know, ten ten ten m c pull MTP tools together, right, can behave in unpredictable ways.

And then you suddenly have, you know, more versions, more owners, more failure points, you know, unattached MTPs. Right? So that's the point where, basically, shadow MTP has kinda left the station. Right? And IT is trying to get their arms around. I'm gonna share a story around that a little bit later on in the presentation.

Just wanna, like, share this also from Gartner. And, yeah, they call it the kind of the the trifecta of of MCP tool risks. And this actually is in the in the white paper that you can download at the at the end of the at the end of the event.

So, you know, they they they kind of view it as as as three areas.

Right?

Yeah. There's the risk of granting access to, you know, PII. Right? Personally identify and identify the information to MTP server.

Right? Things like, you know, you know, you know, obviously, worst case, you know, your your your ID. Right? Social security is a lot things.

Right?

MCP servers can query, you know, untrusted content. Right?

And also also allowing the MCP servers to communicate with external service or web pages. Right? For example, I mentioned earlier. Where you may have an MCP service access to web page, and maybe they're hidden instructions, for example, you know, on the web page.

And and and and Gartner's kind of framing here is that, yeah, if you have a set of these together, that really is an MCP no go zone, right, as well. So this is where you need to think about each of the MCP tools, right, and service that your team is accessing, right, and understanding the the scope of the MCP service, right, and understand these risks areas where, you know, it's potentially accessing untrusted content, external web pages, all the kind of information, right, is potentially tapping into. Right? And if if it's one or more of these, right, you need to get your arms around and say you know, and and intervene from an IT perspective.

So there's one other area, and this is to think about is nondeterminism versus determinism.

Right? And, you know, large language models are ultimately, you know, nondeterministic. Right? When you provide a prompt, you're not necessarily sure, you know, what the answer what it's gonna do.

Right? Because it's it's reasoning. Right? And determinism, on the other hand, is is a guaranteed result.

Right? So if think about a workflow, for example, a workflow is deterministic. Right? You know, you you you start with a you start within a state to begin with.

Right? It's gonna run through and you know your your end state, right, based on what the logic. Right? A a m c an LLM, you doesn't work like that.

It's gonna reason through it, right, and judge it. Right? So you have to think about that, especially when you're deploying MCP because if you provide a prompt, right, for example, you know, create create a sales order. Right?

Help help me create a sales order and you register maybe a certain MCP tools on that. Right? When you yeah. You might you might ask that prompt twenty times.

Right? And it might, for example, invoke a set of MCP tools, right, a certain sequence around that. But that's not that's not guaranteed. Right?

You might ask that prompt twenty times. And in the nineteenth time or the twentieth time, right, it may invoke the MCP tools in a different sequence. Right? Or maybe it might, for example, not ask for an approval, right, where it should have done.

Right? And that's a business process risk. Right? It's not necessarily a security risk. Right? It can be a business process risk.

Right? Because, for example, it might, you know, create the sales order without necessarily going through the right approval. Right? Determinism, right, is where, you know, it's it's it's it's it's not guaranteed the answer.

So there's optionality here that when you create MCP tools, right, that you bake more determinism, you know, into the tool itself or you bake more logic into the tool. So when the MCP serves accesses that create server, create create sales order, for example, it will invoke the MCP tool for the sales order, and it will go through a deterministic process as well. Right? So you need to think about, you know I mean, obviously, I mentioned earlier.

Right? You have ten MCP tools together at end of pseudo risk, but they can also open up business process risk as well. Right? And so, you know, if you think about some of the MTP services we have, in some cases, folks have been creating MTP services that basically are one to one, right, to APIs.

Right? Very granular. Right? That leaves the reasoning down to the CLM. Right? And it, you know, it might, you know, invoke any any number of APIs in different order MCP system in order.

Right? You need to start thinking about MCP service. It's almost like microservices as well. Right?

You have baking logic in it. Right? So when the MCP when the agent calls the MCP service, right, there's a level of guarantee.

Right? And the tools are enforcing the logic that's gonna be applied. Right? And that that ensures a level of trust, right, within the business process. Right? The the the the business process and execute when the prompt is run and it's gonna execute in a reliable in a reliable way, and you get predictability. So, you know, you know, less about, you know, granular MTP services, especially when it comes to critical business processes, are more about baking more business logic into the MTP tool itself.

One of that side of things as well is unmanaged MCP gets really expensive, you know, really fast. It's a really fast way of burning money. Right? I just, you I just sized out a few things here from, you know, GitHub and Notion and, you know, file system.

Right? You know, fifteen ninety three tools, hundred ten tools. You can both could can burn your thousands of tokens. Right?

And so the average tool definition, you know, that's the that's the description, right, of what the tool does. Right? The MC and and the agent basically evaluates the tool definition, decide, you know, should it use or not. Right?

And you you times that by, you know, ten servers, fifty tools in average per server, five hundred token. Right? You can get to, you know, tens of thousand tokens, you know, really, really quickly. And so there's really a trend, right, to evaluate the token the the MCP service we have, right, and start to consolidate them.

Right? You know, you know, do I need, you know, fifty different MCP tools out there, right, when I maybe I can I can build a layer that can consolidate that to, you know, to to a tenth of that, right, or twentieth of that and consolidate my MCP tools down? That both improves the performance, right, because that's the reason up across less tools, right, and it also reduces the token burn, right, as well.

So, yeah, things we covered here. Right? You know, this security risk, right, from unmanaged MCP, things like prompt injection, you know, tool poisoning, you know, over over over permissioning, you know, service accounts, those kind of things.

Right? We covered the risks around determinism and nondeterminism, right, around invoking MCP tools, right, in unpredictable ways, right, that can lead to business process risk, right, because it's not guaranteed.

Right? And also, we covered, you know, token burn, right, as well. So, you know, three areas.

So, you know, what I would say, right, is that, yes, and your RTO, right, not not not recovery time objective, you have returned to office.

Right? There's there's three things. Right? And it these these are things that, you know, that you should really think about when you when you, you know, when when when you return, you know, when you and, to get you get back to your desk, right, after after this event.

Right? And, you know, the first is, you know, you got inventory inventory your your MCP exposure. Right? And that's that that that's that's that's pretty hard.

Right? Because it's not it's not like you can scan a network, right, and see what MCP risk is. Right? It's it's it's it's putting in a, you know, a a level of management around that that ensures, right, and and best practice in your organization, right, and IT policy, right, to unsnap to to to get your users to actually, you know, you know, ensure they're using, you know, MTP servers.

They should be. Right? But even, you know, even right now, the key is to go go out to your organization, right, and really set policy, right, and also understand department by department, right, our teams using Claude with different MTP servers, you know, what are they, you know, where do they come from, you know, are they trusted, you know, those kind of things. Are they from a legitimate vendor?

The other area here, second one, is you really kinda operate basically on, you know, zero trust. Right? You know, it's not it's not paranoia. Right?

You have to assume, you know, prompt injection to come and coming. Right? You think back to that that Gartner stat, you know, I shared earlier on. So, you know, attackers already figured out that, you know, compromising the action MCP server is actually easier than trying to compromise the AI model itself.

You know, AI models are, you know, managed right by, you know, frontier vendors. But when you think about that, that's that number I shared, you know, thirty thousand MCP servers. Right? So attackers have figured figured out that, you know, tool poisoning or supply chain attacks, those kind of stuff, Things are much easier when it comes to, you know, compromising MCP server.

Now and the the final area is, you know, I kinda touched on this a little earlier, right, which is, you know, policy approval. Right? Which is you wanna get to a place, right, which is in order to use an MCP server, right, or to build an MCP server, you have to kind of articulate a business case. Right?

And you have to go through an approval process. Right? And you have to go ahead and write, and that is the the set of in the same way as, you know, you go through an application, right, where organizations, you know, if they wanna use an application, has to be an approved application typically. Right?

That you wanna go through the same process with MCP, and we wanna really shake out that that frivolous, you know, tool adoption, right, and the unsanctioned unsanctioned tool adoption.

Okay. So now I'm just gonna run through, you know, where where the state of the art is, right, with with getting your arms around MCP. And so I'm sure everyone is familiar with, you know, AI gateways. Right?

And, I mean, interestingly, AI gateways, you know, formed over the course of, you know, years. Right? And then everything moves fast to with AI, right, as we all know. Right?

And, you know, agent agent gateways are coming together in a matter of, you know, months, right, with the MCP with with MCP. And that's really a function of how how rapid the adoption is with MCP. Because the thing about APIs, right, we think about, you know, when a a a a a a game user merge, in order to use an an API, you still have to be a developer. Right?

You know, you start to know how to work within your you know, you're running with Java. So you you yeah. But whereas MCP, you have to be a developer to to adopt MCP. Right?

I mean, I can take a URL. I can drop into Claude. Right? And off I go.

Right? And so the the management problem is much more important, right, with NTP, and and and and that's really come together much faster as well with agent gateways. So you can kinda think about an agent gateway as really kind of architecturally kind of similar to an API gateway. Right?

So rather than AI clients going directly, right, to MCP servers, right, you have an agent gateway that manages security, you know, governance control. Right? You know, a registry model around it and also provides a way to build new MCP services, right, and access your underlying systems in a in a managed way. Right?

So and you kinda got the frames here. Right? It's the registration, discovery of approved MCP servers and also auditability. Right?

Audit trail. Right? If you think about, you know, our you know, where where and if you think about your users using MCP directly today, you know, where is the audit trail across the organization is putting spread across a bunch of different areas, whereas a gateway centralizes the audit trail of the prompts, you know, what actions have happened, you know, the identity it's tied to, it it stores that in one central place and provides instrumentation around that.

So, you know, architecture is similar to an AI gateway. You have a central place and the idea being it gives I IT a way to really manage control. And so, you know, Gartner really named this as they were kind of the central capability at this point. It's something really to put in place, right, rather than the cover laissez faire MCP adoption.

You know, I I kind of like, you know, put a little side by side here. Right? And, you know, I can't tell me it's putting orders to MCP chaos. Right?

And you think about the left hand side, this is really what it's about. Right? And, you know, I'm being generous with the systems. Right?

Because there's lots of web pages and file systems and public sources and all these things you can reach out to. Right? But if you think about the left, right, it's a it's, you know, every every agent connecting directly to MCP. So there's no real centralized audit trail right there.

There's no centralized you know, the authentication can be different. Right?

There's no instrumentation around it. If something goes wrong, there's no central place, you know, to look and trace around it. And on that, on the left hand side, if you think about compliance, if you think about security, right, it's pretty challenging, right, to get your to get your kind of arms around that. Right?

And there's lot of risk there. And so the the right hand side is really how an agent gateway kinda operates. Right? It's managing, it's approving, It's securing.

It's controlling in your MCP tools. Right? And that's the that's the centralization. Right? And also the instrumentation right around that.

And also matching some of the authentication as well. Right? Authentication and ensuring that the authentication is essentially handled. Right?

And and also, of course, a cross tool as well. Right? So whether you can chat GPT or Claude or Gemini or right. You know, any any of the any of these tools.

Right? It's all running through a single a single place.

So this is just like the, you know, the managed MCP, and and and Luke is gonna touch on this.

So, you know, Tray, we have what was called our Tray agent gateway.

Right? And, you know, we basically provide the authorization, the access control in terms of who gets access to what at NTP services, things like logs and monitoring, and those areas are all baked into the gateway. And, you know, some one of areas I touched on was deterministic versus nondeterministic earlier on. The key here is with workflow tools, right, is you can design your MCP tool.

Right? And so you can bake as little logic or as much logic as you want. Right? It can be as granular as, you know, run a report.

Right? It could be as as as broad as handle my customer onboarding. Right? And and all the approvals around that.

And so that gives you that level of deterministic control that you really want, right, if you're gonna start to go to production with MCP, right, and have that predictability with MCP services. On the right hand side with connector tools, you know, not all m not all application actually, most applications aren't MCP enabled. Right? So with connect tools, it opens up, basically, seven hundred connectors that are available through MCP, right, with the operations.

So ERP, CRM, you know, service desk, you know, all those areas. And so, basically, it opens up your stack securely, right, with the access control, and you can, you know, open up how much you want. Right? So you have this you have flexibility to find sophisticated MCP services or access, you know, broad range of connectors.

Right? And so, really, that provides that that centralized kind of, you know, intermediary, you know, layer. So, yeah, we call this we call this kind of managed NTP. Right?

And so so so that's the so just, you know, Luke is gonna touch on this, right, in the in the demonstration. But just to give you a feel for what this what this looks like, right, which is, you know, think of as, you know, a control plane. Right? And, you know, if you have one place you can look at, right, you can look at all of your various tools, the MTP server.

You can look through your your various tool names. In this case, we have our our customer onboard and our process payment, right, and our same call for confirmation email and our, you know, generate invoice, right, our various MTP source. I can see them in one place.

Right? I can go ahead and go access the logs around it. I can publish that as MCP server, right, and then teams can consume it. Right?

And you think about the difference here. Right? For if you're an IT, you go to one place and you can see all, right, in one single place. And so this is a fundamentally different approach.

Right? It's rather than kind of reacting to MCP risk, right, where we come are kind of right at right now, you're really going through an approved surface area, right, improved place, improved control plane. Right? And, ultimately, what you're launching internally, right, is basically a governed MCP marketplace.

Right? A governed marketplace. And what that means is that your team gets the speed they want. Right?

But you also get the the area you want, which is everyone's operating from a from an approved from an approved model. Right?

And, also, you know, could you keep that monitoring? Right? Instrumentation is really important.

So, you know, I've kinda like know, we I've popped the hood now, and I think Luke will cover this.

But, you know, I mentioned Krigsman's deterministic MCP tools. Right? So, you know, here you you here I kinda popped the hood on what MCP tool might look behind the scenes. So rather than being buried in your JavaScript or, you know, Python or any of those things, right, You can create the logic.

Right? The way it gets triggered by the as an MCP service, all the steps needs to go through. Right? And you can even you can even go ahead and evaluate some of the the underlying prompts and those kind of things as well.

Right? And then when it executes, it's gonna leave no trail behind. Right? But if there's approvals, if there's other applications it should be reaching out to, right, you can control all of that.

And so the other area is that if you think about the MCP services you have publicly right now through accessing, there's no transparency within them. Right? You know, we gotta know it's gonna be a black box. Right?

And even if teams are building internally, it could be a black box too. Right? It's from IT looking in. Right?

Yeah. Here, it's all in it's all transparent. Right? It's a single kind of visual definition of the underlying MCP service.

Right? And, obviously, deterministic. From a token burn standpoint as well, this this can consolidate what otherwise be multiple m MCP tools. You can consolidate it into one kind of composite MCP tool.

Right? So whereas it might LM previously might have had to call ten, twenty, thirty underlying MCP services, you can actually roll into one centralized place. Right? That's that culture token burn as well.

And so what we actually find is that companies we speak to, the efficiency alone, in some cases, makes sense, right, as as as a driver. Right? Because, you know, as as we all know and as Uber recently found out, token burn can get really expensive, you know, really fast. Right?

And it can be hard to control, right, as well.

You know, governance and instrumentation. So this is the other important area. Kinda Gartner kinda touched on that as well. And, you know, traceability is incredibly important.

Right? Is that ultimately and you can't get there, by the way, when you got service accounts. Right? If you're using service accounts and, you know, admin accounts, those kind of things.

Right? You lose this you lose the traceability from the user that asked to the underlying log. Right? Because, you know, who knows?

You know, they're they're calling a service account. Right? So it's not mapped to their identity. Right?

So, you know, obviously, you're have to know authentication. Right? And ensure that. But the the MCP server, right, and a gateway really provides traceability as well, right, in tandem with with you know, just having all the authentication, which means that when you look at the log file, you know, I can see exactly, you know, the MCP service that that was invoked.

I can see who invoked it and and what actions it performed. Right? And that is really important from a a compliance perspective. Right?

If have a compliance team with your organization, they are really gonna care about the the tools your team team are running and ensure they are completely auditable. Right? And if there's an issue internally, you can get to the logs, right, and see exactly the the kind of causality between what the team is doing, right, and the underlying results. And then finally, observability as well, right, which is ensuring understanding the trends and usage.

And this is actually important even beyond security, right, which is, you know, understanding which MCP tools are being used and, you know, which aren't. Right? You know, what what are what are trending? Right?

What are the opportunities? Right? Maybe I I rolled an MCP service not being adopted. Right?

Is is that a is that an enablement issue? Right? Or is it an MCP usage scope issue, right, or functionality issue? You know, how you know, how you know.

So so Observe really really helps with with adoption. Right? But it also helps with your management as well.

So, you know, you know, logs I know. I don't normally get excited about, you know, logging. Right? But logging is actually really important, right, when it comes to MCP.

Right? And so I just kinda, like, kind of, like, you know, summarized here. Right? You wanna capture user identity.

Right? You know, who triggered interaction. You wanna get timestamps. You wanna get a session identifier.

You wanna capture the original user prompt, right, and capture it.

Any kind of agent reasoning, your chain of thought, you know, and a full activity trace as well, tool calls, tool names, parameters passed. And, you know, if you think about what I shared earlier on, right, with the left hand side, right, with the laissez faire of, you know, lines between the agent and the the destination. Right? You don't wanna capture this in one place, right, if you don't have a gateway. Right? So the gateway provides you with this, right, that that centralized logging.

So, you know, net net. Right? You know, what a gateway helps really provide. Right? It's expose reduces the exposure to your business. Right?

Things like your nondeterministic tool ask aspects. Right? Helps you helps you get to a trust model, right, with MCP. Right?

And so that reduces your risk around things like prompt injection and, you know, especially tuning tool poisoning, right, as well as, you know, privilege abuse, right, where, you know, there may be, you know, the service can't be used as way too much scope of permissions, right, authorization, which which, you know, opens risk there. You know, token costs, right, getting your arms around to do you really need, you know you know, five hundred MCP tools, right, or, you know, twenty MCP servers. Right? Can you consolidate down to to reduce the amount of evaluation that your agent has to do across those various MCP tools?

Right?

Ensures you get bits to mom, but doing it in a managed way.

So just wanna share an example of our company. So JW Pepper is actually one that is a leading retailer behind sheet music. Right?

And they were, you know, founded way back, actually, in eighteen seventy six. So, you know, older company, but they provide everything from sheet music for radio piano and yeah. And and across across the spectrum of of genre.

So where JW Pepper was and we actually have a a recorded event with them who I head over to the Tray website. You're welcome to to hear it from from their own from from their own team here.

You know, what they found that their finance team was building their own MCP servers, and they were looking at this from an IT perspective. Right? And they run the they were looking to point where they they call it shadow AI, you know, shadow MCP. Right?

Their teams were using not not only models, but they're using MCP services. Right? And the the third one was, like, in a key area, right, is the you know, everyone's faster. You off quickly, right, and share.

Right? I mean, I I I've been guilty of it too. Right? But, yeah, teams are grinding full access, admin access to agents, right, to get result quickly.

Right? And that obviously is not best practice. And so what they found, they're in a kind of a place where, yeah, their IT was kinda playing catch up. Right?

And they didn't they didn't wanna be in that place. Right? They wanna be a partner, right, and and and pair up with the the business, but they also wanna get the leading, right, rather than rather than tailing. Right?

But and what they found also within have, you know, enough visibility to agent activities. Right? And so they were really kinda, like, focused on really getting control. Right?

And so, you know, this is kinda where they got to. Right? So, you know, they they went to they went to a gateway model. Right?

But, you know, the the traceability was really important. Right? Every action traced to real users. They go to a place of tool consolidation, which is obviously pretty helpful from a from management and a and a and a cost standpoint, right, ensuring that they were able to reduce the the data access they needed.

Right? But they ultimately were seen by the business as an enabler, right, not a roadblock. Right? And you get to that place where, you know, the IT team is giving the business what they need, right, the business is getting what they need.

Right? But, you know, one is not road blocking the other, and the other one isn't trying to bypass the other. Right? You you do a partnership.

Right? And and the and it wasn't a big rollout. Right? If you think about AI gateway API gateway is in the past.

Right? You're the in the months of rollout. This will roll out within weeks as well. Right?

So just stay with just stay with MTP as fast, rolling out managed gateways is fast too.

Quote from Marcus, you can head to our Tray website if you don't wanna, you know, know, hear hear Marcus himself. So Marcus, the enterprise architect, over at JW Pepper. You can hear the results for yourself.

But with that, you know, not not not screenshots. Right? I'm gonna hand it over to Luke, who's gonna take you through what our gateway looks live. So over to you, Luke.

Thank you. I see myself getting bigger on the screen while we seamlessly switch our screen shares over.

Perfect.

Let me give it a moment, and you should be able to see the Tray platform. So I know there's a few questions coming through while Paul was going through that as well. I will spend some time at the end going through those as well. If any other crop up as I take you through the demo here today, feel free to pop those into section as well.

But exactly like Paul said, I'm gonna take you through the functionality that they just went through, the kind of key different areas around the agent gateway on the Tray platform specifically. And so the general idea here is that we have the ability for you to be able to expose out a single MCP server. That's a lot more governed than just giving people free fall access to kind of whatever MCP services that they require. So the general idea is that I can enable my MCP server.

You'll notice that I can it's currently scoped here what we call a workspace. So, of course, you might have several MCP servers that you want to deploy across different team members, across different use cases, across various tools. The idea is that you get one single URL to expose this MCP server URL app, and all of your clients will be authenticating directly into that. So under this access management tab, I can come in.

All I'm gonna be able to see is all of the users that will have access to this particular MCP server. So the general idea, of course, is that not everybody should have access to every single MCP server, so it gives you a much more clean way to kind of manage the access that your users will have across the service that they're accessing.

And what you'll have here is a combination of both users that are authenticated through API, but then most importantly, you'll also have the ability to authenticate through OAuth two as well. So in your client of choice, depending on what your supported mechanism is, you'll be able to authenticate to this MCP server provided that you are a user that's been tied to this. So this access management layer is obviously really important from the security point of view. It just means that you know who will have access to this MCP server, what tools will they have access to as a result of that, and you've got a much tighter control over the things that they're gonna be able to access when it comes to actually interacting with any of those aspects as well.

This is easily adjustable, so you can tweak this around. You can either obviously add or remove users as you see fit, but this gives you a clean way to make sure that you can roll this out a much more secure but also a scalable way as well. And this touches, I think, certainly onto one of the questions that came through as well around kind of who sort of manages this sort of gateway. Typically, it's that sort of IT business apps teams that are gonna handle that because they'll have the visibility to know who should potentially have access to that.

What's really important is tying that into your existing security things around, okay, which users are assigned to Tray, what permission sets they have within that as well. And then, of course, the next part is, okay. Well, what are we exposing on this MCP server? Right?

So we've got a single MCP server that we're exposing. We're controlling who has access to that in a much more tightly controlled manner, and that's where this idea of workflow tools come in. So we have a combination of the tools that Paul went through in terms of what we're gonna expose on this MCP server. So the first one is this idea of a composite tool.

So you can see that I've got a few different tools associated with this MCP server. This one is sort of emulating a kind of a helper ITSM type set of tools that the user can kind of chat with. Let's imagine that I'm an internal user. Maybe I wanna get access to a certain application, ask it questions around company policy, maybe provision me an application access in my identity provider.

All of these tools are gonna help design to help with that. And the general idea with any of these composite tools is that these aren't just, for example, calling a single endpoint as part of the API that we might have access to. The idea is that all of these tools like Paul showed you in the screenshot there are very well scoped pieces of functionality, and this is where you get that really nice benefit of the determinism coming in as well directly. So as you can see, this is an example of a tool that's currently provisioning application access into an identity provider.

And as you can imagine, that's a very tightly controlled process that I'm gonna be using that for. And so in this case, I've always got my starting point. I've got the set of things that I want my tool to do. But most importantly, you have full control over what's being returned back to whatever LLM was calling this.

And so this is a really important point when we're thinking about the token consumption and conserving tokens from that side, because instead of me just giving back a boatload of data from the MCP tool, flooding the context window with more and more data that it needs as a crunch through and burning through tokens, I can expose out these very well scoped pieces of functionality with these composite tools and make sure the agent has only got the right pieces of information that it might need access to. So maybe in this case, I just return back to my LLM. Success. I've provisioned the application access.

I don't really need to give it any extra data. But what's really powerful with this, what you'll notice is that I'm currently interacting with three different services. So this little guy up here is a call to a third party service through an API connection. I'm currently reaching into an IDP, in this case, Okta, but I'm also reaching into my HR system workday to actually check who this user is.

So all through a single MCP tool, I'm now combining and working with three different systems. And like Paul touched on in the demo, instead of me just going to these three separately as separate MCP servers, again, burning through tokens to get all that response back, it's a very well scoped and defined process for that specifically. As you can start seeing, I'll touch on and come back to that in just a moment, all of the stuff that you're doing with this is logged as well, and I'll drill into those logs in just a moment. But that's what all of these composite MCPs of tools are doing.

So think of these as pieces of functionality you want to add to this MCP server, but give you additional guardrails and control that you can add on top so that it's doing only the right things when it comes to those tool usage.

The next category of tools that we have is what we call our connector tools. So we have around sixty seven hundred connectors in our connector library. And so what you're able to do is through this single MCP server as well, you'll notice that I'm saying, hey. I also wanna include a couple of operations for Gmail, Jira Cloud, and Salesforce.

And I can come into any one of these, and I can update my configuration. And I can actually go through and pick which of these operations from this connector do I actually want to add to this MCP tool. So, again, instead of just giving free form access to the MCP server, this service, I'm now tightly controlling the types of operations that the user can use with this particular service as well. So, again, give me another place in which I can control what level of access that user has so that the MCP server is both flexible but gives you ultimate control about what it's doing and what services are being exposed.

Now a really important concept that we touched on a few times is, okay. Well, how do we make sure that we are dealing with the right users, we're getting back the right data? And what you'll find for a wide variety of use cases is that when it comes to the authentications, you typically have a choice. Right?

It's either a case where the type of tooling that I've got will need, for example, a service account. So maybe I'm reaching into provisioning an application in Okta. I probably need a service account to do that. However, a lot of other tools, though, more specifically, will need user provided authentication.

So we have this idea of dynamic authentication where either you could specify a service as being a service account, and it will use the same one across those tools regardless of the user. Or alternatively, you can scope it down to the user specific authentication. So you can see that here for both Slack and Gmail. So instead of it being a service account, I'm actually gonna use the user's Gmail authentication that when they ask you questions about what's in my inbox or who's in my mailing list or who are my contacts or send a message into Slack, it's gonna be on the context of that user.

And this allows those tools where it makes sense to actually dynamically adjust the equals based on the user that it's speaking with. And, of course, bearing in mind, we're aware of who the user is from this access management piece. So when they've authenticated through OAuth two to our MCP server, we know exactly who they are. We decided they should have access, and then we can, within the tool logic themselves, actually tweak which authentications we're using at different points as well.

Most importantly, though, we've also got this monitoring page, which is a fantastic place for you to come in and have this holistic overview of, okay. Well, who's running these MCP tools?

How often are they running it? Maybe I wanna drill down based on a certain workflow that was being done or a certain tool. Perhaps I want to drill down into a certain user. Right?

So I wanna see which of my users are interacting with this MCP server. I've got full visibility of this at all steps of this life cycle. So when they call the tools, when the tool executes, all of that will be available for me on one single panel that you can see here directly. And I can adjust this time frame around, of course.

I can tweak this around if I needed to. It gives you a lot of options for the different items that you need there for it. So these different places will give you one place to kind of bring together a single MCP server. Think about the functionality you want to expose through this combination of what we call composite tools and those connector tools.

It gives you a place to manage the access to this MCP server. And then most importantly, when it comes to actually executing those tools, are we doing it from a service user perspective or from the user perspective with that dynamic authentication? And then giving you one central place to log all of this as well. So you can see exactly, again, how often people are running it, what happened on each execution, and actually really drill down deeply into the specifics of all of those executions across your service.

So to kinda show you in action, what I've got is Claude here. Now I know Claude likes to have an outage every so often, so, thankfully, it's not happened right now for this demo, which is good. But what you can do is if I click onto this connectors, you can see that I've got two Tray MCP servers exposed at the moment. My ITSM agent one is that set of tools that we just went through a moment ago.

I'm going to kinda show you what that looks like under this customized section. You can see under the connectors, this is my full list of the tools that have been exposed through into, in this case, my client is Cord. Of course, there's various other tools out there that you'll be able to hook into it from an MCP connectivity point of view. You can see now that I've got all of these tools available to it from that side.

So what I'm gonna do is I'm gonna start a new chat, and I'm gonna ask it, what applications can I access? And, of course, what it's gonna do is it's got that MCP tool list. It should be able to take a look at the tools that it's got and actually drill down more specifically into those. So you can see it's like, okay.

Great. Let me double check my application assignments for Okta. Let me call that tool that's available for it. Let me go ahead and call these as necessary.

It's like, okay. Cool. Currently, I've got nothing provisioned in my Okta, which is actually correct. Right?

So it's been able to pull from that successfully.

So I'm gonna be like, well, actually, could I get access to DocuSign, please, in this case? So it's gonna be able to use that provision application access tool for us in this case by taking a look. Again, these are some of those composite tools that I was exposing through this MCP server now. But what you'll notice is that this is quite a, I would say, sensitive process.

Right? You don't want anybody to be able to go, I want this application, and then Claude goes and just provisions it because that would be a terrible idea. You'll end up with catastrophic licensing costs and all of that side. So what it's done is it's gone like, okay.

You're preapproved for DocuSign based on your team. It was able to use those tools looking into the HR system. Now it's using that slightly more powerful tool that can provision the application access. I'm gonna show you what's under the hood of that in just a moment, but it's like, great.

You're all set. It's now been provisioned for you in that access. So if I come on over, I should be able to refresh this, and we get a little DocuSign access there. Now what's really important, though, is that I can now come into this particular workflow tool and this one that was provisioning application access.

I'm gonna drill down into the actual workflow logs, and we're gonna follow through the steps that we just went through specifically for this tool. You can see it's just here, for six forty eight. I'm based in the UK. That's why it's six forty eight PM.

And as you can see, I've got this little purple icon here to tell me this was an MTP execution more specifically, but then I can actually drill down into the logs for every one of the steps that just happened for me to be provisioned application access. Now what we actually did, though, is that you'll notice at this very first step, there is a piece of data that will be sent through from the MTP client that will basically allow you to determine which user are you speaking with. So what we don't want is the LLM, again, just to provision, in this case, applications to anyone. I want it to be a tightly controlled process.

So it's got full context about who the user is. So what I'm using in this tool execution is while, yes, I'm using a service account into Okta, it knows the user that it's speaking with. So it's doing three about three checks, as you can see, based on these conditions to ultimately determine should this user have access or should they not. And that determination is using a combination of data from one system, figuring out who the user is from my HR system, Workday here.

So, ultimately, then if all is happy to actually go ahead and provision it down here, then you can see is this final step within the process. So very well very piece of helpful functionality, but still giving you those guardrails and controls to make sure that those tools are aware of the user.

Only gonna do the right thing, and it's only returning the right use data based on the user that it's speaking with for that one. The flip side of that is that what we can also do is, let's say, I send me a confirmation in Slack, for example. So in that case, what I'm gonna do is I'm gonna use a tool that's now scoped to my user authentication more specifically. So what will happen in that one is it's gonna look at that Slack tool or those sets of Slack tool that I've got within my section.

Now because this is the first time that I'm gonna be authenticating in, it's like, Do you want me to use this tool, your typical sort of process to approve that flow? And it's like, okay. I see a tool here that can get my user Slack channel list, which is great. So it's like, Great.

However, because it's a user authentication, instead of using a service account, it's now gonna go, okay. I just need you to wanna authenticate into your Slack account, and that will then redirect us to Tray where we can go through our normal authentication process, and you can securely set up your authentication, in this case, into Slack directly. I can come back over to Claude. I go, hey.

I'm done. And now it should be able to make use of that tool specifically. Now Tray itself, from a security point of view, we are managing the authentication, so we'll keep that refreshed as secure by default, but it allows us now to tweak around our actual tool usage based on the different users that we're speaking with where it makes sense for the type of tooling that you want. So you get this really powerful combination of the best of both worlds.

So it's effectively like, okay. Great. I'm gonna go through, and provide that. Now I've got a slightly second tool here for Slack that's gonna require that user authentication to actually send the message.

So we're just taking into account the scopes that are required here as well so that it can come through and actually send that message for us in Slack directly. Just to show you what that is, if we come on into that tool use itself, we can open our workflow logs. And what we should be able to see is our logs coming through directly for that as well. But most importantly, six fifty two, which is the time just now.

We also get this nice little icon here to tell me, actually, this was a user provided authentication at this point. This is no longer a service account like the Okta one. This is now scoped to my user. So if Paul was to use this MCP server, it would need him to set up his Slack authentication, and now we've tweaked that around dynamically for us.

So all of this comes together really nicely as part of our kind of agent gateway piece of functionality here so that you have a single MCP server that's exposed. You've got this flexibility to add on those tools, but doing it in a much more governed manner directly there as well. Hopefully, that gave everybody a preview of the kind of functionality there as well. And we've got a little bit of time here for wrapping up and the final questions.

So I'm gonna hand on back over to Paul.

Hey. Hey. Thanks very much, Luke.

Awesome demo. Hey. I know you have questions, but I'm gonna share after questions. So definitely worth staying a little longer.

We have a limited time report from Gartner, and you'd otherwise have a big Gartner client. We we're not gonna be licensing forever, so it's available now the next few weeks or so. So I'll provide the link actually for you just right after the q and a as well. So otherwise, you have to be a Gartner client, and we're we're providing it free of charge to you.

Well, you know, as always, Luke, you get all the hard questions. Alright? So so question here, do you offer group based access management to, you know, to, I guess, to MCP tools?

Yes. It's a good question. So there there's a few few layers there. The biggest one is that when a user's authenticating into into Tray through all of two, they are effectively a Tray user at that point.

That allows you to wrap around the kind of key pieces of identity that we have for actually accessing Tray itself. So your single sign ons, the identity management piece as well, All of that can be brought into the fold for determining should this user have access, do they want to authenticate that in, should they access this MCP server, and just make use of that based on those assignments. That's all covered by the access management piece to kind of control who they are, should they have and that just falls under our sort of native functionality already in Tray because they are, at this point, a Tray user for that.

So yeah. Absolutely.

Awesome.

Question here is that how do how do we stack up against that's have Microsoft Agent three sixty five gateway.

So I'm subtle a little bit familiar with this.

My my understanding is with Intensive Life Gateway, it it's it's it's great for managing agents, and you might you might also use it to manage existing TMCP services. But some of the things that Luke showed here, the ability to create composite tools, right, where you're add more determinism. Right? And you can do that visually as well as the connector library that we have. There's over seven hundred connectors. Right? It can also be exposed as MCP services.

You're not gonna get that with with h three sixty five, but I'm gonna defer to Luke who does have a little history here with yeah. Yeah. Luke, over to you.

Yeah. Absolutely. Yeah. I you say history. I used to more specifically work on on premise active directory when I was there.

So very difficult I'll I'll be sorry to interrupt.

But, no, I think Paul's spot on with some of that analysis there. I think there's a difference here, of course, between managing the agents. Of course, a tool itself could be an agent that you're potentially calling. There is a piece around our agent gateway around things like agent to agent and things like that as well.

And that, of course, has a small amount of overlap. I think the real beauty here is when you combine that with the composite tools that Paul mentioned, when you think about the connectivity that we have from our connector point of view, it just gives you a wealth of possibilities for the types of things that you're exposing through this MCP server, and also gives you a lot of options outside, I would say, of the Microsoft ecosystem as well. Obviously, not everybody is a full some people might be, but not everybody is a full stack Microsoft shop. There's obviously a lot of third party tools out there that bring into the fold with our extra flexibility that we've got from a connectivity point of view.

Gives us a lot of options on that piece as well. So, of course, you will find naturally some overlap, but I think it's slightly different in terms sort of the types of use cases that we're covering, especially when it comes to managing that MCP piece and giving you the best of all three worlds, really, whether it's connected tools, the composite tools, or bringing in other MCP services as well.

Got it. Got it. That that that's that's that's great coverage. The so question here is how does prompt injection manage specifically manifest in an MCP context, and how it's different from from prompt injection to stand in out of them application?

So there's two things. So first of all, you know, think about, you know, the standard prompt injection. Right? You know, pretend you are this, you know, ignore previous instructions and stat.

You know, instead of that, they'll do this. Right? I'll put JSON, those kind of things. Right?

The first is that if you've given your LLM a lot more skills, right, you know, you you've expanded skill set with MCP. Right? That's expanded the surface area for just regular direct prompt injection. Right?

Because now the agent can do more. Right? Because as MCP tools available to it. The second is indirect prompt injection.

Right? Which is what happens is the m c t MCP tool evaluates a web page or an email, and there's written white text embedded in email, which has ignore premise instructions, pretend you are this. Right? And so that's indirect prompt injection.

So, basically, MCP expands the surface area for direct prompt injection, and it opens up opportunities for indirect prompt injection as well. Anything to add to that, Luke? No.

I think exactly. That's that's spot on. I think that those tools that an MCP or a client has access to very often and you sometimes see it in Claude. Right?

Like, if I have an MCP server that I've added, if I just go, you can always run this, it's always gonna run this without asking me. And you find horror stories of people accidentally doing that with things like, you know, Claude code where they accidentally delete everything because, well, they approved all the actions that it can take, and then they come back and go, oops. What have I done? Because it's just got this, at that point, almost full access without that extra layer on top.

Whereas when you're pointing it through the sort of the agent gateway piece, so you know the tools it's calling. It's got the awareness of the user. It's a very well scoped process that it is doing. So you the user should be able to do that thing to start with.

It's not gonna be able to run away and and kinda do what it wants off the back of that. And that comes back to having a good core piece from the access management and the identity layer, so we know who we're speaking with, should they have access to the MCP tool. If they do, are we using a dynamic also they can't see everything they might otherwise have access to? Or are we just scoping down the functionality so that there's a few extra guardrails and checks in our tool logic from a composite tool point of view to actually restrict that and filter that down as well?

That's a great answer, Luke. Hey. Yeah. I know. While I'm sharing, I can't see the questions. Right? So are there any other questions to we should cover, Luke, that you can see?

No. I think there is I think we covered the majority of them.

I think yeah. I'm conscious of the time as well, so we can definitely follow-up on any of these. But, no, really good questions. Thank you, everybody, for for engaging with those. A big topic to to unpack.

Yeah. Yeah. There were some juicy questions there, and we're done. We, you know, we we have a log in them all.

I think we've we'll answer as many as we come to the timeline, and we'll follow-up. So I did promise you that report, and I I would absolutely encourage you to download it, not just because I'm saying it, because we are in a post report, and it's yeah. I don't think well, I think we're the only vendor that's actually licensing this report. And so, otherwise, you're gonna go and get it from Gartner, you're be a client, those kind of things, and we're offering it, you know, free of charge here.

So it's the best practice to count at MCP security risks. Obviously, I shared that triangle, you know, that earlier.

You head over to Tray dot ai, and you go to you know, you can map to it. Or if wanna use the direct link here, you know, resource reports, ebooks, Gartner insights, you wanna take a screenshot of that, you can go ahead and, you know, use that link and say that this won't be available for won't be available forever. Okay? And and also, you know, hey.

If you wanna go and get a demo, right, you know, we can help set you up with that and, you know, chat with our team. And we have, you know, folks like Luke who know this stuff cold on the MCP side of things. You wanna get, like, a little bit more around, you know, risks, opportunities, you know, how an MCP gateway works, you know, what what what is a composite tool, what is a connected tool, what's, know, the some of that use user credential management or if we can take you through all the details on that as well. So it's a great way to kinda get informed, and, you know, and have that discussion internally as well.

So, you know, obviously, we we welcome the chat. So, you know, I know we're I'll get some time and a little over. So thank you very much everyone for attending wherever you are. I know it's no small ask to take an hour out your day, so I hope you found it really valuable.

And also thank you, Luke, right, for, for fantastic demo and answering all the hard questions, Luke.

And, and with that, have a great day, everyone. Okay. Bye.

Thank you, everybody. Cheers.