MCP LFI in 60 minutes (or your money back)

Welcome to zero to LFI in 60 minutes in an MCP server. Uh TLDDR, we're breaking new technology with old really old tricks and because you know uh there will actually be an explanation for why this happens all the time later on in the talk. So stay tuned. Anyway, get my prisoner view up here. And so, who am I? My name is Kurt Boberg. Hello. Nice to meet all of you. Kind of sort of. This is kind of asymmetric, but uh yes. Hello. I will not remember any of your names. I'm very sorry about that. I also kind of have face blindness. Um but I am a staff security researcher at Smra. What does that mean?

I pretty much just like break computers as my day job and for some reason people pay me for it which is actually pretty awesome. Um and like more specifically I kind of understand computers. A lot of what I do is read documentation. Actually at my first job uh I was actually supposed to build and deploy software. I was formerly DevOps. Uh, and my DevOps manager got really tired of my nonsense because I spent a lot of time reading documentations and figuring out how PowerShell worked and less time actually building code to deploy other code. And he got sick of me and then uh the director of AppSec at that company was like, "Hey, you know a lot about

production. My team doesn't know anything about production. Would you like to come work for us?" And I was like, "Yes." And that's how I got into apps. So yeah, basically I like understanding why software was built. Uh lots of people are like, I love software. Computers are the best. Uh computers are actually the worst. Uh but software is built to solve human problems. So like outcomes and like actionability are really important to me. And so we're actually going to talk a little bit about the agenda. Cool. There's a little bit of display lag over here, so I'm kind of So, sorry about that. Anyway, so we're going to start with what is the model context

protocol? A super quick primer to make sure we're all on the same page. Uh, show of hands. How many people are familiar with the model context protocol or MCP? Cool. I see lots of hands. Uh, unrelated question. How many of you are left-handed? Not as many as I expected. Hm. Interesting. Anyway, uh next we'll talk about a bug I found in an MCP server in a hilariously short amount of time. Uh we're going to do a liveish audit of open source an open source MCP server that uh at least as of earlier this week had the same code. Uh we're going to talk about how defense and depth actually works and you should like do it

and stuff even if it's not fun. And then I'm going to give you some takeaways and hopefully I will pace correctly and I can answer some questions. Uh that last part I'm kind of bad at. Uh and my timeke keeper right here in the front will keep me honest. Um I'll do my best. Anyway, let's go. So what is MCP? It is a standard for LM communication with external tools and data sources. MCP servers may be local or remote. Uh, usually the very first one is operating over standard IO. I don't care about that. So, we're not going to talk about it because if you're already on the device, you've already won. Like the I'm

an appseac person. I am very much not interested in building exploit chains or anything like that. Uh, I am yield. Oh, I popped calculator. I won. On to the next problem because I don't care anymore because I have proven that you can do the bad. And I can show that to an engineer and they'll go fix it because they understand that I have done the bad and my job is done. This also makes it so I can go much faster than attackers because all I have to do is find the problem. I don't have to make the problem an actual problem for the business which is a thing. If you're a defender, you should also take away from

this talk because it's way easier to get engineers to fix stuff if you just go, "Oh, look, I popped calculator. Do you understand why that's bad? Great. Go fix it." while an attacker who gets into the infrastructure or whatever has to then go build an exploit chain to do whatever it is they want to do. Also, remote services are bound by the laws of networking, right? Like if it's a remote service, it has to talk over something to go talk to the service, right? Like there's no like magic telepathy for LLMs to talk to MCP. It has to talk over something we already know about. So the specification I'm going to like the slides will be available. There's a

QR code at the end of the talk if you want the slides. There will be links and stuff in the slides yada yada yada. I'm just going to very kind of gloss over the specification. MCP is based on the LSP language server protocol which is a very old technology for things like how IntelliSense works in Visual Studio. It's just an LSP talking to the end. So that's kind of what it's informed by. So if you're familiar with LSP and stuff, that should feel pretty familiar to you. Uh it's client server. The two things in the spec, explicitly in the spec are standard IO and HTTP. The spec does not prevent you from doing any transport you want. You can do gRPC

