You can create an impenetrable prison for the LLM agents if you are willing to employ old school tech like Postgres, MSSQL or Oracle to solve the problem. I can't think of a better sandbox. No other ecosystem is as complete. Using virtual machines & containers is way too much, IMO. If you want to give the agent arbitrary code execution, allowing it to write [T/PL/pg]SQL over explicitly granted schema objects seems to be a more secure approach than running arbitrary python or C# scripts on a VM somewhere.

If you are in a highly regulated environment, I would double down on this advice many times over. Features like row level security + connection context can be used to isolate on a tenant basis (per user's conversation thread) in a way that an auditor would be properly satisfied with. They already have checkboxes on their forms for this technology. Building a custom sandbox ecosystem from scratch is a long, twisted road. There are existing technologies that ~perfectly solve this problem, assuming you have the patience to frame it appropriately.

Think about this from the perspective of the user principals you would create. A built-in SQL account with locked down schema access is constrained in so many more dimensions than an AAD account with access to sandbox/container VMs. With a SQL account, you can exhaustively enumerate all of the things the model could hypothetically touch in one sitting. Privilege escalation is a possibility in the RDBMS environments, but mostly in the same sense that time travel or fusion power is a possibility in real life (i.e., so unlikely we can probably ignore the concern).

I've been doing this for a few months now and it is very obviously the correct path. YC put out a video about this concept too. The only way the agent in my architecture gets to talk to the outside world is by way of a table called RemoteProcedureCalls that a totally separate service polls & responds to over time.

https://www.youtube.com/watch?v=B246K_G7mHU [5:07 -> 9:14]