AI Agents in Sandboxes
Limiting agent blast radius while vibe coding and in applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🦊 New Blog — Security and AI Research: https://teriradichel.substack.com/
⚙️ Security Automation (Pre-AI). The Code.
⚙️ AI Automation. The Code.
🔒 Related Stories: Cybersecurity | Penetration Tests
💻 Free Content on Jobs | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my last post I wrote about how someone who is a complete newbie to AI and not that technical could start writing software…but also demonstrating how having software development expertise can help improve the results.
One of the things I mentioned you should be wary of is letting an agent have complete network and file system access to all the things. In this post I’ll give a high level overview of how I’m solving the problem of unrestricted agents.
After about two minutes of using Amazon Q CLI (now Kiro CLI) I was like NOPE. You’re not getting all that access. NO WAY.
Why? Prompt injection, for one thing:
And in general AI agents taking actions I don’t expect or didn’t mean to authorize. Agents are very “creative” at finding ways to fulfill your tasks and solve problems in ways that are not exactly ideal.
And by the way this is why I’m using the CLI not the IDE at the moment:
A specific Linux user with limited permissions
I started off by trying to figure out how I could use a specific Linux user to run Q which only had permission to work in a specific project directory and could only access certain files and take certain actions.
That’s the solution in a nutshell…but…
Software architecture problems
The next problem I had trying to use Amazon Q was that it was changing code I didn’t want it to change. I would build a complex architecture and it would start rewriting parts of the architecture I didn’t want it touch when I asked or a change. No don’t change that change this.
Test problems
Similar to architecture problems when I tried to run tests and have Q automatically fix the problems, it would change the TEST instead of fixing the CODE with the problem! Creative and all but…not exactly what I had in mind.
Prompt harder doesn’t work
Prompting harder to try to tell Q to do this and not do that (well I think it’s Claude actually but you know what I mean) did not seem to solve the problem. Sometimes Q reads some parts of the prompt but not others.
Context rules don’t work
I tried creating context and rules to get Q to follow them across multiple projects. Nope. Sometimes I could get it to work but reiterating the rules or getting Q to print out the rules and check off each one as it goes. I’m still struggling with these things but regardless if I could get that to work, it was not concrete enough for my security needs.
And when you weren’t looking…
It’s easy to miss something while vibe coding (at least for me) because I want to go fast and I started using multiple agents at once. More on that later. And though I was trying to watch each action I had Q completely delete some of my code multiple times. This led me to create a system to auto-backup my changes periodically with a “backer-upper” script so I can easily revert, along with frequent git commits — and PUSHES.
About git repos
And it is that this point where I will tell you I do NOT give Q access to submit to or access GitHub repositories (soon to become Code Commit repos now that that is back). I have had Q kindly “revert” my changes before I realized what it was doing wiping out a whole day of code. That’s when the backer-upper script came into play. Amazon Q has a way of creating checkpoints of some kind but I haven’t tried it, nor do I trust it if Q has any access to roll back to a particular checkpoint.
Smaller projects
It was at this point I started moving my code to smaller projects. In theory you should open a Q session in a folder and it should stay in that folder. But it doesn’t. It was easier though to realize when Q was asking to alter a project in another directory. But still not good enough.
Common tests in a separate repository
To fix issues with Q trying to change the test instead of fixing the offending code I started putting common tests in a separate repository. That caused Q to ask me before changing code in the other project and was easier to spot. But still not good enough.
Custom CLI agents
I figured out that you could create custom agents in Q. Cool. Each agent has it’s own context and can have global or agent-specific context and rules. There’s a configuration file where you can define which tools are trusted and available to the agent. You can define a local context file and a few other configuration options — but none of that seems to work consistently. It feels like perhaps a “suggestion” rather than a rule. Not good enough.
An agent framework
Next I tried to create an agent framework to lock down agents using Linux permissions. The problem was I started in my home directory but that was a complete mess. I ended up locking my user out while trying to lock down agents. But I created scripts that I could use to build, test, install, and run rust projects in different folders where I would start project specific agents to modify code in that directory roughly locked down to the correct directories via a Linux user for that project.
I ended up moving the projects to a shared directory and set it up so the agents could all execute the shared tests (build, test, install, run) and view all the code in all the projects but not change it. But each agent could modify the code in it’s own directory, install a test version of the project I was working on in a directory specific to that project, write logs specific to that project, and so on.
Get Teri Radichel’s stories in your inbox
Join Medium for free to get updates from this writer.
I also wrote scripts that can initialize a new project, start an agent, stop an agent, or stop all agents. Initializing a new project includes:
- Creating the project directory
- Creating an agent and project-specific Linux user
- Creating a GitHub repo (soon to be CodeCommit in a private network with MFA for EACH code commit which you can’t do anywhere else as far as I can tell)
- Creating a new rust project
- Creating initial tests and test configuration
- Configuring the AI agent with an agent-specific context file
- Pushing a common context file to the agent
- Checking in the initial code
- Setting up all the permissions correctly
- Running test and verify they work
I’m probably forgetting something but that’s the gist of it.
I have a script to start using an agent. When I run it lists all my projects and I choose the one I want to work on. When I start it up it shows which agent I’m using with Amazon Q CLI.
Now when my agent tries to go off and change code in some other project or a project that is designated to run tests the agent can’t touch that code. Once it figures out it doesn’t have permission to change that other code it generally reverts to changing it’s own code without me even telling it to do that.
Limited blast radius
Now with all of that I can quickly create a new projects configured to run tests the way I want with a new agent and the blast radius for each project and agent is limited to a specific directory and a limited set of code. Cool.
Can’t update…
Now along comes new versions of Q and Kiro and I can’t update the code. Why? Because it only will update if you are updating the installation in your own home directory. I got a bit stuck at that point and now I’m just considering if I should update or finish what I’m doing first, because I heard Kiro CLI is basically the same, just rebranded. I will update eventually because I’m sure it will improve but I was trying to finish something. Hmm.
Backwards compatible but…
I looked through the documentation and it should be mostly backwards compatible to what I have and you can even still use the old commands apparently. Essentially I want to rewrite a bunch of scripts to use the Kiro constructs like a steering doc instead of a rules file. (Isn’t rules much clearer? Someone talked to me about a steering doc and I was like a what?)
Wasted time and energy…
Now q-start.sh so clean and simple becomes kiro-start.sh and so on if I want to bother to rename everything. Too bad Q got off to a rough start and someone thought rebranding would help. I wish it was still Q to be honest. People will figure out that it got better. I made this same argument when someone wanted to rename another service. Really not necessary. Just fix what you have and call it new and improved. Now it’s just confusing and I have to spend time on nonsense that slows me down from actually writing useful code. But that’s all a tangent.
It was actually not that hard to get Kiro installed and “working.” The problem is that it bugs me that all my scripts are still using q commands and have q names but I’ll fix that later.
Not super scalable
This agent framework works for me but it’s not super scalable. Anyone using what I have right now could easily change the scripts and files and mess it all up. You have to be security conscious, aware, and use the correct scripts to keep each agent in it’s own little sandbox. You need to trust the developers using it to do the right thing — if they understand what the right thing is and why they are doing it.
I have some ideas to get around that problem but I’m just building tools for myself to use on pentests for the moment, not a commercial product, so this is good enough for me. Someone might be able to take these ideas a bit further — and in fact if you are using autonomous agents in applications, Amazon has basically created something like the above with Bedrock Agent Core. Each agent is locked down so it can’t access another agent’s session and so on.
Other problems to solve
Now solving the security issue was just one of the problems I had to solve on the road to production code. Locking down the agent and limiting what a rogue agent or code injected into a resource it’s reading, the model, or some copy and pasted prompt is one thing. Getting production ready code that works is another.
Moving the code to separate project and locking it down was a major leap forward because I can now more easily maintain architectural constructs like traits and factories used to implement common code in a consistent way. However, I’m still having issues getting Q to follow my instructions precisely and not have my context window fill up and then I lose all the detailed context I’ve been working on when it “summarizes” everything and loses important details in the process.
Supposedly this was doing to be resolved at re:Invent somehow but I haven’t really seen what solves my specific problems. I already use tests (which basically work like Cedar sidecars in the AI keynote), small focused projects, and specifically formatted requirements in my context.
The only thing I saw was a visual to view what Q is going to build before it builds it via a design diagram. That looks somewhat useful but seems like you’d only get that in the IDE version of Kiro. And…I’ve kind of already solved that by breaking my projects down into separate components per project. I ask Q to print out the list of steps it is going to take and check off each one. The problem is when context fills up and I lose my carefully honed list of steps that I finally got the model to abide by. A diagram doesn’t really solve the problem of not following steps in order as far as I can tell.
But:
- I need to upgrade to Kiro and try out autonomous agents and other AWS features announced at re:Invent to see if an how they resolve issues I’ve been having. Likely I’ve missed something or I’m doing something wrong.
- I have some other ideas that might help which I got from another AWS hero while at re:Invent, so I’m going to check that out and see if it works.
Update: I already updated to Kiro and tried my commands again and still have the same problem with steps being executed out of order. I’ll have to try my other ideas to see if I can fix that problem another way.
Update 2: My attempt at using new ideas after AWS re:invent is proving to be very promising. Completed 50% of about 230 reuqirements in two days (with some glitches in between) and stymied by human illness so I’m still testing and researching those ideas.
See next post for more about monitoring the agents.
Stay tuned….
Follow for updates
Teri Radichel | © 2nd Sight Lab 2025
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero Former SANS, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests & Security Research ~ 2nd Sight LabCloud, SAAS, and Application Penetration Testing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration testFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ X, Threads, Blusky, Instagram, AWS BuilderID: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