over whatever. You can do websockets. It doesn't have any prescriptions against doing that. it just doesn't have any like reference implementations or specifications for how you're supposed to do that. Finally, the way that it transmits data is JSON RC RPC because of course it is. So, look, it's the shiny new technology model context protocol. Oo, it's so new and spicy. What could it possibly be? Lol. It's JSON RPC over an API. Haha. Uh, is this new? No. JSON RPC 2.0 is from 2010. JSON RPC 1.0 is from 2006. How many of you were still in grade school in 2006? Yeah. Yeah. Not new. We know how to deal with this already. I think I might have accidentally Oh,

right. Sorry. We're going back. I have talked about the specification again. Anyway, we're going to talk about resources. Resources are exactly what they sound like. Documents, source code, images, build artifacts, anything that you might want to hand to an LLM as context. This is what like rag talks to retrieval augmented generation under the hood. If you have an MCP server that gives you rag, the next thing is prompts. This one I really don't understand. If you like have any idea why MCP servers do this, please help me understand because it's weird. Like all it is is you can ask an MCP server for a prompt to give to your LLM client. It's just it's just a

string. It's like here's some context engineering I did for you. Cool, I guess. Anyway, it's not very interesting, but is in the spec. Uh, I think it's con it's basically just context engineering for your packaging for consumers because they can't be bothered to Google context engineering and read like the first five results. I don't know, make it make sense. Uh, this is the interesting one. Mostly what we're going to talk about tools. Tools are where things get really interesting. Tools allow an LLM to do something other than read a file or make text, right? Because the first version of chatgpt or claude or whatever was really just, hi, I'm a web browser. You can put text into

me and I send you responses. That's all I do. Woo, I'm so neat, but I kind of look like a human. Woo, but I can't actually like do anything like invoke shell or whatever. Tools are how you do things like go call who am I? Go call curl. Go do something in office or shareepoint or whatever. Go execute arbitrary shell instructions. Which is kind of why we as hackers are very interested in this part of the spec because this is how I make the computer do what I want instead of what you want. And finally there's sampling. Uh sampling is not widely supported yet. Uh but it is like this bizarro uno reverse thing where the server can ask your LLM

client for a chat completion and then get the response. And there are some caveats around how that is supposed to be managed by a human. And the spec says you have to, but I suspect that there are going to be people who then don't do that part. And that gets bad for just use your imagination and there will be future talks on that at some point, but I'm just going to say sampling. It's there. It's in the spec. It's interesting. We'll talk about it later. So tooling support for MCP is all real good. Building a server for MCP and Python is real easy. You pip install MCP and then okay, cool. I have a library,

but it's hard to use, right? Wrong. This is what making an MCP server looks like in Python. That's it. You write a function, you go add MCP.tool, and then you serve an MCP server, and it just works. You slap it on a WSGI server, you put it on the internet, and then people start poking at it, and that's where you run into problems. So, we're gonna talk a little bit about the technology life cycle. This is going to be an evergreen life cycle explanation of all new technologies ever. And I see some familiar faces in the audience who have probably seen this exact diagram before from a shared co-orker of ours, John Heman. Uh you can take this at the end of the

slides. There will be a filledin version in the attendee versions of the slides. You can take it with you and uh beat engineers over the head with it because it'll be really funny. And also it's evergreen. It works all the time for everything ever. Yeah. In the beginning, a new technology is invented. Woohoo. We invented MCP or LLMs or YAML or JSON or pick your poison. We forget everything we've ever learned about bugs. We recycle every old bug class, every single one in a new hat. We reimplement the same defenses and then a new technology is invented. We forget everything we've learned about bugs and so on and so forth. The very first version of this was drawn on a

