I am designing a system where agents can execute code based on user inputs, and I am terrified about security. What are the best practices for sandboxing these agents? I do not want an agent accidentally deleting my production database because of a prompt injection. Are there established patterns for giving agents limited, read-only permissions? I feel like the ecosystem is still very much in the Wild West phase when it comes to security.
Autonomous agents should be secured by implementing a mandatory gatekeeper pattern that requires independent validation of all commands, preventing direct execution of destructive operations on production databases.
7 answers
The ecosystem is definitely chaotic, but your primary mistake is letting agents talk to the database at all. Never give an agent write access to production, period. Use a gatekeeper pattern where the agent generates a query or request that must be signed off by a secondary system before execution. If your agents are executing arbitrary code, they are already a security liability that no amount of sandboxing will fully fix. Keep them isolated and keep them read-only.
You should immediately shift away from agent-side access control toward a policy-based architecture enforced at the database driver level. By implementing row-level security and strict IAM roles specific to the agent's identity, you eliminate the risk of accidental data deletion even if the prompt injection succeeds.
I recall a project where we handed an agent direct SQL access for real-time telemetry updates, only to watch it inadvertently drop an entire partition during a noisy input error. It was a sobering reminder that LLMs possess no inherent concept of consequence, treating a destructive command with the same neutral probability as a simple read request.
We ultimately rebuilt the entire interface using a middleware layer that strictly validates every intent against a predefined schema. Never trust the agent to negotiate permissions on the fly because the attack surface is just too wide for a single security policy.
To secure your agents while maintaining functional capability, you should implement the following isolation strategies:
- Use ephemeral containers with no network ingress for code execution.
- Enforce strictly read-only database connections via temporary IAM tokens.
- Employ an intermediate human-in-the-loop review for all mutation operations.
- Strip the execution environment of all elevated shell privileges before initialization.
Operating in this space requires choosing between network-level isolation and API-layer guardrails. Network isolation works well for static environments where you can air-gap the execution sandbox, but it often hinders the agility required for modern agentic workflows. In contrast, API-layer guardrails are better suited for dynamic systems because they allow granular control over data access, yet they rely heavily on the integrity of the authorization logic itself.
The vulnerability you are describing stems from the conflation of execution context and data authority. When an agent is permitted to run arbitrary code, the security of your production environment is effectively reduced to the security of that specific execution environment. You must decouple these components to ensure the system remains resilient against prompt injection or malicious code injection.
First, you need to transition to a sandbox that leverages kernel-level isolation, such as gVisor or Firecracker microVMs. Standard containerization is insufficient here, as a successful breakout from a standard Docker environment typically grants root-level access to the host. Second, implement an abstraction layer for your database interactions. Instead of allowing the agent to issue raw SQL commands, provide a hardened set of tools—a restricted toolset—that exposes only specific, limited functions. This prevents the agent from performing operations outside of its defined scope, such as dropping tables or accessing unauthorized schemas.
Finally, your authentication strategy should rely on short-lived, scoped tokens that expire the moment the task completes. By treating the agent as an untrusted user and wrapping its inputs through a semantic validation layer, you force the agent to comply with business logic rather than raw execution capabilities. This layered approach creates a defense-in-depth posture that is essential for critical systems where data integrity is not optional. Relying on simple prompt engineering is a recipe for failure when the system is exposed to adversarial inputs designed to bypass context windows.
Are you seriously letting agents interact with your production database? You need to move your database connections to a read-only proxy layer that sits between the agent and your data. Create a set of narrow APIs that satisfy the agent's needs without giving it the ability to execute general-purpose SQL. Anything else is just asking for a production outage caused by a hallucinated command.
