Security Model
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.
Settings
Settings search keeps provider, permission, and runtime configuration discoverable.
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, 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.
The diagram above is the whole model in one picture: risky capabilities pass through an Ambient mediation layer before they reach the desktop, and what comes back is bounded, approved, and reviewable.
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.
MCP servers
MCP workloads run inside ToolHive-managed containers with an explicit allow list, instead of as trusted processes on your host.
Browser & scrapers
Autonomous browsing and extraction run with URL policy and private-address protection, because any page can be adversarial. See Browser & Scraping Safety.
Pi packages
Sandboxed Pi support keeps tool-shaped packages separate from privileged extensions, with sanitized artifact paths.
Privileged installs
Packages that want lifecycle hooks, native dependencies, or host changes get explicit privileged review before they run.
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 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 and permission decision is recorded with a timestamp, 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 — 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.
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. At the same time, 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. ToolHive-backed capabilities also depend on a container runtime (Docker, Podman, or equivalent) being present and healthy.
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/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.