whiteboard for me a little over 10 years ago at docysine and it was originally for gaml and I'm sure there was a version of it done for JSON and there was a version of it done fornet and there anyway you're get get where I'm going. Um this is the author in question John Heman. He's currently the CISO of proof uh and he works with a bunch of other former Microsoft people. He's been in the game a very long time. He did things like remote roots and Microsoft Exchange. So like I send you an email and own your exchange server. Very smart guy. This is where that came from. It works everywhere forever. You can basically

just go, "Hey engineer, tell me about that new thing you're playing with." And then you can just apply this model to it and find new bugs that are actually old bugs. And then you can just fix them the same way we've fixed that same bug the last thousand times. This is also how I got my first CVE. You can go look that one up. It's uh rce via uh d serialization in yaml.net which I found because the engineers were like hey we want to use yaml for something and I'm like I'm going to go audit the one net parser that works and yeah I got a cev for it. So at this point some of you are being

like um I was promised hacks where are the hacks and so here's how I broke Samrub's hosted MCP service in 30 minutes. So, in the beginning, we're going to set the stage. Uh, technically, this would have worked way better on Friday, but here it is. It's Saturday, but pretend it's Friday. It's Friday. I don't know about you all, but Friday is generally not the day to start big projects, especially Friday afternoon. Uh, you don't drop big bugs on engineering. all you will do is make them mad and it won't really get cycles until Monday anyway. So, as a security person, you're kind of just waiting around for like the I don't know, the person who's constantly trying to drop

struts on you at 4 p.m. on a Friday on your net stack. This is totally not a real example from my own experience. Uh or in general, start anything you can't finish in a couple hours, right? Friday afternoon is for chilling and checking in with your stakeholders and generally having a nice time and hopefully leaving a little bit early. Hey, MCP hype has been all over LinkedIn the past couple days. Hey, wait a minute. We have an MCP server. I should go look at that. So, I reach out to my buddy Lewis and I send him this Slack message, which if you can't read it, you still remember any Cly command injection vectors? I'm trying to get the MCP server to do

something illegal. And then a minute later I was like I looked through our Sim GRE backlog and it says no. I am very sad because I was hoping to have a hilariously fast five minute route in MCP. Sadly no. We actually like dog food our own software and it turns out that it's actually pretty secure. Very good for customers very boring for me as a carried researcher. No free after lunch dopamine for me anyway. So appsc people what do we do first? We immediately read the code, right? It's literally just a repo. Hit it with your eyeballs, right? If you have code literacy, that's really important, right? Seeing how stuff is made me understand it more completely. I

like whitebox testing a lot. I like to get a sense of the codebase and who wrote it. What design patterns do they prefer? How is business logic organized? What might have led to their architectural or design decisions? because software is still a reflection of the human who wrote it. At least for now. Uh Claude and Codeex and C-pilot are going to mess this up a little bit in the future, but you know, for now it still works. Uh white box testing is also a great thing to pair with static analysis for like trying to exploit findings because it's like a cheat code. If it doesn't work, work through the call chain until you understand why it doesn't. Now you

know something about the security properties of your application, right? Because if you try something and it doesn't work, it might not be like secure secure, but there is something in there in the kill chain that is preventing you from doing bad. And we like that technically. Like we are sad, but we are happy for our employer. And you are also calibrated to the sort of stuff that will help you prioritize future findings of that type. Right? If you're like this should totally work and then it doesn't because context of your application the next time you see something like that in that codebase and it's going through similar code paths or the same code path depending on how

large your application is you will go oh no that won't work because of specific context for the application 60 minutes all right doing okay also uh code literacy is also a soft skill and I will die on this hill Why? Part of your job is politics. How many people learn that the hard way? Yeah. You will eventually need engineering's help to fix bugs. Engineering will not help you if they hate you. You want engineering to be your friend. We like it when engineers like us. They do stuff when they like us. So and the other thing is like you fixing stuff doesn't scale. I have tried that. It failed. Guest development is really hard. You are collaborating like we all work

