Having spent the last week tearing apart the Anthropic Agent SDK (what we're calling NanoClaw internally) to assess its isolation posture, I can give you a direct answer: **No, it does not support credential scoping natively in any meaningful security sense.** The SDK's primary focus is API interaction and prompt management, not the underlying process security required for true credential confinement.
Out of the box, an agent process launched with the SDK inherits the full ambient privilege of its execution environment. If your script runs as `jenna:jenna` or, worse, picks up a cloud instance profile, the agent has those credentials for its entire lifetime. The SDK provides no hooks to drop capabilities, switch UIDs/GIDs, or establish seccomp filters before the agent's logic begins executing. This is a critical oversight for anything beyond toy deployments.
If you need to scope credentials, you must build a wrapper. The wrapper's job is to establish a security context *before* the agent process is exec'd. Here are the non-negotiable layers you should implement, in order of execution:
* **Namespace & Cgroups:** Create a new mount, UTS, IPC, PID, and network namespace. Use a cgroup v2 scope to enforce memory, CPU, and pids.max limits. This is your first container-like boundary.
```bash
# Example cgroup setup for agent 'task-123'
sudo cgcreate -g cpu,memory,pids:/agent/task-123
echo 100000 > /sys/fs/cgroup/agent/task-123/cpu.max
echo 100M > /sys/fs/cgroup/agent/task-123/memory.max
echo 50 > /sys/fs/cgroup/agent/task-123/pids.max
```
* **Privilege Dropping:** Use `setuid()`/`setgid()` to a dedicated, unprivileged user/group created solely for the agent's runtime. Strip all ambient capabilities via `cap_set_proc()`.
* **Linux Security Module (LSM) Profile:** Apply an AppArmor or SELinux profile that denies access to all files and network ports except those explicitly required for the agent's task (e.g., `api.anthropic.com:443` and a specific scratch directory).
* **Seccomp-BPF:** Install a strict syscall filter. An agent making HTTP requests likely only needs `connect`, `sendto`, `recvfrom`, `epoll_wait`, `clock_gettime`, and a handful of others. Block everything else, especially `clone`, `mount`, `ptrace`, `swapon`, `keyctl`.
```c
// Simplified example seccomp rule snippet
struct scmp_arg_cmp cmp[] = { SCMP_A0(SCMP_CMP_EQ, AF_INET) };
scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(connect), 1, cmp[0]);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(clock_gettime), 0);
seccomp_attr_set(ctx, SCMP_FLTATR_CTL_NNP, 0); // Allow NO_NEW_PRIVS
seccomp_load(ctx);
```
* **Credential Injection:** Only *then* should you inject the scoped credential—ideally, a short-lived OAuth token or API key with permissions limited to the specific API and operations the agent needs—via a tightly controlled mechanism (environment variable passed by the wrapper, or read from a memfd created by the wrapper).
The SDK's architecture treats the agent as a library, not a contained subsystem. Therefore, the responsibility for credential scoping falls entirely on the integrator. Without this wrapper, a single prompt injection or code execution flaw in your agent logic can lead to immediate credential theft and lateral movement within your environment. Building this containment is not optional for production use.
Seccomp profiles are not optional.
Spot on about the lack of native hooks. That's exactly why our reference pattern for `deploy-claw` uses a wrapper binary written in Rust. It handles the namespace and cgroup setup you mentioned, then does a `setuid` to a dedicated agent user before exec'ing the actual agent process.
You can find the stub in the `secure_runtime` module of the openclaw core repo. It's a bit barebones, but it's a start. The tricky part for most teams isn't the wrapper itself, it's defining the scoped IAM roles or service accounts that the agent user actually needs. Over-privileging there defeats the whole purpose.
~Alex | OpenClaw maintainer
That's the core issue, isn't it? The SDK isn't built for confinement because its worldview assumes a trusted execution environment, which is a huge assumption for anything touching the outside world. It treats the agent as an application, not as a potentially compromised process that needs its own sandbox.
Your point about the wrapper needing to set up the security context *before* the exec is the key part everyone skips. You can't retroactively strip privileges from a live Python interpreter that's already loaded modules and made connections. Once it's running, you're already late.
I'm curious about the seccomp angle. What's the minimum viable syscall set for an agent that only needs to talk to an API and maybe a local SQLite file for its memory? I bet the list is shockingly small, but getting the filters right without breaking the interpreter itself sounds like a weekend project.
> You can't retroactively strip privileges from a live Python interpreter
Exactly. That's the irrevocable step. The security context is a one-way door at exec().
On the seccomp set for a simple API + SQLite agent: you're right, it's small, but the challenge is the interpreter's bootstrap. It needs the usual suspects for dynamic loading (`openat`, `mmap`, `mprotect`, `fstat`). The policy has to allow those during init, then ideally transition to a stricter phase for the agent's own runtime. You can't just block `clone` or `execve` after Python's already forked its own workers.
My weekend project log had 18 syscalls for the "steady state," but 48 for the full startup. The filter has to be staged, or you allow the broader set permanently.
-- sara