AgentNode Changelog

MCP servers now have the same terminal starting point as the other package types, and the model compatibility matrix has been refreshed with current flagships while keeping older still-valid results.

• ·`agentnode init --type mcp` scaffolds an MCP server listing — a schema-valid manifest (runtime mcp, a pinned mcp_server command with an npm/PyPI package and source_repo, honest permissions) plus a README that walks verify → submit
• ·`agentnode publish` detects an MCP manifest and routes you to `agentnode mcp verify` / `agentnode mcp submit` instead of failing deep in toolpack validation; non-MCP manifests are unaffected
• ·Refreshed compatibility data: 246 scored models (222 S-tier) with current flagships, models untestable in the latest batch kept and marked legacy rather than removed, and only hard-evidence removals delisted

Community agents now run sandbox-or-refuse by default, consistent with toolpacks and MCP servers: isolated in a container when the sandbox is available, otherwise refused cleanly — never on the host. Trusted and curated agents still run on the host under the default policy, unchanged.

• ·`agent_sandbox.enabled` now defaults to on: verified/unverified/unknown community agents run in an isolated container when a runtime and the pinned image are present, and are refused (never a host fallback) when it is unavailable
• ·Hardened agent container profile is locked by tests: CPU/memory/PID limits, read-only rootfs, all capabilities dropped, no-new-privileges, non-root user, noexec/nosuid /tmp, a clean ephemeral HOME, and no network
• ·Host secrets stay on the host: the container env carries only PYTHONPATH, the LLM key stays behind a host-side broker, and tool calls are brokered host-side where the allowlist is enforced
• ·The in-container wrapper neutralizes fork/exec/subprocess before agent code loads (defense-in-depth); end-to-end verified on a real container host

Behavioral change: Community agents were previously refused outright; they now run sandboxed or are refused with a sandbox-required message — no one loses a working agent, but the refusal wording changes on hosts without a container runtime. Set `agent_sandbox.enabled=false` (or `AGENTNODE_AGENT_SANDBOX=0`) to restore the previous behavior. Trusted/curated agents are unchanged.

Toolpacks can now declare the credentials they need, and sandboxed community toolpacks can receive your API keys under a fail-closed regime: consent bound to the exact package identity, an enforced egress allowlist, and name-only key pass-through. AgentNode never stores your keys.

• ·Toolpacks declare their required credentials in the manifest (`env_requirements`: names, required flag, description — never values); the declaration and the publisher's egress allowlist are sealed into the lockfile at install (tampering breaks integrity)
• ·`agentnode install` lists the declared environment variables with set/not-set status and tells you which required ones to set before running
• ·Sandboxed community toolpacks receive user-provided keys via a consent prompt bound to slug + version + artifact hash + key names + domains, an enforced egress proxy restricted to the sealed allowed domains, and name-only pass-through (the value never appears on argv, in the process spec, or in logs)
• ·Running with a missing required environment variable now fails before dispatch with an actionable, value-free message

`agentnode setup` now covers the full first-class configuration surface with multiple-choice prompts and clearly marked recommended defaults. Accepting every recommendation reproduces the current default configuration, so upgrading changes nothing until you opt in.

• ·The setup wizard covers installation behavior, trust level, permissions, guard posture, credentials, sandbox, and `sandbox.host_trust_policy` — each as a multiple-choice prompt with a marked (recommended) default
• ·New Guard posture step: Balanced, Strict, Permissive, or Customize-each (drills into all nine guard action types)
• ·Optional Advanced gate for niche first-class settings; deeply nested config (custom LLM endpoints, guard overrides) stays CLI-only by design
• ·A stored LLM key provider can now be offered as the default provider, and invalid interactive input re-prompts instead of silently taking the recommended option

Wizard-only change; runtime behavior and the default configuration are unchanged.

A new `sandbox.host_trust_policy` setting lets you decide which trust tiers may run directly on your host. AgentNode trusting a package's code is not the same as you trusting it with your machine — this setting closes that gap across toolpacks, MCP servers, and agents.

