Most agent tools protect you by sandboxing the whole agent, which also blinds it. Ambient does the opposite: the agent works on your real desktop, while the genuinely risky capabilities are the things that get contained.
Capability Security Boundary. Risky capabilities (an MCP server, a browser page scraper, and a Pi package) are routed through Ambient mediation, which applies a ToolHive contained MCP runtime, descriptor review, a permission profile, secret redaction, and audit artifacts. In parallel, the regular desktop (its files and tools) remains directly usable. The result: high-risk capability is bounded, approvals are visible, and proof is reviewable.
In short: risky capabilities pass through Ambient mediation (ToolHive containment, descriptor review, permission profiles, secret redaction, and audit artifacts) while the regular desktop stays directly usable: risk is bounded, approvals are visible, and proof is reviewable.
Sandbox the capability, not the agent#
If you lock an agent inside a VM, it stays safe and useless: it can no longer touch the files, terminals, and tools that make a desktop agent worth running. Ambient draws the boundary in a more useful place. The agent operates on your regular machine, with real filesystem and terminal access, and the specific high-risk surfaces (third-party MCP servers, autonomous browsing and scraping, privileged package installs) are the ones that run inside containers, behind policy, with redacted secrets.
What gets contained#
Not every action is risky, so not everything is treated the same. Ambient classifies capabilities by blast radius and contains the ones that warrant it: the three surfaces in the diagram above, plus privileged installs.
| Capability | How it is contained |
|---|---|
| MCP servers (third-party code) | Run inside ToolHive-managed containers with an explicit allow list, instead of as trusted processes on your host |
| Browser & scrapers (hostile pages) | Run with URL policy and private-address protection, because any page can be adversarial. See Browser and scraping safety |
| Pi packages (tool-shaped extensions) | Sandboxed Pi support keeps tool-shaped packages separate from privileged extensions, with sanitized artifact paths |
| Privileged installs (host mutation) | Packages that want lifecycle hooks, native dependencies, or host changes get explicit privileged review before they run |
Two of these surfaces have their own pages: curated defaults covers which capabilities ship reviewed, pinned, and sandboxed instead of installable on an agent's own initiative, and browser and scraping safety covers URL policy, private-address protection, bounded outputs, and the escalation ladder for web work.
How an approval flows#
Containment is only half the story; the other half is that you can see and gate what happens. A high-impact action moves through a visible policy path before it executes.
Descriptor review#
Before a capability runs, Ambient Desktop reads its descriptor (command, arguments, environment, and requested permissions) so the request is legible, not opaque.
Permission profile#
Each capability runs under a permission profile (allow, deny, prompt, or audit) scoped to a thread, workspace, or process. Defaults are conservative.
Visible approval#
Sensitive actions (web extraction, connector access, filesystem changes, workflow invocation) surface a permission prompt with the grantable scope, instead of happening silently.
Audit artifact#
Every tool call and permission decision is recorded with a timestamp, alongside inspectable evidence (output, screenshots, and logs) rather than an unverifiable summary, so there is a trail you can review after the fact.
Secrets stay out of the transcript#
Provider keys, browser credentials, and account tokens move through Ambient-managed secret flows. They are never pasted into chat and never written into transcripts or cached artifacts. Diagnostics are redacted, and artifact paths handed to sandboxed tools are sanitized so they cannot leak absolute paths, parent-directory traversal, or raw URLs. Do not paste secrets into chat; use the managed secret flows instead.
What this does and does not cover#
Ambient labels its security posture honestly. The container boundary for MCP, the permission prompts, secret redaction, and audit artifacts are real and exercised by release gates. This model contains third-party MCP servers, web content, and package installs, including privileged ones, which get explicit review. Privileged installs, hosted model endpoints, and local runtime exposure are higher-risk paths that carry their own maturity labels and validation references. They are not presented as finished.
FAQ#
Does the agent run with full access to my machine? The core agent works on your regular desktop, but high-risk capabilities are contained: MCP servers run in ToolHive containers, browser and scraper access is policy-bounded, and privileged installs require review. Sensitive actions prompt for approval.
Where do my API keys go? Into Ambient-managed secret flows, scoped to the capabilities that need them. They are redacted from diagnostics and never written into chat or transcripts. Do not paste secrets into chat.
Can I see what a capability did? Yes. Permission decisions and tool calls are recorded as audit artifacts, and results come back as inspectable evidence (output, screenshots, and logs) rather than an unverifiable summary.
Keep going#
- Privacy and data retention: what leaves your machine, and what the provider keeps
- Curated defaults: the reviewed, pinned, sandboxed capabilities that ship as the default catalog
- Browser and scraping safety: how untrusted pages are bounded by policy, isolation, and visible approval
- Plugins and marketplace: the install classes and the Capability Builder