Building a Generalized Internal Agent with Sandboxed Execution and Credential Brokering

browserbase · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Generalized internal knowledge-work agents

Browserbase wanted one internal agent, bb, to automate cross-functional knowledge work across engineering, ops, sales, support, and executives without building a separate bot for every task or leaking credentials into arbitrary agent sandboxes.

Constraints:

many internal workflows happen in web apps without clean APIs
agent sandboxes execute arbitrary code and must not receive raw credentials
interactive Slack runs need continuity while background webhook runs need hard-scoped permissions
the agent needs domain-specific playbooks without bloating the core loop
permissions must be narrower than service-level RBAC for agent use cases

Architecture

Browserbase built bb as one OpenCode-based agent loop running in isolated cloud sandboxes. Slack interactive sessions create or reuse a sandbox keyed by thread ID, stream SSE events back to Slack, and preserve multi-turn state. Background webhooks dispatch to the same sandbox infrastructure with hard-scoped permissions. Skills are lazy-loaded markdown playbooks, while service packages expose typed API wrappers through a secure integration proxy. Credentials are brokered through proxy calls or network-level egress injection, with scoped permissions, request interception, and domain allowlisting.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  slack-interface[Slack interface] --> slack-events-handler[Slack events handler]
  slack-events-handler --> kv-thread-store[KV thread store]
  kv-thread-store --> sandbox-session[Sandbox session]
  webhook-handlers[Webhook handlers] --> sandbox-session
  webhook-handlers --> permission-system[Permission system]
  pre-warmed-snapshot[Pre-warmed snapshot] --> sandbox-session
  sandbox-session --> opencode-core-loop[OpenCode core loop]
  opencode-core-loop --> skill-router[Skill router]
  skill-router --> markdown-skills[Markdown skills]
  opencode-core-loop --> service-packages[Service packages]
  service-packages --> secure-integration-proxy[Secure integration proxy]
  secure-integration-proxy --> permission-system
  secure-integration-proxy --> credential-broker[Credential broker]
  credential-broker --> sandbox-session
  credential-broker --> permission-system

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Slack interface`	Primary conversational interface for interactive bb requests and streaming updates.	`Slack events handler`, `Sandbox session`
`Slack events handler`	Receives @bb events and dispatches to internal endpoints.	`Slack interface`, `KV thread store`, `Sandbox session`
`KV thread store`	Maps Slack thread IDs to sandbox IDs for multi-turn continuity.	`Slack events handler`, `Sandbox session`
`Webhook handlers`	Start background bb runs from support-ticket and transcript events with scoped permissions.	`Sandbox session`, `Permission system`
`Sandbox session`	Ephemeral Linux VM with filesystem, network, and process isolation for each agent run.	`Slack interface`, `KV thread store`, `OpenCode core loop`, `Credential broker`
`Pre-warmed snapshot`	Base sandbox image rebuilt every 30 minutes so sessions boot quickly with required tools installed.	`Sandbox session`
`OpenCode core loop`	Agent harness for LLM conversation, tool orchestration, context management, streaming, and context compaction.	`Sandbox session`, `Skill router`, `Service packages`
`Skill router`	Routing table that lazy-loads markdown skills based on request type.	`OpenCode core loop`, `Markdown skills`
`Markdown skills`	Domain-specific playbooks, schemas, and decision trees loaded into context on demand.	`Skill router`, `OpenCode core loop`
`Service packages`	Typed TypeScript wrappers around external APIs called through the exec tool and proxy.	`OpenCode core loop`, `Secure integration proxy`
`Secure integration proxy`	Serverless proxy that holds real credentials, checks permissions, and calls services.	`Service packages`, `Permission system`, `Credential broker`
`Credential broker`	Injects real credentials at proxy or network egress while the sandbox sees only references or placeholders.	`Sandbox session`, `Secure integration proxy`, `Permission system`
`Permission system`	Scopes available services, methods, domains, and invocation-specific permissions.	`Webhook handlers`, `Secure integration proxy`, `Credential broker`

Data flow

A Slack mention or webhook invokes bb. The system creates or reuses an isolated sandbox from a pre-warmed snapshot. The agent loads only the relevant skills, calls typed service packages through an integration proxy, and receives scoped access via credential references rather than real keys. Results stream back to Slack or a dedicated channel, while background sessions close when work is complete.

3 supporting quotes

“Someone types @bb in a Slack channel. The Slack events handler dispatches to an internal endpoint, which creates or reuses a sandbox keyed by the Slack thread ID in a KV store.”article, stated

“External events like a Pylon support ticket closing or a Circleback meeting transcript landing trigger webhook handlers that dispatch to the same sandbox infrastructure”article, stated

“Instead of baking secrets into the sandbox, the sandbox boots with only references and short-lived tokens: 1. BB_PROXY_URL — the URL of a serverless integration proxy 2. BB_SESSION_TOKEN — a rotating session token (TTL’d in a KV store)”article, stated

Why this architecture

Browserbase argues that one generalized agent loop works if capabilities, access, and repeatable workflows are separated. Sandboxes give safe execution, credential brokering prevents raw secret exposure, scoped permissions constrain runs by invocation source, and skills keep the core loop general while loading task-specific playbooks only when needed.

3 supporting quotes

“Instead of building a bot per task, we run one agent loop and “lazy load” two things per task: skills (playbooks) and permissions (scope).”article, stated

“Most internal agents start as coding agents. Ours did too. The question that changed everything was: if the agent can already read code, write files, and call APIs, why can't it do everything else? All we had to do was separate the agent's capabilities from its core loop.”article, stated

“4. An agent interface — Slack is the highest-leverage starting point because it's where your team already communicates One agent with good abstractions beats a fleet of narrow bots. Build your own bb.”article, stated

Models used: OpenCode · LLMs inside bb

Scale

Browserbase reports 100 percent feature request pipeline coverage with zero human effort.
“Our feature request pipeline runs at 100% coverage with zero human effort. Every closed support ticket and every meeting transcript gets scanned automatically, helping reduce 99% of our first response time to <24hrs.”article, stated
Browserbase reports 99 percent of first response time under 24 hours.
“Every closed support ticket and every meeting transcript gets scanned automatically, helping reduce 99% of our first response time to <24hrs. Session investigation dropped from 30–60 minutes of manual log-diving to a single Slack message.”article, stated
Session investigation dropped from 30 to 60 minutes to one Slack message.
“Session investigation dropped from 30–60 minutes of manual log-diving to a single Slack message. Many engineers went from writing a majority of PRs by hand to reviewing them.”article, stated
Sandboxes idle out after 30 minutes of inactivity.
“The sandbox idles out after 30 minutes of inactivity, and no state persists between sessions unless we explicitly snapshot it.”article, stated
Snapshots are rebuilt every 30 minutes.
“The interesting part isn't the sandbox product, it's what we bake into it. Every sandbox starts from a pre-warmed snapshot that gets rebuilt every 30 minutes via a cron job:”article, stated

Alternatives considered (roads not taken)

One bot per task

Rejected because: Browserbase wanted one core loop that lazy-loads skills and permissions instead of a fleet of narrow bots.

“Instead of building a bot per task, we run one agent loop and “lazy load” two things per task: skills (playbooks) and permissions (scope).”article, stated

Clean API integrations only

Rejected because: A lot of knowledge work happens in human-facing web apps, dashboards, portals, inboxes, and PDFs.

“We’ve already connected it to a majority of our systems, but a lot of knowledge work doesn’t happen behind clean APIs. It happens in web apps built for humans (dashboards, portals, inboxes, PDFs). The Browserbase Platform ensures that BB can do all of the same work that we do.”article, stated

Put API keys directly in sandbox environment variables

Rejected because: The agent can execute arbitrary code, echo secrets, or write credentials to files.

“If you pass API keys as environment variables, nothing stops the agent from running echo $SOME_API_KEY or writing credentials to a file”article, stated

Only service-level RBAC

Rejected because: Agent-specific restrictions are needed so a scoped session can use search methods without destructive operations.

“Even if it has access to HubSpot, a scoped session might only allow hubspot.search* and not hubspot.delete*.”article, stated

Patterns

`tool-use-orchestration` (orchestration)

bb calls APIs, browser automations, SQL, code tools, support systems, and CRM workflows through a small typed service-package surface.

“it keeps the tool surface small, defines the TypeScript interfaces once in the exec tool, and lets the agent do dynamic pre-transforming in deterministic code”article, stated

`privacy-preserving-processing` (security)

The sandbox receives credential references or placeholders while the proxy or network broker injects real secrets outside the agent's direct environment.

“The sandbox environment variable is set to a placeholder string like "credential-brokered" so the SDK initializes without erroring”article, stated

`safety-policy-enforcement` (security)

Scoped permissions, domain allowlisting, and method-level restrictions limit what the agent can do even when it has service access.

“we add request interception and domain allowlisting for sensitive internal APIs”article, stated

`context-compaction` (memory)

Browserbase relies on OpenCode for context management and compaction in the core loop.

“It handles the LLM conversation, tool orchestration, context management, streaming, and context compaction.”article, stated

`agent-memory` (memory)

Slack threads map to persistent sandbox sessions so follow-ups retain conversation and file context.

“The sandbox persists, so the agent has all the context from the previous turn including files it read, queries it ran, results it got.”article, stated

`structured-output-contract` (tooling)

Skills and service packages define schemas, decision trees, and typed interfaces for repeatable agent work.

“Skills are markdown files in .opencode/skills/ that inject domain-specific workflows, schemas, and decision trees into the agent's context on demand.”article, stated

Tradeoffs

Run one generalized agent loop

Chose lazy-loaded skills and permissions over separate bots for every internal workflow.

Rationale: A single core loop can generalize if domain knowledge and access scopes are loaded per task.

“One agent with good abstractions beats a fleet of narrow bots.”article, stated

Use isolated cloud sandboxes

Chose ephemeral Linux VMs with filesystem, network, and process isolation over running arbitrary agent code against production infrastructure.

Rationale: The sandbox gives the agent execution power without directly touching production infrastructure or persisting state by default.

“You need a place where the agent can read files, write code, run shell commands, call APIs, and do it all without touching production infrastructure or leaking credentials.”article, stated

Put the primary interface in Slack

Chose Slack threads as persistent agent workspaces over a separate app-first workflow.

Rationale: Slack is where company work conversations already happen, and threads provide free multi-turn state.

“Slack threads give you free multi-turn state. Each thread is a persistent workspace with its own sandbox, conversation history, and file state.”article, stated

Keep tool APIs typed and narrow

Chose TypeScript service packages through an exec tool over a broad untyped tool surface exposed directly to the model.

Rationale: Typed wrappers keep context smaller and allow deterministic pre-transforming before results reach the agent.

“typed TypeScript wrappers around external APIs that get called through the proxy.”article, stated

Gotchas (what bit them)

Agent sandboxes are dangerous if given raw secrets.

Root cause: The LLM can choose arbitrary shell commands or file writes inside the sandbox.

Resolution: Use credential brokering, secure integration proxying, short-lived tokens, and placeholders instead of raw environment variables.

“Here's the uncomfortable truth about agent sandboxes: they run arbitrary code.”article, stated

Credential brokering alone is not enough.

Root cause: Even brokered credentials can be abused through arbitrary HTTP requests.

Resolution: Add request interception and domain allowlisting for sensitive APIs.

“Credential brokering isn’t the final frontier for secure agent access. Even with brokered credentials, an agent can still generate arbitrary HTTP requests”article, stated

Interactive and background invocations need different permission models.

Root cause: Slack sessions are exploratory while webhook sessions carry explicit intent and should not inherit broad access.

Resolution: Let interactive sessions self-select skills and services, but hard-scope webhook permissions at invocation time.

“For interactive Slack sessions, the agent reads this routing table and self-selects. For background webhook sessions, the permissions system hard-restricts which tools and services are available”article, stated

API-only automation misses much internal work.

Root cause: Knowledge work often lives in human-facing web applications and documents rather than clean API surfaces.

Resolution: Use browser automation as the universal interface for dashboards, portals, inboxes, PDFs, and other web apps.

“The Browserbase Platform ensures that BB can do all of the same work that we do.”article, stated

Evaluation

Browserbase reports operational outcomes across feature-request coverage, support response time, session investigation, and engineer workflow changes, plus architectural checks around sandboxing and permissions.

Metrics: 100% feature request pipeline coverage · 99% first response time under 24 hours · 30-60 minute session investigations reduced to one Slack message · 30-minute sandbox idle timeout · 30-minute snapshot rebuild cadence

“Our feature request pipeline runs at 100% coverage with zero human effort.”article, stated

“Session investigation dropped from 30–60 minutes of manual log-diving to a single Slack message.”article, stated

Outcomes

bb became a generalized internal interface across engineering, ops, sales, support, and executive workflows
feature request scanning reached 100% coverage with no human effort
support first-response time improved so 99% are under 24 hours
session investigation collapsed from manual log-diving to a Slack request
many engineers shifted from writing PRs to reviewing agent-generated ones

The source describes company-wide internal use and gives concrete operational metrics, but does not publish absolute request counts.

“Every closed support ticket, every meeting transcript, every data pull, and many PRs at Browserbase goes through one generalized agent.”article, stated

“Many engineers went from writing a majority of PRs by hand to reviewing them.”article, stated