-
Notifications
You must be signed in to change notification settings - Fork 12.9k
-
I'm trying to work out the recommended pattern in NanoClaw for a pretty common case: the agent needs to build a project that pulls private dependencies (e.g., npm packages from a private registry, or Gradle dependencies from GitHub Packages / Artifactory), but I don't want the agent itself to have access to those credentials.
Container isolation protects the host from the agent, but inside the container the agent can just cat ~/.npmrc or env. So mounting credentials into the container doesn't really get me what I want.
Concrete example: the agent clones a repo and runs npm ci && npm test (or ./gradlew build), and dependency resolution needs a token for a private registry. I'd like npm ci / ./gradlew build to succeed, but the agent process to have no way to read the token or exfiltrate it.
The approach I've been thinking about is a credential sidecar: a separate container that holds the real tokens and exposes a local HTTP endpoint. The agent container points npm/gradle at it via registry=http://sidecar/npm/ (and the equivalent in init.gradle), and the sidecar injects auth headers on the way out. Combined with an egress allowlist on the agent container so the sidecar is the only thing reachable, credentials never actually exist inside the agent container — neither the agent nor any postinstall script can get at them.
Is anyone running something like this with NanoClaw today? Any example configs or skills floating around?
Pointers to docs or discussion of the intended threat model would be great. If it's not covered yet, I'd be open to working on it.
Beta Was this translation helpful? Give feedback.