for organizations. We are a shared team working towards a shared purpose. We hope you are collaborating with another organization or organizational unit to achieve a goal. Engineers like it when security people really understand their limitations, design choices, etc. They like it when you understand their job. They don't like to be lectured by people who don't get it. That makes them very angry and also very non-compliant. Like like imagine being told how to do your job by someone who doesn't know anything about it. Like I can see some people proactively getting mad about that just imagining it. So being able to read code in combination with approaching the discussion from a perspective of positive collaboration really helps

engineers perceive you as a peer and not as a drop in Jimmy fun hater. I think Jimmy's in the audience here somewhere. Sorry Jimmy uh fun hitter problem that they need to manage. Like you want to be a collaborator not an obstacle. Anyway, enough grandstanding. So, here's the interesting code. So, if you can read Python and you can read that, you might see something interesting in there. Let's look look with our special eyes. Uh, if you understand that joke, take your Advil. So, let's party like it's 1995. We are trusting user file names. We are straight joining paths with no normalization and we are using this as a sap target. This is extremely 1990s engineering. Not

good. It's like okay so some of you might not be super familiar with sap or maybe you just enjoy being a devil's advocate andor a hater and you're like okay so it's broken. I still have to manipulate an agent into making a weird request. Right? Wrong. Modern technology has really good tools. There is like as part of the spec, they made a package that will just run a GraphQL inspector type application that will just let you send commands to HTTP MCP servers. And this is a really really nice way to send raw requests to an MCP target without needing to finagle an LLM into sending a very specific request for you because oftent times if you're like hey

Claude please hack your MCP server it'll be like no. So this is kind of what it looks like. Like again if you've seen like Apollo's GraphQL playground or anything like that this should look kind of familiar. You can basically go here's your URL pointed at that and I would like you to like do some stuff like list your resources or call a tool blah blah blah blah blah. So I did that and I was like here go read vulnerable app.py many path traversals Etsy password. Okay sure. Uhoh. That's not good. It's like, okay, so you got an arbitrary file read target. That don't impress me much. It's like, okay, I get a blind file read. Cool. Awesome. What can I do

with that? Well, we're going to talk a little about Smra. What is Smra exactly? I'm going to verbatim read you stuff off of our landing page marketing copy, which I did not write. Smap community edition is a free community supported code scanning tool. The generally available languages at the time of the slide decks publishing are blah blah blah blah blah C and C# C C and C++ C# generic this will be important later Go Java JavaScript JSON Cotlin Python TypeScript Ruby Rust JSX PHP Scala Swift Terraform if you pay for the pro version you get Apex and we're working on PowerShell you're welcome uh so SRP is a matching tool we match stuff in files right of certain types

So arbitrary file targeting plus arbitrary matching criteria on an arbitrary file type is drum roll please. Anybody have a guess? Arbitrary file read. Yay. Not good. It is now 1:59 and I send Lewis these messages. So for those of you who were eagle-eyed and keeping time tag reset, we're keeping track of the timestamps on these messages that was 28 minutes from first look to PC. So approximately the length of this talk thus far little bit under we're actually at 22 minutes. Okay. So six minutes from now I find this bug. So I send this message which is again what you're not actually supposed to do but happy Friday. TLDDR arbitrary file radar hosted NCP server. I don't have a full exploit yet

because again I'm a defender. I don't build full exploits because we don't do that here. We just go, "Yep, you can do it. Please go fix it." And so basically, you can go provide a malicious custom rule that matches the file to a meta variable. Provide an app token so the finding gets reported to Smra cloud. And then you can go pull the contents of any file on the disk out via the app profit. We're done. Yay. Also, that's a spec violation. Lols. Um, and we'll talk about that right now. Actually, speaking of spec violations, nuance will get you if you're not careful. This is the Graphana MCP server. It kind of famously made waves

