Every command an agent runs, whether shell scripts, Python code, or Node.js programs, executes inside a sandbox. The sandbox isolates each agent from the rest of your system by restricting filesystem access, network connections, and resource usage. Even if an agent runs untrusted code, it cannot escape its boundaries.

On startup, Frona verifies that the sandbox is working correctly. If the verification fails, the server won't start, unless the sandbox is disabled.

Keep the sandbox enabled

LLMs can make mistakes, and prompt injection is a real threat. A malicious webpage or document could trick an agent into running harmful commands. The sandbox is the cornerstone of securing your data. It works hand in hand with agent specialization: give each agent only the tools, network access, and files it needs, so even if something goes wrong, the blast radius is contained.

Filesystem isolation

Each agent can only read and write files within its own workspace directory. The sandbox blocks access to everything else on the system.

What agents can access:

• Their own workspace directory (read and write)
• Shared paths you explicitly grant in the agent's sandbox settings
• System libraries and language runtimes (read-only, needed to execute code)
• Standard temp directories

What agents cannot access:

• Other agents' workspaces
• Other users' files
• System configuration files
• Anything outside the explicitly allowed paths

The agent's workspace becomes its home directory. Python virtual environments, Node.js modules, and shell config all live inside the workspace, fully isolated.

Network access

You control whether an agent can make network connections, and to which destinations. There are three modes:

Full access. The agent can reach any host. This is the default.

Restricted. The agent can only reach specific destinations you allow. Everything else is blocked. Destinations can be:

• Hostnames: api.github.com
• IPv4 addresses: 1.1.1.1
• CIDR ranges: 10.10.100.0/24
• IPv6 addresses: [::1]

DNS resolution is handled automatically. When you add a hostname, the sandbox resolves it and allows connections to the resulting IPs.

No access. The agent is completely offline. No network requests of any kind.

This is the most important security setting. An agent configured to only reach api.github.com cannot exfiltrate data to any other server, even if the code it runs tries to.

Resource limits

The sandbox monitors and enforces CPU and memory usage in real time. If an agent exceeds its limits, the offending process is killed immediately.

Per-agent limits

Each agent can have its own resource limits, configured in the agent settings:

• Max CPU (%). The maximum CPU this agent can use, as a percentage of total system CPU.
• Max Memory (%). The maximum memory this agent can use, as a percentage of total system memory.
• Timeout (seconds). Maximum execution time per command. Commands that run longer are killed.

If you don't set per-agent limits, the server defaults apply.

Server-wide limits

Server-wide defaults protect the system as a whole:

Setting	Default	Description
Per-agent CPU limit	95%	Max CPU any single agent can use
Per-agent memory limit	80%	Max memory any single agent can use
Global CPU limit	98%	Max CPU all agents combined can use
Global memory limit	90%	Max memory all agents combined can use

The resource monitor polls every 250ms. If an agent exceeds its limit, the largest process in its process tree is killed. If all agents combined exceed the global limit, the largest process across all agents is killed.

Shared paths

By default, agents can only access their own workspace. If an agent needs to read files from another location, you can add shared paths in the agent's sandbox settings.

Shared paths can be:

• Absolute filesystem paths
• Virtual paths like agent://other-agent/data or user://username/files

You can add paths manually or browse the file system from the agent settings UI.

Sandbox drivers

Frona selects the best sandbox driver for your platform automatically:

Platform	Driver	Capabilities
Linux (with Syd)	Syd	Filesystem, network, and resource isolation. Full protection.
Linux (without Syd)	Landlock	Filesystem isolation only. No network enforcement.
macOS	macOS sandbox-exec	Filesystem and network isolation. Less strict than Linux.
Other / Disabled	No-op	No restrictions. Only for development.

For production, Linux with Syd provides the strongest isolation. The sandbox driver in use is visible in the agent settings UI.

What users see

When the sandbox blocks something or enforces a limit, the agent reports it in the chat:

• Timeout. "Process timed out after N seconds."
• Resource kill. "Process killed: resource limit exceeded."
• Cancelled. "Process cancelled by user."
• Non-zero exit. The exit code and any error output are shown.

This feedback helps you decide if you need to adjust the agent's sandbox settings (e.g., increase timeout, allow a network destination, or raise a resource limit).

Disabling the sandbox

You can disable sandboxing entirely in the server settings. This is not recommended for production. It removes all execution restrictions, meaning agents can access any file and any network destination on your server.

Tips

• Default to restricted. Start with specific allowed network destinations and add more as needed, rather than allowing everything.
• Match sandbox to agent purpose. A research agent needs web access, but a data processing agent probably doesn't. An agent that only talks to your internal API should only reach that host.
• Use longer timeouts for heavy work. Data processing, large file operations, and package installs may need more than the default timeout.
• Check blocked requests. If an agent's task fails unexpectedly, check if it hit a sandbox restriction. The error will appear in the chat.
• Use shared paths sparingly. Every additional path widens the agent's access. Only grant what's necessary.

Next steps

• Creating & Configuring Agents. Set sandbox settings per agent.
• Building & Deploying Apps. How app sandboxing works.
• Setting Up Authentication. Other security features.