Skip to main content

Agent security

The agent is designed to be powerful but controllable. Safety comes from a combination of approvals, scoping, and organization policy — not from limiting what the agent can help with, but from ensuring you see and approve what crosses trust boundaries.

What protects you

ControlWhat it does
ApprovalsCommands and out-of-scope file changes require your confirmation before they run
Working-directory scopeThe agent operates within the folder you opened and respects .gitignore
Path securitySensitive paths (e.g. .env, credential files) trigger approval on read and write
Command heuristicsDestructive shell patterns (recursive delete, disk tools) always require approval
Reviewable outputChanges land as diffs you accept or discard — nothing silent lands in your tree
Broker mediationAll tools, including MCP, flow through the tool broker

Approval layers

  1. Tool-level gates

    Individual tools declare when approval is needed — e.g. bash for dangerous commands, read/write for sensitive paths.

  2. User confirmation

    You approve, deny, or allow-for-session each pending action in the agent UI.

  3. Organization policy

    Admins constrain models, spend, plugin availability, and cloud network egress.

Scoping and sandboxing

Desktop and CLI

  • The agent's filesystem scope is the workspace root you opened.
  • .gitignore rules apply — ignored paths are not casually exposed.
  • Terminal commands run in a non-interactive shell with timeouts and output limits.
  • Dev servers can run detached; you still started the session and approve risky commands.

Cloud agents

Cloud runs execute in isolated environments with org-defined permissions:

ControlWhere to configure
Repository accessCloud agents · Setup
Network egressCloud agents · Security & network
Run visibilitySentinel

Treat cloud agents like CI: grant the minimum repo and network access the task needs.

Organization controls

Admins shape what's allowed across the org:

AreaControlDocs
ModelsRestrict which models and providers are availableModel control
SpendCap usage with budget policiesUsage & billing
PluginsCurate which marketplace plugins members can installPlugins
Platform auditOperator-level governance and audit eventsGovernance
Cloud networkRestrict egress for remote agent runsCloud agents · Security
Defense in depth

UI restrictions are enforced server-side. Policy changes are audited so admins can review who changed what and when.

Handling secrets

Don't paste secrets

Avoid pasting credentials into prompts. Use environment variables or your secret manager, and keep secret files in .gitignore so the agent doesn't read them.

Best practices:

DoDon't
Store secrets in env vars or 1Password EnvironmentsPaste API keys into chat
Add .env* to .gitignoreCommit .env files "just for local dev"
Use read-only MCP credentials for inspectionGive agents write access to production databases by default
Rotate credentials if accidentally exposedAssume the model "forgets" what you pasted

The 1Password marketplace plugin helps validate locally mounted env files before shell commands run — a useful guardrail when development secrets live outside the repo.

Terminal command gates

The bash tool enforces a 120-second timeout per command and evaluates shell input against heuristic patterns before execution. Commands matching destructive patterns — recursive rm, find with -delete, disk tools like shred or dd, and fork bombs — always require approval. The same gate triggers when a command references sensitive paths such as .env files, SSH keys (id_rsa, id_ed25519), or ~/.aws/credentials. These checks live in packages/agents-core and apply consistently on desktop and cloud; they complement org policy rather than replacing your review of unfamiliar commands.

MCP and plugin security

Installed plugins register MCP servers through the tool broker. Treat each connection like any other third-party integration:

  • Prefer OAuth or short-lived tokens over long-lived API keys where supported.
  • Scope credentials to least privilege — read-only for triage, write only when the task requires it.
  • Review which plugins are org-approved; unused integrations reduce attack surface.
  • Disconnect MCP servers you no longer need from Tools & MCP in the app.

Security checklist for teams

  1. Set model and budget policy

    Limit models to what you support and cap spend per member or org.

  2. Curate plugins

    Allow only marketplace plugins your team actually uses.

  3. Configure cloud egress

    Default-deny outbound network for cloud agents; allowlist required hosts.

  4. Train members

    Review approvals before accepting; never paste production secrets into prompts.

Tool broker

How tool mediation and auditability work across surfaces.

Cloud security

Network isolation and egress controls for remote runs.

Model control

Restrict providers and models available to members.