because it like had no authorization on top of it a while back. Uh, I think it still doesn't if you deploy it in certain configurations. Uh, to be very clear, I am not picking on Graphana. they just have a really good illustration of why details matter and lots of people will mess this up in a lot of ways a lot of times to the readme. So it does have some arbback permission like graphfana like if you're familiar with graphfana log aggregator blah blah blah lets you read logs from your services. Uh they do have like graphana the tool has a bunch of arbback permissions and those are needed to function properly. The MCP server has

a crap ton of tools. Graphana's official stance on how to set up this MCP server to work is just give it an editor role for the service account and stick it on your MCP server. So like yeah, just like give it a huge read write to everything credential and turn on the things you want. Yeah, how many people are kind of upset about that right now? Yeah, you should all be upset about this. Anyone who's like, "Yes, I would like a programmatic editor role to all of my logs." Maybe not the greatest idea. People put the wildest crap in logs. Like I have found user session tokens and like encryption keys and all kinds of nonsense in logs. You do not

want attackers nosing around in your logs especially pre-auth, which is what this lets you do because MCP also has sort of an OOTH or no authorization model. And if you've ever met engineers, they do not like implementing OOTH. So if you give them an option to not do ooth, they will take it. Especially if it's an internal tool and no one will touch this ever. It's fine. Yes, it is not fine. All right. Enhance. Yeah. One service account. Anything you want graphana the MCT the graphana MCP to do has to have credentials for everything. And the suggestion is yeah, that's fine. Just give it an editor role. So, do we support HTTP transport SSE streamable HTTP? We sure do. If you

fire this thing up in your infrastructure, there will be an HTTP endpoint sitting there listening that you can go point MCP inspector at and like just go call Graphana tools with credentials that live on that box, not that you necessarily proide yourself. And yeah, so how does the MCP server get these credentials exactly? From the environment, it's just like on the box that the MCP server is running on. So like you it's just it's classic confused deputy. Like you just send it a hey MCP server, I'm going to ask you real nice to like go read all the logs for the O service and please send them all back to me. Okay, thanks. Bye. It's

like okie dokie. Here you go. I don't know who you are, but it's fine. Uh, or I guess you can read them from headers from the request. >> Why is your LLM client sending custom headers to your MCP server? Because that's like super illegal from the spec right there. MCP servers must not in big letters accept or transit any other tokens. Big no, not allowed. Don't do that. No. So, spec violations being what they are, this is not the worst thing, right? It does result in poor handling of user credentials because if you're doing the HTTP header off, like what is you doing? And like in normal operation, you're giving your Graphfana credentials to an

LLM that's probably not locally hosted. Maybe not great because like that that's like automatically credential leaking to a third party vendor. Like you will probably cause an incident if you use this with like an anthropic LLM. However, if I saw an HTTP transport graphana MCP server in my red team travels, I'd probably just go hm MCP inspector. I'm going to throw commands at it and see what it does. Might just have a service account with wide access to the company Graphana instance. And we all know logs are worth their weight in gold to an attacker. So MCP is kind of still the wild west. Like this talk was originally written a while ago and unfortunately this is

still true. But there is good news. Container hardening saves the day. This is a literal quote from me talking to our CTO and I was like, "Defense and depth is preventing me from doing worse. This is me lamenting the inability to get a shell on the container." Why is that? Our CTO is paranoid AF. He built this whole thing for untrusted code or why that underappreciated container hardening project you're working on is actually super important. So if you're an intern and you get handed a container hardening project, it's actually really really important. And if you do a good job, people will appreciate you and remember you. I still remember the intern that worked on our golden image

project and I see him at Defcon every now and then. And he has been very successful because he put his whole heart and soul into that and he did a great job. So the MCP server ran in an isolated container workload in EKS. It was provisioned with an app user, not a root user. People skip this step all the time. It makes me sad. The app user had no real permissions outside of the app directory and the public open- source code was receiving much more development attention and was much more secure. Uh the other quote from my uh the CTO when I was like, "Hey Drew, uh you did an oops and I owned your stuff." He was

