(upbeat music) Up until now, we ran our LFLUPS with a default mode set to accept edits in the Project Settings.json configuration file. In the interactive CLI, we can toggle between these modes by pressing Shift + Tab. And all accept edits does is auto accept file edits without asking us for approval. And this is generally considered safe because we're probably tracking our code with Git,

And this is generally considered safe because we're probably tracking our code with Git, which means any change can be easily inspected, reverted or discarded. However, it's important to understand what the setting does not to accept edits only affects file modifications. It has zero impact on bash tool execution. So whenever Cloud wants to run a bash command, for example, installing dependencies, it will still ask for permission.

So whenever Cloud wants to run a bash command, for example, installing dependencies, it will still ask for permission. (upbeat music) If you want Cloud to run certain commands automatically, you need to explicitly grant that permission through the allow list as we can see here. Only the commands included in this allow list will run without prompting you for permission. And to set a model up for success in a previous lesson, I already added a few things in there like NPO install,

And to set a model up for success in a previous lesson, I already added a few things in there like NPO install, but I also denied destructive actions like RM or Git RM. In these allow and deny lists, we can use glob patterns. As you can see here, we can say wildcard-version. And this means that Cloud can run things like screen-version without asking us for permission. So this is pretty safe. And these wildcards can appear anywhere in the command. For example, here we say wildcards,

And these wildcards can appear anywhere in the command. For example, here we say wildcards, base, dash dash help, space, wildcard. And this will match commands like GH, dash dash help, PR. So this is also a pretty safe command to allow. Besides the position, the word boundary is also important for these commands. For example, if we say bash, ls wildcard, this will match things like ls dash LA, which is will not match things like ls off.

this will match things like ls dash LA, which is will not match things like ls off. If instead we say ls wildcard without a space, this will match things like ls off and even ls space dash LA. In the deny list, I usually also have things like read and I will disallow reading my environment file and let's add a wildcard in there. So none of the environment files are readable. An important thing to note is that the deny list

So none of the environment files are readable. An important thing to note is that the deny list always wins over the allow list. In Ralph Loops, the allow and the deny list is even more important because we're running imprint mode. There's no way for us to give permission interactively like in the shell. When a Ralph loop hits a permission request, the tool call will simply fail imprint mode, forcing the model to work around it.

the tool call will simply fail imprint mode, forcing the model to work around it. Let's quickly demonstrate this. We can say cloth, do a core request to larkas.com and show me the response headers. So if you do this interactively, this will ask us for permission. So there we go. This command requires approval. If in set we say cloth dash B,

This command requires approval. If in set we say cloth dash B, do a core request to larkas.com. It is unable to ask us for permission so it will fail by default. And as you can see here, it looks like the curl command is being blocked by the permission settings. This is technically not entirely correct. It's running imprint mode

This is technically not entirely correct. It's running imprint mode so the permissions will always fail. There are a few mechanisms to bypass the permission requests safely. And let's start with the native sandboxing. Cloth code has a native sandbox we can configure interactively by saying sandbox. By default, we are on no sandbox but let's say we want to have sandbox bash tool

By default, we are on no sandbox but let's say we want to have sandbox bash tool with auto allow. Then let's also go to overrides and I also like to enable the allow un-sandboxed fallback. And this means when a command fails due to sandbox restrictions, it'll just fall back to regular permissions. And by simply enabling this native sandbox feature, we will already be relieved of permission fatigue.

And by simply enabling this native sandbox feature, we will already be relieved of permission fatigue. By design, the bash tool in the sandbox is automatically allowed but modifications outside of the current working directory and network requests are disallowed at the OS level. The underlying sandboxing framework is called Apple Seed Belt on macOS and Bubble Wrap on Linux. On macOS Seed Belt will work out of the box

and Bubble Wrap on Linux. On macOS Seed Belt will work out of the box but Bubble Wrap needs to be installed first and you can refer to the docs for that. So even if Cloud tried to write to a directory outside of the current working directory, the OS simply will not allow it. This means Cloud can't modify critical configuration files like your bash RC and it definitely cannot remove your home directory.

like your bash RC and it definitely cannot remove your home directory. But on top of that, there are also network restrictions in place. So Cloud can go out to the internet and connect to every service out there. All outbound connections are disabled by default and this reduces your prompt injection risk and even your data exfiltration risk significantly. (upbeat music)

and even your data exfiltration risk significantly. (upbeat music) We can try and bait the model by saying something like do a core request to larkas.com and show me the response headers. And as we can see, this will fail because the sandbox blocks all outbound network connections at the OS level. No matter what tries to make the connection, in this case, curl.

No matter what tries to make the connection, in this case, curl. What we see here on screen is a sandbox fallback mechanism in place which we explicitly allowed. Because the curl command failed in the sandbox, Cloud breaks out of the sandbox and falls back to the permission flow and that's why it's asking us for permission. To prevent this from happening, we can add network configurations to the sandbox,

To prevent this from happening, we can add network configurations to the sandbox, open up our settings.json file and look for the sandbox entry and then we can add things like network. We can say allow domains and let's say larkas.com is an allowed domain. And this time when we run the prompt again, it'll work without permission requests as we can see here and we get to see all the response headers

it'll work without permission requests as we can see here and we get to see all the response headers which is pretty neat. By default, the sandbox allows reading from the entire file system but writing is scoped down to the current directory. We can modify the sandbox behavior by adding an entry in the configuration like this. We can say file system, let's say allow write and maybe we're working on an app.

We can say file system, let's say allow write and maybe we're working on an app. So we will allow fast lane. We can also say deny write and maybe we want to disallow the GitHub directory so the workflows are unchanged. We might want to also say deny read. For example, let's say our AWS credentials are off limit. Finally, we can also say excluded commands. For example, Docker,

Finally, we can also say excluded commands. For example, Docker, because Docker will not work in this native sandbox. And this way we can tailor the permissions to our needs and give Ralph a decent playing field while maintaining a great balance between freedom for the model and safety for us. A quick note, we actually don't need to modify or rel script in this lesson as long as we run it in the same directory

or rel script in this lesson as long as we run it in the same directory where it has access to our cloud directory. So I can read the settings.json file. Join me in the next lesson where we'll push the boundaries even further.