What it can do

The data BusyBro can read, the actions it can take, web search, and how permissions keep it safe.

BusyBro reads your live data, takes actions on your behalf, and reaches the web when an answer lives outside the project — all scoped, always, to what your role is allowed to do.

What it can read

BusyBro answers from your real data, not guesses. With the right capability, it can read:

  • Devices — the fleet, each device's basics (name, model, OS, last seen, detected country, app version), and live status (online/offline, VPN state, last heartbeat, IP country).
  • Captured traffic — counts and recent entries (time, device, method, status, host, path), over a rolling window or any absolute date range.
  • Settings — the effective settings for a device (per-device override merged over global) or the global defaults: connection type, applied service groups, breakpoint patterns.
  • Workspaces, tags, and service groups — including each service group's linked BusyBro agents and which one is primary (see Specialist agents).
  • Users and roles — for callers who hold users:view: who the users are, their roles, and device ownership.
  • Breakpoints and proxies — recent paused exchanges, and the available upstream-proxy pool (for callers who hold devices:view). Proxy credentials are never surfaced.

Deep inspection with secret redaction

The headline read is deep request inspection — point BusyBro at a captured host and it reads the actual request and response headers and bodies to explain how a real app or API works (login, token, refresh, OAuth, signed headers) and to hand you runnable repro code (curl / fetch).

Two things keep this safe:

  • Secrets are redacted. Tokens, cookies, API keys, and credentials in the captured traffic are treated as secrets — repro snippets use placeholders like <access_token>, never the live value.
  • Use a full hostname (with a dot) — api.example.com, not a bare brand word. If you only know the brand, BusyBro tries likely hosts such as identity.<brand>.com, auth.<brand>.com, api.<brand>.com.

What it can do

For a linked (Telegram) or logged-in (dashboard) user, BusyBro can also act — each action gated by the matching capability and limited to devices you own:

AskCapability
Set or clear a device's Live Activity messagedevices:edit
Rename a devicedevices:edit
Turn VPN on / offdevices:edit
Change a device's connection type (VPN / PAC)devices:edit
Set or clear an external (upstream) proxydevices:edit
Set the global default connection typeglobal:edit
Create, update, or delete service groups, and link their BusyBro agentsservices:edit
Create, update, or delete tagstags:edit
Drive a bmc device's Chrome — open a URL, screenshot, snapshot, evaluatedevices:edit + remote-control opt-in

External (upstream) proxy. Ask BusyBro to route a device's egress through an upstream proxy and its public IP and country become the proxy's — useful for testing geo-specific behaviour. It picks a healthy proxy from the pool by country (or you give an explicit host and port), writes it to the device's settings, and the proxy-server / cdp-connector pick it up automatically. It can then open a what's-my-IP page and screenshot it to confirm. Say "clear the proxy" to go back to direct egress.

Remote browser control. For a bmc (CDP) device that has remote control switched on, BusyBro can navigate Chrome, take screenshots, capture an accessibility snapshot, and evaluate JavaScript — enough to walk through a multi-step page flow and show you the result inline.

Note: The exact tool names and schemas live in the BusyBro API reference and the MCP server tools list. Describe what you want in plain language — BusyBro maps it to the right tool.

When the answer lives outside the codebase — a third-party API change, an SDK doc, an error-message lookup, recent events — BusyBro can search the web and cite what it found. It prefers project tools and docs for anything internal, and reaches for the web only when the answer isn't in the project.

How permissions keep it safe

BusyBro acts as you. It never has more power than you do, and it's bounded three ways:

  • Role. Every read and action is checked against your role's capabilities — the same RBAC model the dashboard uses. A viewer gets read-only help; if you can't do it in the dashboard, you can't do it through BusyBro. See Roles.
  • Ownership. Device actions are limited to devices you own — BusyBro won't touch someone else's device (unless you're an admin).
  • Confirmation. Destructive actions are confirm-gated — on Telegram they show a tap-to-confirm button, and the caller's permissions are re-checked at the moment of confirmation. Some powerful capabilities (like raw browser control and reading raw file contents from the repo) are admin-only.

Grounded code answers. When you ask whether something exists in the codebase, or where it lives, BusyBro doesn't guess from memory — it searches the actual repo and answers from what it finds (or tells you plainly if it couldn't verify). Any signed-in user can run that existence/where check (it returns the matching file paths); reading a file's full contents stays admin-only, so a non-admin learns whether and where something exists without seeing the surrounding source. (The repo is private, so an anonymous session gets none of this.)

If you ask for something outside your role, or for a device that isn't yours, BusyBro tells you plainly rather than pretending it worked. And it never leaks a secret in an answer — captured tokens and cookies are redacted in everything it shows you.

See also