like, "I'm just hyper paranoid, so I always use AWS to isolate workloads." which is a really good attitude to have actually. All right, so let's talk a little bit about takeaways. What if I told you that MCP bugs are exactly the same as the old bugs? There's a little bit of new context to learn, little bit, but you can largely use your existing skill set. If you're an API hacker, go nuts. MCP is shooting fish in a barrel. Yeah, under the hood, they're just JSON, RPC, HTTP APIs. We already have a pretty good mental model of how to think about these as building blocks for exploit chains. Use that to your advantage. Remote servers in particular are

interesting because their callers are not humans, nor are they deterministic. So either the human has to authenticate on their behalf such as with OOTH or you need to pass credentials through against the specification or the MCP server just has a credential it uses and anyone who asks it for something is considered authorized. Big yikes. And that happens more often than you would think. Uh and people cannot help giving these damn things access. Like it's it's sad actually. The command line is and you know we'll reset part of the reason this happens is the command line is the universal glue for making functionality fast. The whole LLM space is moving at breakneck speed right like how many people have heard of

openclaw molbot etc yada yada yada uh how many people had heard of openclaw like three weeks ago four weeks ago. Yeah, right. Like it's everyone knows about it now. A month ago, maybe 10% of you. It's going super crazy fast these days. Staying competitive often means getting things done yesterday. Shortcuts will be taken. Mistakes will be made. Look for those mistakes and it'll happen to you. Smap is a security company. We build a static analysis tool that looks for problems like this that is reliably deployed across almost every project except for the CTO gets a B in his bonnet and go home goes and home rolls something and then forgets to wire it up to CI and ships it and puts

it on the internet and suddenly oops it'll happen. Not being perfect is okay. Mistakes are opportunities for learning. We're putting AI in it everywhere forever. How many people work for a company that is putting AI in it? Yeah. Right. If you distribute software or have software involved in your business, somebody is working on an MCP thing somewhere. If you're like, "No, they're not." You just haven't found it yet. And finally, Cursor, Windsurf, Copilot, Cloud Code, etc., etc. Any team at your company can now author these things. The barrier to building one of these things is zero and they can put them on the internet because Windurf Cursor Claude Codeex etc. will write them deployment scripts to

put it on the internet. Claude can write you terraform plans. Maybe not entirely correctly and almost certainly not on the first try, but it'll do it eventually. Basics matter. If you can hear this picture, I like you. Container hardening is awesome. Instead of having to be clever and insightful and borderline clairvoyant one time, you have to do it many times to actually do anything meaningful. As defenders, we like this because every time we make attackers do more work, we give them an opportunity to make a mistake. And that is how we catch them because every time they make a mistake, they light up the logs like a Christmas tree. You want to give them as many things to trip over as

possible. When you find cool stuff, teach people. Like, this seems like dumb and obvious, but people forget to do it all the time. Every time I find nonsense like this at Smrep or anywhere else, we have like a weekly demo day where people share stuff they're excited about. You know what I do when I show up to these? I'm like, "Hey, you guys want to hear about how I like totally broke the app this week?" And then I tell everyone from other researchers to engineers to the finance people and the people team, hey, look at this like terrible thing I found in software and here's how we should probably fix it. Because of this sort of

culture of knowledge sharing, I literally have friends in our sales org who own flipper zeros and know how to use them. Like this is a we're just like you will just make new hackers doing this. Like you should just do it. It basically free. Teaching security-minded folks and junior researchers how to bug hunt and how to compassionately communicate findings is like magical. Imagine if every engineer in your org was as good as a firstear college appsac hire. Uh how many folks here like work on like appsac or like prodac teams? Uh, how many of you are a ratio better than 1 to 200? I don't see any hands. Right? Think about that scale like and

