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.