Security & Trust for AgentNode

AgentNode runs third-party tool code on your own machine, not ours. Untrusted, community-tier code runs inside a hardened container — or not at all (fail-closed). Trusted and curated code runs host-side under policy checks. Your API keys stay in the OS keychain, and tool data never reaches our servers.

Is AgentNode safe?

AgentNode is built so that untrusted code cannot quietly run with your privileges. Community-tier packages run inside a hardened container or are refused (fail-closed); trusted and curated code runs host-side under policy checks; and your data and credentials stay on your machine. How safe it is in practice depends on your setup — running the local sandbox and keeping a sensible minimum trust level.

Does AgentNode sandbox community code?

Yes. Verified, unverified, and unknown-tier code runs in a hardened container — read-only filesystem, non-root user, dropped Linux capabilities, network off by default — or not at all. There is no silent fallback to host execution. It requires Docker or Podman plus the digest-pinned image; trusted and curated packages run host-side instead.

Where do API keys go?

Into your operating-system keychain via agentnode auth — never into sandboxed code. When a sandboxed agent needs an LLM, a host-side broker makes the call, so the provider key never enters the container, audit records, manifests, or lockfiles.

Can teams enforce policies?

Yes. A minimum trust level, the Guard policy engine (allow / prompt / deny per action), input inspection, rate limits, and lockfile-integrity checks all run locally and fail closed. In CI or non-interactive contexts, any prompt escalates to a denial.

Defense in depth

Trust is layered across the lifecycle of a package — from publish to runtime to your data.

Trust tiers

Every package version carries a trust level, and enforcement differs by tier: community tiers are sandboxed or refused, while vetted tiers run host-side under policy checks by default — and a user-controlled host-trust policy lets you sandbox them too.

Details per tier: Security model and Execution sandbox.

For teams and companies

AgentNode is designed to be governed before it is rolled out across agents:

• Set a minimum trust level so packages below your bar are denied before execution.
• The Guard policy engine classifies each action and returns allow, prompt, or deny — with rate limits and input inspection.
• Lockfile integrity is verifiable in CI (agentnode lock verify); tampered entries are denied in strict mode.
• In CI and non-interactive contexts, any prompt escalates to a denial — no silent approvals in automation.
• A local-only audit trail records every policy decision; it never leaves your machine.
• The whole runtime is fail-closed: missing config or an unavailable sandbox blocks execution, it does not loosen it.

See AgentNode Guard and the security model.

Honest limits

We document the boundaries plainly — trust is earned by being precise, not by overclaiming.

• By default, trusted and curated packages run host-side with policy checks and subprocess isolation, not OS-level filesystem or network sandboxing. Tighten this yourself with sandbox.host_trust_policy to sandbox those tiers too.
• Community sandboxing requires Docker or Podman plus the pinned image; without them, community code is blocked, not downgraded to the host.
• MCP servers must be pinned and preinstalled; they then run with no network by default, or a sealed egress allowlist when they declare allowed domains. Non-preinstalled (npx/uvx) servers are refused — filesystem, host, and secret isolation apply as before.
• The agent sandbox for community agents is opt-in and off by default; with it off, community agents are refused, not run on the host.

Full detail: Execution sandbox.

Next steps