think about how big your team is versus how big how many engineers there are. Uh, I was the lone ABSSAC person for an engineering or of I think 1500 people. I got real good at teaching ems how to look at logs from the perspective of the security engineer. I had a lot less work to do after that. It was great. If you have the privilege of hiring junior researchers, dangle like juicy threads in front of them and then just lead them to the finding. This is how I learned to do what I do. My mentor would basically go, "Hey, like this API service is interesting." That's it. Go find it there. It's in there. I promise. Because that sort of

bug hunting is like catnip to curious people, especially if they know there's an answer that's in there. Like he cuz he would do that. He would just go, "Yeah, I know there's a bug in there. Like I am sure of it. I know exactly where it is. I'm not going to tell you where it is or even where to start other than like it's in this service. Have fun. You have four hours. Go. That's how I learned. I got thrown into the deep end of the pool. That may not work for everyone, but it worked for me because I had a good manager who could like look at how I approach the world and be like, "Yeah, that'll probably

work on him." It did. Here I am. Be nice to your engineers. Like please like if you take one thing away don't be a jerk. Your engineers did not write bad code and they are not stupid. They made a mistake. Tops. You are a team. You are all working together. Teams do not criticize mistakes. They work to make sure the team learns and grows from them. Engineering has already figured this out. Blameless retrospectives are kind of how we do engineering now. And engineers who work for teams that don't do that are like I hate my job and I want to leave. Like this is a solved problem. We shouldn't be redoing it. And yet security is just so impulsively the

department of no. They just have to like beat on it and just be like and you're you were wrong and you did bad. No, no, no, no, no. We made a mistake. We're learning from it. We're preventing it in the future. And let's see, we're at 38 minutes, so I'm actually got a little bit more time than I expected for Q&A. I am happy to answer questions about MCP or AppSac or anything else. Burning questions. Go. Yes. Okay. So, if I'm hearing the question correctly, it's how do I communicate to engineers that I'm curious about their line of work? Is that correct statement? Okay. So this will be different for everyone. I think the important thing is to approach it with

authenticity like be genuinely curious about their work. uh as I think someone I was it the keynote I feel I have had so many conversations and my brain is so cooked from being at bides for two straight days that I can't remember where I heard it but I heard it somewhere in the past 48 hours someone said it takes 9 months to build a relationship like that is absolute facts like when you land at a new job as a security person you should go meet all of the em that's engineering managers for the students in the room. I'm very sorry. We love acronyms here in corporate America. And if you don't know what one of the

things that came out of my mouth was, please like yell at me and be like, I don't know what those five letters mean. Please explain it to me because I forget. Um, talk to engineering managers and like figure out what they build and how underwater their team is because they think about that all the time. I guarantee you. So understanding what they build and what their load is like is the kind of first place to start because if that team builds like a like business critical service and they are deeply underwater, you need to be very compassionate with that team because they are all at the very least feeling like they are staring down getting fired

every day and you don't want to pile on on top of that because again we want engineers to be our friends. Engineers are friends not food. For me personally I have a like very mathematics heavy background. Uh a lot of the way that I approach the world is very first principles and architecture based. Uh I am not a software engineer by trade at all. Uh, I have sort of absorbed a lot of that stuff from reading documentation and specs and I do dumb stuff like check out books from the library like high performance.net but like that's not normal and doesn't have to be you. But the the important thing is approach engineers from a place of

genuine curiosity. And it really does help to understand at least how to read and write one language. So you kind of understand their job in like in your bones because people who don't get it don't get it. And they there is there there is like instant social capital from understanding the misery of staring at a stack trace for an hour and a half going why is this broken that like immediately gives you more credibility to engineers and I'm not saying it's fair but it's how it is and you don't operate under the how it should be model you operate under the how it is model. Does that answer your question? >> Yes. Thank you. >> Great. Cool. Next question. I know you

have more questions. Yes. Okay. So, I'm repeating the question. I think the question I heard is given how easy these are to build, how do you communicate to the people building them that they are just adding attack surface and new ways to shoot themselves in the foot? I am a researcher at a smallish scale up with a whole bunch of people who by and large are massive AI skeptics. So, I don't really have to do that right now, and I'm somewhat grateful for that because woof. Um, I think it's really just an extension of education and like almost just developer relations. you should already be doing with treat anything that you didn't write yourself with a