• ·New `sandbox.host_trust_policy` setting: `default` (curated + trusted may run on the host, today's behavior), `curated_only` (trusted is sandboxed), or `none` (nothing runs directly on the host)
• ·Honored uniformly by toolpacks, MCP servers, and agents through one shared decision; a tier the policy sandboxes is fail-closed — never a silent host fallback
• ·Under a stricter policy the installer builds a sealed sandbox volume for trusted/curated packages at install time, and the lockfile records how each package was built
• ·`agentnode sandbox doctor` is now policy-aware — it explains when a package is sandboxed by the policy and distinguishes a reinstall from a publisher-must-pin

Behavioral change: Not breaking by default — the default policy is exactly today's behavior. Opting into curated_only or none isolates more strongly and can break trusted/curated packages that expect the host filesystem, broad tools, host LLM keys, or network; after tightening the policy, reinstall affected packages and use `agentnode sandbox doctor` to see what each needs.

Community MCP servers no longer have an open default-network path. A community MCP runs only when it is pinned and preinstalled into a sealed volume — with no network by default, or a sealed egress allowlist when it declares allowed domains — and non-preinstalled runtime-fetch servers are refused.

• ·MCP servers no longer use an open default network path — networking is default-deny
• ·Community MCPs must be pinned, preinstalled, and sealed, or they are refused (floating `npx`/`uvx`/`latest`/git/url runtime fetches are rejected)
• ·Network access is granted only through a declared `mcp_allowed_domains` sealed egress allowlist; otherwise the container runs with no network
• ·Credentialed MCP launches use default-deny networking plus sealed egress allowlists; cleanup and secret hygiene are enforced across launch, timeout, and failure paths

Behavioral change: Community MCP servers that ship only an mcp_command (floating npx/uvx runtime fetch) are now refused. Pin an exact mcp_install so the server is preinstalled into a sealed volume, and declare mcp_allowed_domains for any runtime egress; without declared domains the server runs with no network. Credentialed and curated/trusted host flows are unchanged.

The auth CLI and setup wizard now surface every LLM provider from the registry — OpenAI, Anthropic, OpenRouter, DeepSeek, Mistral, Qwen, Gemini, and keyless local Ollama — with one source of truth and no hardcoded provider lists.

• ·`agentnode auth status` lists all registry providers with storage backend and effective source; Ollama shows as a local keyless provider
• ·`agentnode auth test` validates any compatible provider via a free no-completion probe; `auth test ollama` is a reachability check that never starts Ollama
• ·Setup wizard offers all providers in a grouped menu (Recommended / More / Local); selecting Ollama never asks for an API key
• ·Custom endpoints configured under `llm.providers.<name>` appear in status and test automatically

The LLM runtime can bind any endpoint that speaks the OpenAI-compatible protocol. Built-in presets cover OpenRouter, DeepSeek, Mistral, Qwen, Gemini, and Ollama — the first key-free, cost-free local agent path.

• ·Custom endpoints are plain config entries (`llm.providers.<name>` with base_url and model) — no code change per provider
• ·Ollama as an opt-in keyless local provider: no account, no per-token cost, never bound by surprise
• ·Per-provider credentials via environment variable or stored vault key; environment always wins
• ·Sandboxed agents inherit every provider automatically — keys stay host-side, the container only sees RPC completions

`agentnode setup` now walks through optional LLM credentials and local-sandbox readiness — store a key in the OS keychain, diagnose Docker/image state, and optionally pull the pinned sandbox image, all in one guided flow.

• ·Credential screen with hidden input or env import, honest storage label, and an optional free key test
• ·Sandbox screen shows the doctor's diagnosis and offers the digest-pinned image pull (TTY-only, explicit Yes)
• ·Optional 'enable sandboxed community agents' prompt — only offered when the sandbox is fully ready, default No
• ·No keys in output or config files; pull failures never abort setup

API keys now live in the OS keychain (Windows Credential Manager, macOS Keychain, Linux Secret Service) instead of plaintext files, and the LLM runtime finally reads stored credentials — including the sandboxed-agent broker, where keys never enter the container.

• ·`agentnode auth set <provider>` stores keys in the OS keychain, with an honest plaintext-file (0600) fallback when no keychain exists
• ·`agentnode auth test <provider>` validates the effective key via a free endpoint — no completion call, no cost
• ·`auth status` shows the effective source per provider, including when an environment variable shadows a stored key
• ·Keys are never printed, logged, echoed from provider responses, or sent into the sandbox container

Fixes the config loader silently stripping a hand-written agent_sandbox section, so the documented `agent_sandbox.enabled` config path and the host LLM ceiling now actually take effect.

• ·`agentnode config set agent_sandbox.enabled true|false` works and stores a real boolean
• ·The nested `agent_sandbox.llm` host ceiling survives config loading

Community agents can now run sandbox-or-fail-closed in the pinned container image — never on the host — with a host-side LLM broker, default-deny credential policy, per-run caps, and a sanitized audit record. Default OFF; opt in via AGENTNODE_AGENT_SANDBOX=1.

• ·Verified/unverified agents run in the sandbox or not at all — no host fallback anywhere on the path
• ·Host-side LLM broker: provider API keys never enter the container (container env is PYTHONPATH only)
• ·`llm_access` manifest block is default-deny, with max_calls / max_input_chars / max_output_chars caps and an optional model allowlist; the host ceiling always wins
• ·Every sandboxed run writes one aggregated, sanitized audit record — never prompts, keys, or raw provider errors

`agentnode publish` now asks for confirmation before uploading; non-interactive publishes require an explicit `--yes`.

• ·Interactive prompt (default No) prevents accidental publishes; `--yes` for CI

Behavioral change: Non-interactive publish without --yes now refuses instead of uploading silently.

Clearer `agentnode run` errors for multi-tool packs (lists available tools and the slug:tool syntax) and a stale lock-integrity test fix.

• ·Multi-tool packs without an explicit tool name get an actionable error instead of a generic import failure

`agentnode run <slug>` auto-selects a single-tool pack's tool, and the `slug:tool` form resolves the real package trust level and lockfile entry.

• ·Single-tool packs run without naming the tool; multi-tool packs are never guessed
• ·`slug:tool` no longer downgrades the package to unverified — the sandbox/trust gate keys on the real slug

Installs now target the running Python interpreter (fixes pipx and unactivated-venv setups), and the agent trust gate is locked by a named regression test.

• ·`installer.resolve_python()` returns sys.executable first — install and run use the same Python
• ·Agent execution-vector invariant documented and regression-tested

The execution plane is now sandboxed: community and unverified code — toolpack builds, toolpack runs, MCP servers — runs inside a hardened, digest-pinned container or not at all. There is no host fallback.

• ·Hardened container execution: read-only, cap-drop ALL, non-root, network none by default, no host mounts, no secrets
• ·Digest-pinned runner image, acquired explicitly via `agentnode sandbox pull` — never a tag, never auto-pulled
• ·`agentnode sandbox` CLI: pull, doctor (diagnose readiness per package), status
• ·Real network-permission enforcement for toolpack runs: allowlist, unknown = deny

Behavioral change: Behavioral change vs 0.5.x: community code requires a container runtime plus the pinned sandbox image; without them execution is blocked (sandbox_unavailable). Curated/trusted packages run on the host as before.

PyPI jumps 0.5.1 → 0.11.0. The 0.5.2–0.10.1 changes below were tagged in git but not published to PyPI.

The async client verifies registry response signatures on trust-critical endpoints, matching the sync clients.

• ·Signature verification parity across AgentNodeClient, AgentNode, and AsyncAgentNode

Tagged in git; first published to PyPI as part of 0.11.0.

Trust-critical registry responses are cryptographically verified against pinned Ed25519 keys — a compromised registry or a MitM with a valid TLS cert can no longer serve an attacker's public key.

• ·Ed25519 signature verification of registry responses (X-AgentNode-Signature header), exact-byte, no canonicalization
• ·Compile-time pinned trust anchors — no env override, no config file, no network fetch
• ·Differentiated error codes for stripped headers (downgrade), bad signatures (tampering), and unknown/expired keys

Tagged in git; first published to PyPI as part of 0.11.0.

Completes the publisher trust chain: install-time revocation checks against the registry, `agentnode lock verify --online`, and integrity-protected publisher identity in the lockfile.

• ·Install blocks packages whose publisher key the registry reports as revoked
• ·`lock verify --online` reports active/revoked/unknown/mismatch per signed package, fail-closed
• ·publisher_slug stored write-once in the lockfile and covered by the integrity hash

Tagged in git; first published to PyPI as part of 0.11.0.

Cryptographic proof of package origin: publishers sign packages with Ed25519 keys at publish time, installs verify before writing the lockfile, and an invalid signature is a hard block with no override.

• ·Deterministic Ed25519 signatures over the canonical package payload, created automatically by `agentnode publish`
• ·Install verification against the cached public key; invalid signatures block before any lockfile write
• ·Missing signatures warn but never block — publisher adoption is gradual, but never silent
• ·`lock verify` and `inspect` show signature status per package

Tagged in git; first published to PyPI as part of 0.11.0.

Every security-critical lockfile field is covered by a per-entry SHA-256 hash — post-install tampering is detected before any code executes, warned by default and denied in strict mode.

• ·`agentnode lock seal` / `lock verify` CLI plus automatic sealing at install time
• ·Runtime integrity check before policy checks; strict mode denies tampered entries
• ·Sensitive-change detection flags runtime swaps, entrypoint changes, endpoint redirects, and permission escalation

Tagged in git; first published to PyPI as part of 0.11.0.

Credentials for remote/connector tools are domain-bound and HTTPS-only before any request leaves the process.

• ·HTTPS-only credential enforcement; empty domain binding is a hard deny
• ·Advisory method/action-type and payload-size checks with safe-metadata audit fields

Tagged in git; first published to PyPI as part of 0.11.0.

Unified dispatch-level audit events for all runtimes, and path-traversal/URL-anomaly findings escalate from warning to prompt (interactive) or deny (non-interactive).

• ·runtime_run and mcp_run audit events with no kwargs or result data
• ·Input guard fail-closed when no human is present to confirm

Tagged in git; first published to PyPI as part of 0.11.0.

AgentNode Guard classifies every tool invocation by action type (read, write, delete, execute, credential use, network egress, …) and applies configurable allow/prompt/deny policy — before any code runs.

• ·9 action types with safe defaults, strict mode for production/CI, and per-tool overrides
• ·Composite risk scoring; critical risk is always denied, unoverridable
• ·`agentnode guard` CLI: status, set, unset, check (dry-run), reset
• ·Rate limiting, MCP argument inspection, install-time risk preview, and full audit integration

Tagged in git; first published to PyPI as part of 0.11.0.

Computed risk flags (like external_write_capable) get user-configurable reactions: allow, log, prompt, or deny — default stays audit-only.

• ·`risk_policies` config section evaluated between the permission check and execution

Tagged in git; first published to PyPI as part of 0.11.0.

Per-package usage risk scoring, separate from the verification score: static signals (permissions, trust, credentials) plus runtime signals produce a 0–100 score with semantic risk flags.

• ·`get_risk_profile(slug)` API and Usage Risk section in `agentnode inspect`

Untagged development release; first published to PyPI as part of 0.11.0.

Visibility hardening: `agentnode inspect`, input guard warnings, plan-level risk warnings, LLM tool-output marking, and an agent auto-install guard — all informational, nothing blocking.

• ·`agentnode inspect <slug>` — security-focused report for installed packages
• ·Untrusted tool output is truncated and delimiter-wrapped before reaching the LLM

Multi-step planner with policy-checked piping, a typed capability graph powering gap detection and recommendations, credential/audit/logs CLI, and a broad security hardening pass (trust TTL refresh, atomic writes, file locking).

• ·`agentnode run "extract from report.pdf then translate to german"` — multi-step execution with full policy and audit per step
• ·Capability graph with typed edges; doctor and recommend rewritten on top of it
• ·`agentnode auth`, `agentnode audit`, `agentnode logs`, `--json`/`--explain`/`--dry-run` across the CLI
• ·Trust TTL refresh, atomic config/lockfile/credential writes, cross-platform file locking

run_tool(mode="auto") now always executes via subprocess isolation regardless of trust level, making the documented isolation guarantee true by default — plus async-client URL and install-tracking fixes.

• ·Subprocess isolation by default; mode="direct" remains an explicit opt-in
• ·500 MB download ceiling with per-chunk enforcement

Behavioral change: Tools relying on shared in-process state must pass mode="direct" explicitly.