First one is I think for best for you.
Do you think many of today's built MCPs Are vulnerable to hacking attacks? Yes, short answer
Yes, I think the protocol MCP is new right we all know that it's in you So just like any other existing protocols like TCP IP over time they get to improve on this protocol and you see specifications released which are built around redesigning the architecture from the base or improving the quality of the protocol.
Just two months ago the first specification for MCP was released and they've addressed a lot of concerns around authentication, authorization, these problems that are native to MCPs.
I think it's a question of speed versus security here. While it's pretty new, it's heavily adopted. I think the only agentic system to do that doesn't have an MCP somewhere within it. So I would say all today vulnerable.
But of course, you can actually build defense in depth strategy, which is XYZ checks must be in place before you speak to an MCP or invoke an MCP. And that's how you stay safe.
until it matures to the point where a lot of revision goes into it then it's better it's still vulnerable that's the truth excellent thank you much very good
let's move to the next question yeah so one for Tommy what's your main challenge you're currently facing like in life yeah that's a good one well I would
probably say capacity is a it's not a major problem but thinking about how much capacity we have because so as an agency we build our own internal tools but we also build tools for clients and so there's a delicate balance between trying to allocate the right capacity each week and trying to pick up the right number of tickets
and I think Moochbot isn't naturally good at assessing capacity of humans and even of itself and so that's one how much can we pick up how much of it is client work versus our own internal internal products? What should we be prioritizing?
That's, I guess, one of the main challenges. It's around capacity and that delicate balance between client work and our own internal stuff.
Excellent. Thank you very much. I think it's a common problem which we are all facing.
Benedikt, a question for you. How do you measure, let me read that word by word, How do you measure if the newly generated agents, in brackets, generated through observability and agents' creators work well or not compared to old ones? Is that another type of looping system, new layer of observability? Doesn't that possibly mean changing the entire system architecture and causing issue and costs? So that's quite a detailed question.
So if I try to understand the question, so you're asking if you build a new agent from scratch from whatever observability, I guess. So actually the system is quite, or AI agents are quite good in actually guessing. They'll give you their best guess and then what we do is there's a human review, kind of what you do too.
There's this planning session and the same for the scorers or for the judges. Every time it runs it by you and you judge it. and then it gives you this hypothesis assumption list and then you tell this is true, this is not true, this is not true and you give the feedback and then after this planning, speccing session, then you actually go into the building so you capture the human business intent even in the very beginning. So this is kind of why we always say we sit on top of the loop where you're still the person with the business, the context and I guess this also is what you do with Mootspot.
So how do you know that this works better than the old one? I think that was the other hard question. So we know by the scores basically and the scores are defined by you. So because you have been part of building the scores and the scores are basically your representation of your business logic.
So in the end what you do is you make a context transformation from I'm doing this process and I'm transferring this process into a checklist the agent has to approve. And this transformation allows you to then do it. And this is kind of the basis of all reinforcement learning. The score is basically what AI is trained on, and the scores define the outcome.
Okay, excellent. Thank you very much.
Dyson, back to you. Okay. Would an MCP help to gateway help with mitigating some or most of the attacks you described during the session, and how?
Some, yes. Yes, and I think I actually, one of the slides I had, you can see the gateway was the target. It wasn't the MCP directly, because most companies don't expose MCPs directly. They put it behind the gateway and force control, governance, compliance, and security control at the gateway. Then people interact with the server behind the gateway.
Now, to get past the gateway, authentication is the first thing, right? So once you're authenticated, you're authorized, roles are defined, meaning what you're allowed to do, either mcp read or mcp write the two spec defined i think that kind of architecture is the first layer of defense because if you have that in place i can bet you would cut down close to 20 30 percent of the attack but i think the other 80 70 80 percent of the attack is a trust once you get
past authentication one of the engagement i was actually we were testing the gateway itself and we're able to bypass it's all of implemented we're going to bypass it once you get past that if the back end systems themselves have not been designed to be hardened it's game over so to answer the question yes not a hundred percent not all i would say 30 40 or 20 30 it's usually the
first line of defense but also be sure you do your two schema specification definition understand the schema validate each input at the schema level because that is where the attack actually is more, because once you read the schemas, then anything goes into them.
Excellent.
Can I ask a follow -up question to this? Yes, of course.
So when you pass, so after the gateway, you get an authentication cookie or like a session cookie. When you pass it on through the MCP2 call and everything and down to the tools, would that prevent this? Because then in your backend system, you can do like a check again if this is an authenticated request from the beginning, like against your auth server. Would that help implement this or would that still be because of MCP doesn't have auth yet or it's not properly implemented or would that not be enough? Because that's what I did, I just want to figure out if that's enough.
Keep it short, but I think that's an excellent conversation. Yeah, that's actually an excellent implementation, right. I think that the heart of the problem is the fact that I keep kept on putting trusts, right. You handle authentication authorizations, now does Does the MCP server assume that and passes that back to the back -end services? That's the question. If not, because the MCP speaks to the back -end services using a different authentication authorization.
Okay. All right. So, you as the user, you authenticate exactly what the user authenticates. The identity must flow all the way back to the back -end services because that is validation. Meaning, this user is locked in to only do this, this, this. Now, if the MCP server is speaking to the back -end service, it must assume the role that the user has. and lock in that rule to speak with the back -end services. That way you defend it.
Okay. Okay, I think that's a great question. I agree. That's wonderful. 100%.
What I'd like to do is open the floor for one or two questions here outside of that. We have here some comments that I'm curious to learn and so on. Anyone kind of outside of that?
I think you had kind of a question already before. I can use the microphone.
Yeah, specifically for Dai. You mentioned the review phase. Aren't you using any help at that phase? During the review phase? Yes.
Yeah, so we, excuse me, I typically review it myself because what happens is that 7 a .m. and 1 p .m. run where Moochbot completes the work, it will already spin off some sub -agents to review the work and then I will see what Moochbot has done but what the review agent has reviewed as well
and then I will take a look at it myself and so I look at the output but I also maybe take another agent and then let's look at the code look at how it's assembled but typically it's me it's me going in and looking at it myself yeah so first call review agent second call me and that yeah that's typically how I
do it thank you very much I think that shows kind of clearly what what is required. We all need to rethink our roles, and there is not a simple answer. It's not just human loop, I think that's simplifying things, because if you have multiple requests, it doesn't work anymore.
If you have a thousand things you have to review, well then the seven to one doesn't, isn't enough, so then of course you need different motors, so very good question
and thank you for the answer so yeah can you can you agents in the in the space body uh for for example to to get good health um yeah can you be the agent uh for human uh sorry repeat the question that is definitely above my pay grade he's asking whether you can build agents within to put them within the human body to assess your health yeah
Yeah, that's completely outside of my field of expertise, but I imagine it's possible. Do you guys have any?
Yes, there are quite a number of research in that space, actually, and I think I've stumbled, I love to read research papers. Perfect, perfect.
I have stumbled on quite a number of research papers in that space, right, where they are building agentic systems that can actually interact with you, Like interface with human, again, most of these smart genetic systems are actually built based on how the human mind works at the heart of it, right? So, the layer is already there.
And in today's world, there are quite, I think, one or two companies in the States, early phase startup, researching how to build harness in a physical harness where you can then, more like a wearable or something, then you can actually interact with human interface. With human, yes. Very good. Good.
So with that, again, a big applause for our three speakers.