Secure code execution and credential management for your AI agents.
The Code Sandbox gives your agent the ability to execute Python code and shell commands in a secure, isolated cloud environment. It is natively enabled on all agents with no configuration required.
Each conversation runs in its own secure cloud sandbox (an isolated VM). The files your agent creates while working stay with that conversation, so if you reopen the chat later they are restored automatically.Anything that should outlive a single chat lives in one of two durable layers that carry over across all conversations with the same agent: the shared package environment and the agent’s workspace folders.
Persistence Model
Isolation
Scope
What Persists
Lifetime
Per-conversation files
Files the agent saves in its working directory
Saved with the conversation and restored when you reopen it
Shared across every chat on the agent. Members with edit access add packages once and they become available to everyone
Team workspace (.workspace/agent/)
Skills and files saved to the shared workspace
Shared across all conversations and all members of the agent
Personal workspace (.workspace/personal/)
Files you save to your private workspace
Private to you, persists across all your conversations with that agent
Python variables and imports remain available while the conversation’s Python kernel is running. They are not archived with files and may be lost if the kernel or sandbox is restarted. Save important intermediate results to files so the agent can reload them.
Starting a new conversation gives you a fresh working directory, but your installed packages and workspace files are already available from previous sessions.
Conversations are isolated from one another:
Each chat runs in its own sandbox, so one conversation can never see another conversation’s in-progress working files.
Sharing across chats happens only through the workspace folders and the shared package environment described above.
Your personal workspace is private to you. Other members of the same agent cannot see it.
Subagents spawned by your agent run in their own sandboxes but mount the same workspace folders and package environment, so they can reach the same shared files and packages.
Need something that isn’t pre-installed? Your agent can install it with pip install package-name. Installed packages are shared across every chat on the agent, so you only need to install once. Members with edit access to the agent can add packages for everyone; if you only have view access, your own installs are temporary and last for the current session.
Full internet access (API calls, pip installs, web requests)
GUI
Headless only. Visualizations must be saved to files (e.g., plt.savefig())
The sandbox is designed for data analysis, scripting, and automation tasks. It is not intended for training large ML models or running persistent servers.
The agent has two persistent workspace folders that carry over across conversations:
Team workspace (.workspace/agent/) — shared by everyone with access to the agent. Files saved here by one member are visible to all other members, which makes it ideal for reference data, configuration, or ongoing project assets. Members with edit access can write to it; members with view access can read it but not change it.
Personal workspace (.workspace/personal/) — private to you. Files you save here persist across your own conversations with the agent and are never visible to other members.
Your agent chooses the right folder automatically based on whether a file should be shared or kept private, so you can simply ask it to save something for later.Workspace files follow the same artifact system as other agent-generated files: they are versioned, previewable, and shareable.
For more details on file management, versioning, and sharing, see Agent Artifacts.
The sandbox has access to your connected apps via the pre-installed gumloop SDK. Your agent can call any of its configured integrations directly from Python code:
from gumloop import Gumloopclient = Gumloop()result = client.mcp.execute( server_id="slack", tool_name="send_message", arguments={"channel": "#general", "text": "Hello from the sandbox!"})
This means your agent can combine code execution with any integration, for example: query a database, process the results in Python, then post a summary to Slack.
Agent Secrets let you inject encrypted credentials into the sandbox as environment variables, so your agent can authenticate with external services (APIs, databases, etc.) without ever exposing the raw values.A secret is the stored credential, either personal or owned by a team. A binding maps an environment-variable name on an agent to a secret. Binding scope controls who gets that mapping; it does not change who owns the secret.
Open the agent, go to the Agent tab, expand Secrets, and click + Add.
2
Name it and pick a source
In Add personal secret to agent, set Name to the environment-variable name the agent should use (for example PYLON_API_KEY). Under Source, choose Existing secret or New secret, then pick or create the stored credential.
Click Add. The secret appears by name in the Secrets section. The agent can use it at runtime as an environment variable, but it never sees the raw value.
3
Prompt the agent to use the secret
In the agent chat, ask it to perform a task that requires the credential. The agent accesses the secret as an environment variable (e.g. os.environ["PYLON_API_KEY"]) and uses it in code, but it can never read or expose the actual value.
If you share an agent that uses personal secrets, other users will be prompted to provide their own values. Your secrets are never exposed.
Bindings can be saved for User or Team scope in Secrets on the Agent tab:
Scope
Who it applies to
Requirement
User
You only. The binding is saved to your own row.
Anyone who can read and use the agent can save their own user bindings.
Team
Everyone on the agent’s home team who uses the agent.
The agent must have a home project/team, and you must have permission to manage the project’s variables. Team bindings can reference only secrets owned by that home project.
The scope toggle offers Team and User. The panel describes them as:
Team scope: “Anyone in your team who uses this agent can use these secrets. A user binding with the same name overrides these.”
User scope: “Only you can use these secrets. User secrets override matching team secrets.”
If you can read team bindings but cannot manage team secrets, you can see the Team list but are prompted to request the required permission instead of adding a binding. A personal agent with no home team can only have user bindings, so the Team option is not offered.
Secrets resolve based on the running user, not the agent owner. A user who runs an agent without a binding of their own is prompted to configure one.For each run, the authorized home-team bindings are merged with the running user’s bindings. If the same environment-variable name exists in both, the user binding wins.Team bindings are skipped when the running user does not have permission to read the home project, so users outside that team do not get them. Permissions are checked again when bindings are used, not only when they are saved.When a user encounters a secret they haven’t configured, the chat prompts them to configure it:
When the agent asks you to bind secrets mid-chat, the prompt asks Who should use these bindings?Options:
Skip: proceed without the secret
Only me: the binding applies to you
My team: the binding applies to everyone on the agent’s home team; offered only when the agent has a home team and you can manage the team’s variables
If the question goes unanswered, the binding is saved for you only, so access is never widened by accident.
Users can also manage their active secrets during a conversation using the Secrets button in the chat composer:
No. Secrets are injected as environment variables at runtime. The agent can reference them by name (os.environ["MY_KEY"]) but never sees the actual value. Values are encrypted and never shown to the agent.
Can I use both personal and team secrets on the same agent?
Yes. An agent can use personal and team secrets, and it can have both user and team bindings. Team bindings require a home team and the appropriate project access. If you run an agent with a binding you haven’t configured, the chat prompts you to bind your own (see Runtime Resolution).
Which binding wins when both bind the same environment-variable name?
Your user binding wins. The running user’s bindings override authorized team bindings with the same environment-variable name.
Who can see or use a team binding?
Anyone on the agent’s home team who can use the agent and has read access to the home project can use the binding. Permissions are checked again when the binding is used.
Why is the Team option missing?
The agent may not have a home team, or you may not have permission to manage the project’s variables. Personal agents with no home team offer user bindings only.
What about an agent with no home team?
It can use user bindings only. Team scope is not available without a home project/team.
Do secrets persist across conversations?
Yes. Secrets are bound to the agent configuration. They are available every time the agent runs code.