Agent Sandbox & Programmatic Tool Calling
Agent Sandbox gives Glean Assistant a virtual computer. It has a file system, shell, and code interpreter that sits alongside the LLM. Think of the LLM's context window as RAM and Agent Sandbox as a hard drive. When a user asks Glean to analyze hundreds of records or aggregate data across systems, the Assistant can't fit everything into the context window at once. Agent Sandbox solves this by giving the model a virtual file system to store results, a shell to run commands, and a Python interpreter to write and execute analysis code.
Programmatic Tool Calling (PTC): PTC lets Glean orchestrate tools directly from code running in a sandboxed execution environment, avoiding a model round trip for each tool call. This reduces latency in multi-step workflows and lowers token usage by processing or filtering data before it enters the model's context window.
- This feature is available for Glean Key and Glean-hosted customers only.
- This feature is being rolled out to specific groups in phases. If you are a Glean Key or Glean-hosted customer, you may not see this feature yet.
We recommend using the latest frontier models to fully leverage these new tools: GPT 5.4, Claude Sonnet 4.6 or Claude Opus 4.6, and Gemini 3.1 Pro. If you're on Glean Key, you can automatically leverage these models using your model picker in chat. If you're on Customer Key, you can update your default model in the LLM section of Settings.
What Agent Sandbox and PTC enable
With Agent Sandbox, Assistant can pull data in batches, keep working files and intermediate results in the sandbox, and run Python for joins and aggregations. Only summarized or filtered output needs to sit in the model’s context window. When PTC is enabled for your organization, the same sandbox session can also invoke allowlisted tools from code (loops, branches, paging) without a full model round-trip for each tool call.
Without a sandbox (and without staging data in that environment), a frontier model in Glean is limited by its context window: it cannot hold every relevant row from every source in one prompt. Workflows that need many retrieval steps, working sets larger than the window, or dependable counting and arithmetic over hundreds or thousands of rows are a poor fit for reasoning from context alone.
Indexed enterprise content often spans many applications, for example: Salesforce, Gong, Zendesk, Slack, Confluence, and Jira. Analytical questions often require combining those sources and operating on large numbers of individual records, not just a short list of snippets.
Agent Sandbox removes that context window ceiling and gives the model a virtual file system. It can paginate through thousands of data points across multiple systems, store data in its virtual file system, and write Python code to compute aggregations, distributions, risk scores, and custom business logic on the fly.
When the model runs Python in Agent Sandbox, exact work—record counts, aggregates, ordering by date, conditional rules over large row sets—runs in the interpreter instead of being inferred only through natural-language reasoning, where those steps are easy to get wrong.
The model still authors the program: it fetches data in batches or pages, applies filters and joins, deduplicates across sources, and passes smaller derived outputs into the context window for interpretation. Intermediate steps and artifacts in the sandbox can be inspected for audit or debugging, and the workflow extends to volumes that cannot be pasted wholesale into context.
With PTC, tool invocations are issued from sandbox code (including loops and branches), so a long sequence of calls does not require a full LLM round-trip for each step. For example, paging and merging many Salesforce reads can be one program instead of 10+ separate model turns.
The same pattern applies across tools: one script can call Glean Search, Document Reader, JQL, SOQL, and similar allowlisted tools, with filtering or merging between calls. Without PTC, each tool use is typically its own model generation step; with PTC, orchestration stays in code until the model needs to read results and produce the user-facing answer.
Example use cases
| Use Case | Query |
|---|---|
| Pipeline review | Go through all open Salesforce opportunities closing this quarter. Group by stage, owner, and ARR. Flag any stuck in the same stage for 30+ days. Give me a risk-adjusted forecast. |
| Competitive analysis | Analyze all closed-lost deals from Q4. Group by competitor, identify the top reasons we lost, and surface patterns across deal size and segment. |
| Support ticket analysis | Go through all support tickets from the past 60 days. Identify the top 10 most common issues, calculate first-response time and resolution time, and flag open tickets older than 7 days. |
| Postmortem review | Go through all post-mortems from the last 6 months. What are the recurring root causes, and which ones have we actually fixed vs. just acknowledged? |
| Customer evidence | Pull all customer conversations from Gong, Zendesk, and Slack mentioning "memory." How many unique customers have asked for it, what are their use cases, and what workarounds are they using? |
| Time analysis | How do I spend my time? Pull my calendar data and categorize meetings by type, participants, and frequency. Show me where my time goes. |
| Org chart growth | Show me how the engineering org has grown over the past year. Break down by team, hiring velocity, and reporting structure. |
Activate Agent Sandbox and PTC
Automatic activation (sandbox): Agent Sandbox triggers automatically in Thinking mode when the query benefits from code execution, exhaustive retrieval, or cross-system aggregation. Ask Glean in Thinking mode—there is no separate end-user toggle for the sandbox itself.
PTC: Programmatic Tool Calling only runs inside an Agent Sandbox session. In Glean’s configuration they are separate controls: sandbox code execution can be available without PTC, while PTC always requires an active sandbox so generated code can call tools through the host agent. For eligible customers, Glean typically enables both together for Assistant in Thinking mode as this capability rolls out.
Model support: Code execution is exposed through a generic shell tool rather than a single vendor’s native “code mode” API, so models that participate in the agentic loop with sandbox access can drive the same shell abstraction. The underlying sandbox may be Glean-operated or provider-hosted depending on deployment settings; modes that omit the shell tool (for example some fast or minimal tool sets) do not support Agent Sandbox or PTC.
Security & Data Protection
Agent Sandbox provides a secure, isolated execution environment for AI-powered code execution and data analysis within Glean. It was designed with enterprise security as a foundational requirement, ensuring that customer data remains protected at every layer.
For Glean's broader security posture, certifications, and compliance documentation, see:
- Glean Security Page
- Glean Trust Portal (under NDA)
- Security & Architecture Hub (Help Center)
- Data Analysis: File Security (Help Center)
- Data Analysis: Technical Overview (Help Center)
Agent Sandbox Security
Sandbox Isolation
Every sandbox instance runs in an isolated environment designed to keep each session separate and protect customer data.
- Per-tenant, per-session isolation: Each sandbox is dedicated to a single customer environment and a single session. There is no cross-session or cross-tenant access to data, code, or artifacts.
- Ephemeral by design: When a session ends, sandbox data and artifacts are removed. If conversation history across turns is enabled, filesystem state can be preserved only as needed to support pause/resume.
- No cross-sandbox communication: Sandboxes cannot detect or interact with other instances, and each session remains isolated from the others.
Data Residency
Sandbox execution runs on infrastructure Glean operates on behalf of your isolated customer environment—not on end-user devices. Data you process in the sandbox stays within your tenant’s Glean boundary and is not sent to third-party orchestration services for sandbox control.
For how Glean provisions isolated sandbox workloads (for example dedicated pods and orchestration in Glean’s cluster for comparable analysis sandboxes), see Data Analysis: Technical Overview.
- Single-tenant architecture: Each customer environment is fully isolated in its own dedicated infrastructure. Customer data is not sent to any external orchestration services.
Network Security
- No outbound internet access by default. When egress is required (e.g., for LLM provider calls), only pre-approved domains are permitted via allowlisting.
- Restricted ingress. Only authenticated internal systems can communicate with sandbox instances.
- No access to infrastructure credentials. Sandboxes do not have access to cloud IAM credentials, secrets, or other infrastructure resources.
Execution Security
- Processes run with non-root permissions and cannot escalate privileges.
- Resource limits are enforced per sandbox to prevent abuse and resource exhaustion.
- The sandbox file system is scoped to the session with no access to host or other tenant file systems.
Permissions & Access Control
Agent Sandbox inherits and enforces Glean's existing permission model, ensuring users can only access data they are already authorized to see.
- Permission-aware retrieval: All results respect the user's existing source-application permissions. Permission changes propagate immediately.
- No privilege escalation path: Even in the event of a prompt injection attempt, the sandbox cannot access data beyond the user's existing entitlements.
AI Security
Glean provides runtime AI security capabilities that detect and block prompt injection attacks, jailbreak attempts, malicious code, and toxic content across Assistant, Agents, and sandboxed tools.
- Optional Palo Alto Networks Prisma AIRS integration is available for organizations requiring additional runtime defenses.
Programmatic Tool Calling (PTC) Security
PTC enables LLM-generated code to orchestrate enterprise tools from within the sandbox. Additional security controls include:
- No credentials in sandbox: The sandbox never holds authentication tokens, API keys, or secrets. Tool calls are mediated by the host agent — no credentials cross the sandbox boundary.
- Tool allowlisting: Only explicitly allowlisted tools are exposed. PTC currently supports read-only tools only; write actions are not supported through programmatic tool calling.
- Global call budget: A per-session cap on total tool invocations prevents runaway loops or resource exhaustion.
- Permission enforcement: All tool calls go through the same permission-aware execution path as direct tool calls. Source-app ACLs are enforced outside the sandbox.
- Code inspection: All sandbox code is logged and available for audit. Malicious code detection applies to PTC-generated code.
Compliance
Glean's platform-level compliance certifications extend to Agent Sandbox: SOC 2 Type II, ISO 27001, ISO 42001, HIPAA, GDPR, TX-RAMP Level 2.
FAQ
Can a user access another customer's data? No. Sandboxes are per-tenant and per-session, with isolation enforced at the sandbox runtime and network boundary (dedicated instances, no cross-session or cross-tenant file or process access). There is no supported path for one tenant’s sandbox to read another tenant’s data.
What happens to data after a session ends? All data, code, and artifacts are permanently deleted.
Can the sandbox make outbound internet requests? No. Network egress is disabled by default.
Does prompt injection pose a risk? Source-app ACLs are enforced outside the model layer. Even if a prompt injection is attempted, the user can only access data they already have permission to see, within their own ephemeral session.
Where does sandbox execution happen? On infrastructure Glean operates for your tenant (for example isolated workloads in Glean’s environment), consistent with the sandbox orchestration patterns described in Data Analysis: Technical Overview (Help Center). Execution does not run on the end user’s device. Data stays within your tenant’s Glean boundary.
Can PTC-generated code exfiltrate data? No. The sandbox has no network egress, tool results stay within the session, the tool allowlist restricts exposed tools, and a call budget caps invocations. Malicious code detection inspects for exfiltration patterns.
Does PTC give the model access to credentials? No. The sandbox never holds tokens, keys, or secrets. Tool calls are mediated by the host agent outside the sandbox boundary.
What tools can PTC call? Only tools on the admin-configurable allowlist, including read-only native tools (Glean Search, Document Reader, email search, web search, employee search, code search, JQL, meeting lookup). PTC does not support write actions; allowlisted tools are read-only.