> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getbindu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# v2026.9.4

> Your agent keeps its identity, even after a restart

## 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](https://www.vaultproject.io) — 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

<Warning>
  **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`.
</Warning>

***

## 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:

```bash theme={null}
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:

```yaml theme={null}
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

<Steps>
  <Step title="Turn Vault on">
    ```bash theme={null}
    VAULT__ENABLED=true
    VAULT__URL=http://vault:8200
    VAULT__TOKEN=hvs.CAESIJ...
    ```
  </Step>

  <Step title="Restart your agent">
    The first time it starts up with Vault enabled, your existing keys get backed up automatically.
  </Step>

  <Step title="Peek inside Vault to confirm">
    ```bash theme={null}
    vault kv get secret/bindu/agents/{agent_id}/did-keys
    ```
  </Step>

  <Step title="Test a pod restart">
    Delete a pod and watch the replacement come up with the same DID. That's the whole point.
  </Step>
</Steps>

<Warning>
  **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.
</Warning>