hefty amount of skepticism. And don't put things on the internet till you're sure. And lots of people skip that second part because they're like, I just want to go do a cool thing and see. And I get it. I get the desire to ship and see a thing that you made out in the world, but I think a lot of it is just getting engineers to stop and think about risk at all because a lot of engineers don't like engineers are like way overindexed on building. They really love building and that makes them real good at their jobs. But builders need that feedback loop. They need to have a thing that they're like, I made

that. That's a really important part of like their dopamine loop that keeps them engaged in their work. And it's really hard to fight that. So, you need to go with it. And I think what that means really if like cuz you can't just say no, right? Like they're going to build stuff, but you can say if you want to build MCP servers and all that stuff, please standard IO, that is like the easiest way for you to get something on your box that you can play around with that is minimally harmful to the rest of the organization. And that's really what our jobs are, right? We are in the business of risk minimization, not risk elimination

because that's impossible. The only risk-free computer was not built. So I think I think it's a complicated question, but I think just sort of doing the mile high like having them understand the risk and understand that like it's an immature technology and immature technologies are wildly attacker biased until we really get our feet under ourselves for the defensive posture. And also I would really just harp on the ooth or no and being like do you really really want to do ooth? Really? You want you want to do OOTH? Do you think you can do it right the first time? You you sure? Yeah. Anyway, any other questions? Burning questions. Any questions? Yes. >> Are there alternatives to MCP?

>> Uh, the question was, are there alternatives to MCP and is it like a no alternatives problem or an engineering problem? I don't actually know that the spec itself is bad or the problem or necessarily even that building MCP servers is the problem. I think the problem is velocity and the space is so biased towards just absolutely insane velocity especially in the LLM space where if you're a day behind you're basically out of the race that people are cutting every corner they can to stay competitive and I get that because in the current environment staying competitive, especially in a market where venture capital is expensive and it's like product market fit or die. You got to go

fast. You got to go as fast as you possibly can. And so our job is to make sure that engineers can go as fast as they possibly can, as safely as they can. And that's not necessarily saying don't It's saying you need to think about these things because these are sort of the table stakes attacks that everyone knows about. Does that answer your question? >> Yeah. DevOps developer experience problem. >> Yeah. Like it's a >> self-service. >> Yeah. It's some of it is self-service and shadow IT and stuff like that. And that that's a that's a whole another conversation. Like the number of times that I have had to complain about subdomain takeovers because people did

the wrong order of operations from decommissioning a service is too damn high. And I I am still like we have an internal notion page that is literally like step zero pull your subdomain record. I don't care. Like the first thing you do is you pull your service off the internet. Then you decommission it. Step one, step zero, step zero, step zero. Pull the DNS record, pull any internet facing records for the thing, then take it apart. And there's just like and I don't know that we have a good like paved path for building MCP yet other than like standard IO is the way. like build a standard IO thing cuz you're building a tech because one of

the things that I think really causes these sorts of problems is it's not MCP is it's a deputy that's attached to a high value service. So what you're actually looking for is a deputy attached to a highv value service. If that's not the case in your org, you don't actually need to care about this all that much. Like if if the MCP server is like an totally unsecured HTTP MCP thing, but like all it does is read your public facing docs. I I don't care like that that that's already on the internet. We can't um we're at 51. So I think we're So like it again, it's under it's a risk calculation. So what I would do is like

use this kind of as a triage point I guess and go through like okay and again this is really lean on the like engineering lessons of the past 60 years because engineering has been learning this stuff constantly for 60 years like do the blameless retro be like I'm not mad at you what did you build and then just go through that and go what does it touch and if you get through that and you're like Okay, public public internal public public restricted private. I want to look at the private thing and then the restricted thing and then the internal thing and I probably don't care about the rest.