You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
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 ~/.npmrcorenv. 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 likenpm ci/./gradlew buildto 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 ininit.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.
All reactions