In the previous lesson we set up Cloud Code's native sandbox, which gave us protection against file modifications outside of our current working directory and protected us against an authorized network access, enforced by the operating system itself. And that gets us most of the way there, but if you've been running relfloops inside the sandbox, you probably noticed that you're still getting permissioned denials for certain things. Let's say we added an mcp server to our project,

getting permissioned denials for certain things. Let's say we added an mcp server to our project, in this case, the chrome dev tools, and let's ask Cloud to use the chrome dev tools mcp and navigate to laracars.com. You might expect this to just work, since we set up the sandbox with auto-allow in the previous lesson, and we allow laracars.com on a network level , but look, we're still getting a permission prompt. This is because the sandbox only auto allows the bash tool.

we're still getting a permission prompt. This is because the sandbox only auto allows the bash tool. mcp tools are a completely different category. They're not bash commands, they 're not child processors, they don't even run in the sandbox at all. So as we can see on screen, the navigation request goes straight to the regular permission flow, and this would simply fail in print mode. We could add our mcp tool to the allow list by saying mcp_chrome-wildcard. And while this would work, what if you only want to deny visiting certain pages

We could add our mcp tool to the allow list by saying mcp_chrome-wildcard. And while this would work, what if you only want to deny visiting certain pages ? This is where the permission settings will start to break down, but luckily we can extend the permissions with hooks. There are a bunch of hooks we can plug into, but we are most interested in the pre-tool use hook. This is going to be an array, we can add an object here, and let's start by defining our matcher, let's scroll up and take the mcp_chrome out of the allow list and

start by defining our matcher, let's scroll up and take the mcp_chrome out of the allow list and put it in our hook. Next, we need to define our hooks, which is again going to be an array, we'll add an object, it's going to be of type command, and I prepared the pre-dev tools hook for us. And this hook is actually a pretty simple script, we will just check if you are going to do a request to laracars.com, and we'll block that, and we'll instruct the model to go to laracars.test

request to laracars.com, and we'll block that, and we'll instruct the model to go to laracars.test instead. The way we instruct the model is pretty simple, we have to output this specific JSON, we have to say hook specific output, and because we use pre-tool use, we can say permission decision deny or allow, and we say permission decision reason, and this will be fed to the model, so we can say no fetching laracars.com, you may fetch laracars.test. If we won't find laracars.com in the

can say no fetching laracars.com, you may fetch laracars.test. If we won't find laracars.com in the input, we will just allow it. This hook script looks a bit verbose, because I also added logging, so we can trace back what actually went through this hook, and whether or not we allowed the permission request. Right, so we defined our hook, we say pre-tool use, we will match all mcp- chrome requests, and the hook that we will execute is a command, and the command we will execute

chrome requests, and the hook that we will execute is a command, and the command we will execute lives in this directory, and I actually have to remove this slash if I'm not mistaken, and now when we run our prompt again, it should be denied. And as you can see here, chrome opened on laracars.test, and chrome opened here, because the request to laracars.com got denied, we say no fetching laracars.com, you may fetch laracars.test, and because the model can interpret this, it's

no fetching laracars.com, you may fetch laracars.test, and because the model can interpret this, it's going to be smart enough to say we don't go to laracars.com, we have to go to laracars.test, and then do the navigation to laracars.test instead. If you open up our pre-dev tools.log, we can see the request came in with this tool call, we want to navigate to laracars.com, and we say blocked, because laracars.com got detected the second time, we go to laracars.test, it's allowed, and hooks are a

because laracars.com got detected the second time, we go to laracars.test, it's allowed, and hooks are a pretty powerful extension to permissions, because they're just scripts. You could even make this a note or a PHP script and evaluate that you could have an API call in there to check whether or not we'll allow the tool use, or we could do something crazy and evaluate the incoming request with cloud itself, and have it accept or deny the request. There's a building way to

request with cloud itself, and have it accept or deny the request. There's a building way to achieve this, we can say instead of type command, we can say type prompt, and then we can say prompt, and then we have to add or prompt in line allow or deny the incoming requests l aracars.com is not allowed laracars.test is, and now we have to paste arguments in here, and essentially this arguments variable is just going to be replaced with this JSON object we saw in

essentially this arguments variable is just going to be replaced with this JSON object we saw in our logs before, and I actually kind of dislike doing it this way, because as you can see, it's kind of hard to manage the prompt. So instead, what I like to do is to keep the type as command, let's revert this to command, and we can say clot -p, and we will get clot hooks breed after use dot md, and this is actually a simple prompt you're a pre tool use hook for cloud code, you will

md, and this is actually a simple prompt you're a pre tool use hook for cloud code, you will have some allow and deny rules will deny when it's going to go to laracars.com will allow when it's lara cars.test, and we'll allow all other requests to deny we have to do the hook specific output to allow it to do this, and before outputting we want to have our logs as well. Let me clear out the logs and run our prompt again, and now when we run this prompt again, cloud will spin up

logs and run our prompt again, and now when we run this prompt again, cloud will spin up a cloud instance in print mode, when there's a permission request that matches the pattern, so when we use the chrome dev tools mcp, and this separate cloud instance will allow or deny the permission by outputting the correct JSON string. And as you can see here, no fetching laracars.com, you may fetch laracars.test, and this one should hopefully be allowed. And there we go, laracars.test got

may fetch laracars.test, and this one should hopefully be allowed. And there we go, laracars.test got loaded in the dev tools mcp. This is pretty neat. And if you take a look at a pre dev tools.lock, we can see it got denied because laracars.com got matched, and the second one got allowed because laracars.test got matched. And we can actually push this quite far. Instead of only matching the mcp, let's say we want to match every command that has a permission request, and I

the mcp, let's say we want to match every command that has a permission request, and I included a generic tool reviewer prompt we can use as a general security advisor. So we can say pre tool use, and if we quickly take a look at a prompt, we'll just instruct a model to inspect every tool call for security violations and deny anything dangerous. For example, we cannot SSH , we cannot deploy things, publish things, release things, we cannot do destructive table operations, we

, we cannot deploy things, publish things, release things, we cannot do destructive table operations, we can do destructive file or system operations, etc, etc. While this sounds great, the trade off here is that you're adding latency to every single tool call that is not in our allow list. On top of that, you're burning a lot of tokens because this cloud instance does not have access to the entire context, and this cloud instance will have to do a screening even for repeated tool

entire context, and this cloud instance will have to do a screening even for repeated tool calls we allowed before. But if you're running relfloops in attended, maybe overnight, this gives you a second pair of eyes that screen what's happening for you. This system is not perfect, but it's a decent alternative to dangerously skipping permissions, which we will talk about in the next lesson. I'll see you there.

about in the next lesson. I'll see you there.