Skip to main content

​
Restart your agent without losing who it is

Picture this. Your agent is running in Kubernetes. A pod crashes and restarts. The new pod comes up — but with a brand new DID and fresh OAuth credentials. Any app that remembered the old credentials? Broken. And Hydra slowly fills up with orphaned clients that no one is using. This release fixes that. Your agent can now save its identity (DID keys + Hydra credentials) in HashiCorp Vault — a safe place for secrets. When it restarts, it picks up the same identity and keeps going. From the outside, nothing changed.

​
One thing to know first

DID keys don’t regenerate on every restart anymore. The recreate_keys setting now defaults to False, which means your agent keeps its existing keys. This is almost always what you want. If you actually need fresh keys each time, set recreate_keys=True.

​
What’s new

​
Agent identity that survives restarts

A new VaultClient stores and fetches your agent’s DID keys and Hydra credentials in Vault. When your agent starts up, it follows a simple priority order:
  1. Check Vault first. If credentials are there, use them.
  2. Fall back to the local filesystem. Maybe Vault is offline — that’s fine.
  3. Last resort: generate new ones. And then immediately save them to Vault so the next restart finds them.
It reuses the HTTP client Bindu already uses (no extra connections) and cleans up properly when it’s done (no memory leaks).

​
Agent IDs that are predictable

Your agent ID is now generated from SHA256(author:agent_name). That sounds fancy, but the idea is simple: same author + same agent name = same ID, every time, forever. This means you don’t have to hardcode an ID anywhere. Bindu figures it out from details you’ve already provided.

​
What ends up in Vault

vault/secret/bindu/
├── agents/{agent_id}/did-keys
│   ├── private_key (PEM)
│   ├── public_key (PEM)
│   └── did
└── hydra/credentials/{did}/
    ├── client_id
    ├── client_secret
    ├── agent_id
    ├── created_at
    └── scopes
Two folders: one for the DID identity (who the agent is), one for the Hydra login (how it proves it).

​
How to turn it on

Set three environment variables: 
VAULT__ENABLED=true
VAULT__URL=http://vault:8200
VAULT__TOKEN=hvs.CAESIJ...
The standard VAULT_ADDR and VAULT_TOKEN names work too, if you’ve already got those set up. On Kubernetes, pull the token from a Secret: 
env:
- name: VAULT__ENABLED
  value: "true"
- name: VAULT__URL
  value: "http://vault.vault.svc.cluster.local:8200"
- name: VAULT__TOKEN
  valueFrom:
    secretKeyRef:
      name: bindu-vault-token
      key: token

​
What got better

The startup flow is now: check Vault → check local files → generate new. If Vault is down, the agent doesn’t crash — it just uses local files or makes fresh keys, like before. Inside the code, agent IDs are handled as proper UUIDs where the type matters, and as strings where humans will read them. A few unused dependencies (agno, openai, ddgs) got removed from pyproject.toml.

​
Migration

1

Turn Vault on

VAULT__ENABLED=true
VAULT__URL=http://vault:8200
VAULT__TOKEN=hvs.CAESIJ...
2

Restart your agent

The first time it starts up with Vault enabled, your existing keys get backed up automatically.
3

Peek inside Vault to confirm

vault kv get secret/bindu/agents/{agent_id}/did-keys
4

Test a pod restart

Delete a pod and watch the replacement come up with the same DID. That’s the whole point.
For production: don’t rely on a hardcoded Vault token. Use Kubernetes auth (Vault can accept a pod’s service account as proof of identity). Rotate tokens often, turn on audit logging, and always talk to Vault over TLS.