NanoClaw Now Uses Agent Vault as Its Default Credential Layer

I want to share something that happened this week: NanoClaw, one of the most widely-used open-source agent frameworks (25k+ stars on GitHub), adopted OneCLI Agent Vault as their default credential layer. Gavriel Cohen and his team wrote about their reasoning on their blog, and I want to add our perspective on what this means and why it matters.

The problem we keep seeing

There is a story that has been circulating in AI safety circles. A director of AI alignment at Meta gave an OpenClaw agent access to her email. She explicitly told it not to take action without her approval. The agent mass-deleted emails anyway. She had to physically run to her computer to stop it.

This is not an edge case. It is the default behavior of most agent-credential setups today. You hand an agent an API key, the agent has full access, and your only protection is the system prompt, which is not a reliable enforcement mechanism.

The question I kept coming back to when building Agent Vault was simple: what if the damage in that scenario had been three emails instead of an entire inbox?

What Agent Vault actually does

Agent Vault sits between the agent and external services (Gmail, Slack, GitHub, whatever the agent needs to talk to). It proxies requests and injects real credentials at the network layer. The agent never sees or holds raw API keys.

This is not a novel idea. Credential proxies exist in plenty of infrastructure tooling. What makes the agent context different is that you need a policy layer on top. An agent is not a microservice with a predictable call pattern. It makes decisions, and sometimes those decisions are wrong.

Today, that policy layer includes rate limiting. Here is what it looks like in practice:

# Rate-limit Gmail API calls to 3 per hour
onecli rules create \
  --name "Gmail rate limit" \
  --host-pattern "gmail.googleapis.com" \
  --action rate_limit \
  --rate-limit 3 \
  --rate-window 1h

# Rate-limit Gmail API calls to 3 per hour
onecli rules create \
  --name "Gmail rate limit" \
  --host-pattern "gmail.googleapis.com" \
  --action rate_limit \
  --rate-limit 3 \
  --rate-window 1h

That is the difference between "the agent deleted my entire inbox" and "the agent deleted three emails before the vault cut it off." Not perfect. But a fundamentally different failure mode.

Time-bound access and human-in-the-loop approvals are coming next. Rate limiting is the foundation because it is the simplest policy that still changes outcomes.

What NanoClaw gets

NanoClaw is a framework for running groups of cooperating agents. Each group can now get its own vault identity with its own rules. This matters because different agent groups have different risk profiles. A group of agents doing research and summarization needs different credential policies than a group that is sending emails and managing calendars on behalf of a user.

With the integration, NanoClaw users get:

• Credential isolation by default. Agents request access through the vault. They never touch raw keys.
• Per-group policy. Each NanoClaw agent group gets its own vault identity. You set rules per identity, not globally.
• Rate limiting out of the box. One command to cap how many times any agent group can hit a given API in a given window.
• An upgrade path. When we ship time-bound access and approval workflows, NanoClaw users get them automatically.

Gavriel and his team wrote about their decision-making process in detail: nanoclaw.dev/blog/nanoclaw-agent-vault. I recommend reading it. They were honest about what they evaluated and why they chose this approach.

What this is not

I wrote a post on this blog a while back, "What a Credential Vault Can and Can't Do for AI Agent Security", and everything in it still holds. A credential vault does not solve alignment. It does not prevent an agent from making bad decisions. It limits the blast radius when those bad decisions involve external services.

That is a narrower claim than most security tooling makes. I think it is the honest one.

What is next

On our side:

• Time-bound access: credentials that expire after a window, so agents cannot hold persistent access to services they only need briefly.
• Approval workflows: for high-risk actions, the vault pauses the request and asks a human before injecting credentials.
• Audit logging improvements: better visibility into what agents are actually doing with their access.

On NanoClaw's side, they are building deeper integration into their agent group lifecycle. Their blog post covers the roadmap.

Try it

Agent Vault is open source. You can look at the code, run it locally, and decide for yourself whether the approach makes sense.

• OneCLI: github.com/onecli/onecli
• NanoClaw: github.com/qwibitai/nanoclaw
• NanoClaw's post: nanoclaw.dev/blog/nanoclaw-agent-vault

If you are building an agent framework and thinking about how to handle credentials, I would like to hear from you. The problem space is bigger than any one tool.