Transcript
one. In this video, I'm going to make it clear how to get those all set up properly with security flavored examples, but you can use this as a reference for any other needs you may have in your project. By the way, if you aren't already familiar with these terms, I encourage you to watch our previous video to get caught up and then come back to this one. That all said and done, let's jump into the first one MCPs. We're jumping into MCPs first because it's going to act as the foundation for the rest of the extension points, rules, hooks, MCPs for the rest of the demos I'm going to show you throughout the rest of this video. Now to get started with MCPs, you're likely already familiar with this. It's the one that's been around the longest, but I'm going to tailor all this to cloud code. Just know that you can apply this to other AI ecosystems like open AI codecs or cursor or Gemini and antigravity, whatever your tooling suite that you're working with, you can apply these in a similar fashion. Now when it comes to adding MCPs to cloud, you have a few different avenues you can go with. I personally like to go with the local scope option, which is scoped to the current project that I'm working with. That way it limits the number of MCPs that are being leveraged and used and added into the context. And I can have it focus on things for the purpose of the task at hand in that situation. But you can also do it at a project level. You can do it at a user scope level, whichever suits your needs. All right, jumping over to our example project, I'm going to set up an MCP server in this project for us. So in here, I need to create a dot cloud folder. From there, I have the option to create a settings dot JSON file or a settings dot local dot JSON file. Now the idea between these two is the settings dot JSON is one that's more project specific that you can share and check into source control to share with the rest of your team. And then settings dot local dot JSON is just specific for you as an individual scoped to the project as well. So if you're experimenting with some other MCPs that the team's not using yet and you want to see how it works, that's a great way to get started there. But if you want to share it and have everyone use it when they pull in the project, you can put it in your settings dot JSON file. All right, now from here, we need to create a JSON object, the curly braces, and then we're going to add in a MCP servers key along with some objects for it. I'm pasting this in as an example. So we have MCP servers, I'm calling my one MCP server, I want to add sneak, which is the security tool I want to use telling it the type is standard input output, the command to run it, which is NPX, and then the arguments that I want to pass into it to get it started. And if I had any environment variables, I can pass those in as well. So that's one example of setting up an MCP server, each one that you might be wanting to use and apply might have different types and commands and arguments. So keep that in mind, look at that tools documentation to find out the correct setup that you need for your purposes. So being that I'm using Visual Studio code for this, I can actually leverage the extension marketplace there and use the sneak extension, which has the ability to set up and enable the MCP server for me via its settings. So you install the extension, searching for sneak in the VS code marketplace. And then you go into settings, search for sneak secure at inception, you click on configure MCP server, make sure that's checked. And then the other option that you have here is you can tell it to do security scans whenever there's code generated by AI. Or if you want, you can do a smart scan. And that's another way to set up the sneak MCP server as an example. Now that the MCP server is set up and configured, let's make sure that cloud code can access it and verify that it's been set up properly. So one gotcha or caveat to call out here, when you're trying to leverage MCP servers, via the cloud code extension inside of Visual Studio code, it's not as accessible to all those resources like you would from the CLI or clouds desktop application. And when you look at the documentation on anthropic website, VS code extension versus cloud code CLI, you can see the features differ of what's available in the VS code extension version and the CLI version. So for commands and skills, you can access all of them from the CLI, but only a subset of them from the VS code extension for some reason. And then MCP server configurations, you can get them all from the CLI, but only partially from the VS code extension. For some reason, you have to add servers via the CLI and manage existing servers with MCP in the chat panel. So keep that in mind, if you prefer going through Visual Studio code to access cloud code in the extension way, that way, you're going to run into some gotchas or hiccups like this. That said, I'm going to switch over from VS code into the CLI, the built in terminal there so that we can continue forward. Alright, so back to verifying that the MCP server is set up properly, I'm going to load up Claude in my terminal here. And I'm going to run this slash MCP command to see and manage MCP servers. Alright, so looking at the configuration for the sneak MCP server via Claude CLI, we can see that it is connected, it's running through MPX, what arguments are being used, and the config location, there is the project level one, and then my broader user level one as well. And then there's 12 tools set up there, we can reconnect, we can disable that MCP server, we can view the tools, we can see what's available from it, all to make sure that we have the MCP server set up properly. And I can even view some more details about each tool that comes with this MCP server. With the MCP server set up and verified it's working, we do need to authenticate. So we're going to trigger using the MCP server via Claude. And you can see I'll load the sneak auth tool schema and assign you in, it's going to prompt me to make sure that I want to allow that to happen. I'm going to choose Yes. And there we go, we can see I am already authenticated with sneak as myself using the API dot sneak.io. We're good to go. And we can start using it and even gives us an example prompt we can provide to Claude, run a sneak scan on this project if we want. So let's do that. And it's going to ask me for permission to use these other tools that I haven't yet used from the MCP server. And I'm going to say yes, for that, those two tools there. All right. And just like that, within a few seconds, really, we can see there were seven issues found, there's one high severity issue in my server js file. And then a few other ones, medium severity in some other files within the project. When it comes to dependencies, the folder needs to be trusted before sneak can do that. So let's do that as well. Because I want to check the dependencies that I have in this project. Okay, once I trusted that folder, I'm going to tell it to run the open source dependency scan again. Alright, and now with scanning our dependencies, we can see there's a vulnerability via my low dash dependency. And I can fix it by upgrading to 4.18.1, that version of it. But we can see there's seven high severity vulnerabilities due to this dependency that I have here. And then I can go on further and tell Claude to go ahead and upgrade low dash to that version if we want. But we're going to keep it like this for now for demonstration purposes for the other AI extension points with the MCP server setup, verified it's running, and we've actually demonstrated using it, we had to do all that manually, wouldn't it be nice if we talked to the model in natural language about checking the security of the project as a whole, and it automatically knew to leverage sneak for that purpose? Well, we can. And one of the first ways we're going to enable that to be possible is using a rules file back in our project. And since we're focusing on the Claude code approach to things here, we can now set up a rules file, which in the Claude ecosystem is just a Claude.md file. So within the dot Claude folder, I'm going to create a new file, call it Claude in all caps, dot md. And now I can paste in my rules. Now these are pre existing rules that I had created, you can actually leverage Claude code to help you come up with a rules file for you, if you'd like, which is where some of this stems from, actually. So it describes what the project is about, what the repo contains the commands that are available to run it, audit it, and that sort of thing. And the architecture of the project. But here is where I added a little bit to the rules from line 36 down is where I wanted project security best practices. And I tell it always run the sneak code scan tool, which is one of the tools that's part of that sneak MCP server. And that's for any first party new first party code that is generated, okay, in a sneak supported language, of course, if there are any security issues found in newly introduced or modified code or dependencies attempt to fix the issues using the results from sneak as well. And then always rescan after fixing things repeat this process until new issues until no new issues are found, actually. So there you have it, I added four rules to my cloud.md file so that any model I'm using within cloud code will get that information and know to leverage the sneak MCP server and the sneak capabilities for security scanning purposes. Alright, so starting a new session with cloud code CLI, I'm going to say please check for security issues. Alright, we can see that it picked up that it wants to run a sneak code scan on the project. And that happened automatically without me explicitly telling it to use sneak. It recognized that for security issues, based on the rules in cloud.md, it should leverage the sneak MCP server. And then it prompts me for permission to use the tools that are related to the MCP server. So that's rules in a nutshell. In the past video, we talked about how rules are not exactly rules, they're more guidelines, the code is more what you call guidelines than actual rules, because something like 90% of the time, the AI model will follow those rules. But as things get more complicated, or it finds easier paths forward, it's just going to ignore those rules or forget about them. To show you an example of that, when I tried to give the same prompt to cloud code in the VS code extension version of cloud code, I'm going to show you exactly what happened there. So similar to what I did in the CLI for cloud code, I asked please check for security issues, it thought for 170 seconds, and it says the user wants me to check for security issues. The cloud.md mentions using the sneak code scan tool. So it read the rule, but then decides, let me invoke the security review skill, which is something that's built into cloud code as a another skill that you can leverage. So that goes to show you that even though rules are called rules, they're actually just guidelines. And there isn't a guarantee that the model will follow those rules every single time, or exactly how you expect them to. So hold that thought, we'll come back to this when we talk about hooks. So at this point, we've set up an MCP server, and we've set up rules or cloud.md file. Next up, let's take a look at skills, we want the skill to provide a workflow to the model that's proper for finding and fixing vulnerabilities in our projects. So we want it to first discover what vulnerabilities are found in the project, look at what are the remediation options it can take, check those remediation options to see if they are breaking changes are going to have some type of negative effect on the outcome of the project, and make proper decisions on how it addresses the vulnerabilities moving forward. Then once it feels it's addressed those vulnerabilities, verify that and then maybe create a PR. And that can be the overall workflow that we want. And that is a perfect case and scenario or a skill. So let's set that up now. Very similar to the other options that we've set up for an MCP server or the rules file, we can add skills scope to our project within the dot cloud folder there. So I'm going to add a new folder subdirectory inside of there called skills. And then I'm going to give it another folder underneath that with the name of the skill that I want. So it's going to be sneak fix. Now within this folder, I can have a skill.md file, which is the main entry point and then any other supporting file contents documentation, other scripts that can be leveraged as part of that skill can all fall within the skills folder. So let's start off with our skill.md file, all caps skill.md. And then I'm going to paste in the contents for that. All right, let's step through this. As I mentioned in the past video, we have the front matter first and then the body of the skill. The front matter here describes the name of it, sneak fix, and a description. The description is important here because this will help the model know whether the skill will be relevant for the test that it's working on. And it will key off of the words found within the description of the skill. Then we describe what tools it's allowed to leverage as part of this skill, which is another reason why we set up the MCP server first for the purposes of these demonstrations, the license of this compatibility, and some metadata on it. So that is all the front matter wrapped within these three hyphens from the start. And at the end here. After that, we get into the body of the skill, which describes the overall workflow we want to do here, we want to complete security remediation flow, we're going to parse, scan, analyze, fix, validate, summary, and then optionally, we will add a PR. And this goes into great detail here of that whole workflow. What's nice about this and taking this approach is the skill name and description are the only thing that's going to be loaded into the context for any new chat session I have within the cloud code. With that in place, let's start a new session with Claude and see if the sneak fix skill is available to us. So I'm going to do slash sneak fix. And now we can see that option there. And I could just do that maybe give it a little bit more details. Please address security issues. I can give it that type of prompt. Or I could just without even calling out the skill, it should pick up on that skill being available to it and related to the purpose of the prompt here and leverage all those details throughout the process. So let's kick it off and see what happens without calling the skill directly. And look at that right off the bat. It says use skill sneak fix Claude may use instructions, code or files from the skill Do you want to proceed and choose Yes. And now it will go through and follow that workflow from that skill to leverage the sneak MCP server and find and fix vulnerabilities for us in this project. As you can see, it's triggering that one sneak tool to scan for the open source dependencies and see if there's any vulnerabilities there and then the sneak code scan for any of the code that's found within the project here. And that's an example of setting up an AI skill and leveraging that in an agentic way. At this point, we have now set up an MCP server, we've set up rules in our cloud that MD file, and we set up a skill or using sneak to find and fix vulnerabilities in the project, leveraging all that together. The next thing that we need to put in place is hooks. Hooks are a guaranteed deterministic way of executing certain actions that you want to happen every single time. As I mentioned in the past video, if a rule needs to happen every single time and be guaranteed, it must be a hook. So in this case, I don't want any AI agent introducing and committing security issues in my open source dependencies of my project or the code that it's editing or adding into the project. So how do I guarantee that I set up a hook that's going to leverage sneak before it commits anything to my project? Let's go do that now. In order to set up hook scope to this project, I'm going to open up my settings JSON file within the cloud folder. And I'm going to add a new keyword here, I'm going to paste it in hooks. So what I pasted in is two different hooks for the purposes that I'm looking to achieve here. One is a pre tool use, and one is a post tool use. For the pre tool use, I want it to match on any bash actions that the agentic coding tool is trying to do within that type of scope. And before it goes ahead and uses or run some bash command, I want it to actually run this command, which is local to my project here. And you can see I'm referencing dot cloud hooks, sneak pre commit gate.sh. So I wrote a shell script that we need to now add so that this can actually work as expected. So we're going to create a new folder in here, we're going to call it hooks. And I'm going to create a new file in here and call it sneak underscore pre commit underscore gate.sh. So I'm going to paste in my shell script here. And this is actually something that I pulled directly from sneak. That is part of sneak studio recipes, which I'm going to talk more about at the end of this video as a really helpful resource to set all this stuff up for you so you don't have to manually do it if you're interested in using a security tool like this. So I'm not going to go line by line through the specifics of this, you can go check it out when I share the repo at the end of the video here. So now we have a script in place that can check to see if a commit is about to be executed and run some actions before we allow that to go through when it comes to the post tool use hook that I have set up here. I'm matching on anytime a file is had modifications to it, which is what the edit keyword is there. Or if a new file is written, or we write to a new file, we being the agent decoding tool here. And if that happens, the hook we want to run is a command. And it's going to be this other shell script, which is the sneak SAI or secure at inception scan, I'm going to create a new file for that in the hooks folder, sneak underscore SAI, and sh and very similarly here, I pulled this from our studio recipes repository for demonstration purposes. So with both those in place, now I have a guaranteed deterministic way that security checks will happen either before the model tries to make a commit to my branch in my project here, or during code changes that are happening. So with that in place, let's test it out. I'm going to open up a new session with Claude. And I'm going to ask you to add a feature to this project. And an API endpoint that takes us date format and converts it to British date format because I'm using low dash here in this project. And it is intentionally vulnerable version of low dash. So let's see what happens when it tries to work on this. Alright, a couple things to call out here when it was making the file changes, we can see that there were two post tool use hooks that ran here, you can assume one of them is going to be the one that we set up. And then once it was done making, you know, several file changes, we can see that happened multiple times. But after that was done, it then said, okay, let me run the sneak code scan as required by the project security rules. So it's reading the rules file for us there. So having all of these extension points layered together for that single purpose, in this case around security, it's been working out the way we would expect it to be and we have more confidence in the results that this agentic tool is going to produce for us now, once it's done with all the changes that needed to do for that prompt, we can see that it calls out sneak found seven issues, but all are pre existing, none are in the code that it just added. So it's going to verify by cross referencing each finding against new files. And it did all that gave us a summary of everything that happened. Alright, with those changes made, let's attempt to have cloud code commit the changes to the branch. And with that, we can see that when cloud code attempted to run the Git commit command, it did trigger our pre commit hook, and sneak found security vulnerabilities. So the commit was blocked by the pre commit gate, which is fantastic to see that and that our hooks are indeed working as expected. And just like that, we have set up an MCP server, some rules, cloud rules in a cloud MD file, some skills to go with it like sneak fix, and some hooks that can help ensure that things happen in a deterministic way for all the things that absolutely must happen, like a security scan. Now I promised you at the end of this video, I'd share a resource that will help set up this security stuff that you saw in this video, pretty much automatically for you without having to manually add everything. And that is where sneaks studio recipes repository up on GitHub is your greatest resource, you can check it out here, link will be in the description below. And it goes through details on how to set up and install all that stuff with one quick command from this repository. Again, that was all specific to that security scenario. But if you have other scenarios and other tasks that you want to put in place around your projects, you can take what you saw here as a reference and apply it to those scenarios. On that note, that does it for this video. If you got value out of it, be sure to like it down below and share with somebody who could put it to use. And if you made it this far, subscribe to the channel so you don't miss out on upcoming videos. Thanks for watching and happy safe coding everyone. Transcribed by https://otter.ai
