security / security model

Security Model

Ambient's security story centers on sandboxing capabilities, not only sandboxing the whole agent.

Developer Previewllms.txtSource evidence
Capability Sandboxing Model Ambient prefers sandboxing risky capabilities so the agent can operate on a regular desktop with bounded authority. Capability Sandboxing Model Ambient prefers sandboxing risky capabilities so the agent can operate on a regular desktop with bounded authority. classifies riskapplies policycontains executionproves outcome Sandbox boundary policyisolationaudit 1 Untrusted surface MCP serverPi packageBrowser pageScraper 2 Ambient mediation Descriptor reviewPermission policySecret redactionToolHive 3 Execution boundary Container workloadSandboxed Pi toolURL policyAudit log 4 User proof Prompted approvalVisible outputDiagnosticsRollback
Ambient prefers sandboxing risky capabilities so the agent can operate on a regular desktop with bounded authority.
Product screenshots

Settings

Settings search keeps provider, permission, and runtime configuration discoverable.

Ambient Desktop settings search.

Core Security Claim

Many agent systems lean on sandboxing the entire agent. Ambient's goal is different: let the agent work on the user's regular desktop while meaningfully sandboxing risky capabilities such as MCP servers, Pi tools, browser-backed scrapers, and privileged package installs.

Illustrative Boundaries

  • ToolHive runs MCP workloads behind containerized runtime boundaries.
  • Sandboxed Pi support keeps tool-shaped packages separate from privileged extensions.
  • Browser and scraping capabilities are wrapped with URL policy and isolated runtimes.
  • Provider secrets move through Ambient-managed secret flows and redacted diagnostics.

Known Boundaries

Security documentation does not pretend that every advanced path is complete. Privileged installs, hosted endpoints, and local runtime exposure carry maturity labels and validation references.