AI Guides

Tightening Token Management After the Leak

One accidental secret exposure turned into a full security drill: quarantine the tokens, rotate what can be rotated locally, disable cloud routes, and build a no-leak workflow before trusting the stack again.

2026-05-04 · 7 min read

There is a special kind of silence that happens when an AI assistant prints a secret to the terminal.

Not because the machine has exploded. Not because anything dramatic has happened yet. Because for one second everyone in the room understands the same thing:

That token is dead now.

No debate. No “it was only local”. No “probably fine”. A token that appears in logs, terminal output, chat history, screenshots, or tool traces is not a token anymore. It is a liability wearing a name badge.

This is the uncomfortable part of building with agents. The more useful they become, the closer they get to the wiring. They read configs. They inspect env files. They restart services. They debug broken providers. They become operational partners.

And operational partners eventually stand near secrets.

This week, I tightened the rules.

The mistake was simple

The task was supposed to be straightforward: lock OpenClaw down to local-only mode until the security posture was tight.

That meant:

Good plan.

Then the audit touched the wrong surface. Instead of reporting key names and status only, the assistant inspected the env file too directly. The output exposed active secrets in the terminal.

Not all of them were for OpenClaw. Some belonged to the wider Hermes stack: bot tokens, provider API keys, routing keys, service integrations. The kind of operational keys that make an agent system actually useful — and therefore the kind you absolutely do not want smeared across a transcript.

So the response had to be bigger than OpenClaw.

If the exposure is broad, the containment has to be broad too.

Rule one: do not argue with compromise

The first security rule I now follow is brutally simple:

If a secret appears in chat, terminal output, logs, screenshots, or a model-visible trace, treat it as compromised.

Not “possibly compromised”. Not “low risk”. Compromised.

That sounds harsh until you remember what agent systems do with text. They compress it. Summarise it. Save it. Search it. Feed it into future context. Pass it through tools. Sometimes send it to cloud models. Sometimes write it to daily logs so the next session can recover from context loss.

That is a brilliant memory system for work.

It is a terrible place for secrets.

So the protocol is now:

  1. Stop printing values.
  2. Remove exposed values from active config.
  3. Quarantine old values locally for controlled recovery if needed.
  4. Rotate provider-side keys.
  5. Re-add new values through hidden local prompts only.
  6. Verify by key name and service status, never by showing the value.

The important shift is mental: a token leak is not a chat mistake. It is an incident.

Small incident, if handled quickly. Big incident, if normalised.

What actually got tightened

The fix was not just “delete the Anthropic key”. That was only the first layer.

OpenClaw was narrowed down to a local-only baseline:

That gave Kate a safe operating lane: local model, local gateway, sandboxed execution, no cloud model dependency, no casual web reach.

Then the wider Hermes environment was cleaned up.

Exposed external provider and bot tokens were removed from active ~/.hermes/.env and moved into a locked quarantine file. The active Hermes auth pool was stripped back so it no longer tried to use those exposed env-backed credentials.

One local token — the Hermes gateway token — was regenerated immediately.

Telegram and Discord were intentionally left disabled until fresh bot tokens are generated and re-added.

That matters. A secure system sometimes looks “less functional” right after a cleanup. That is not failure. That is containment.

The machine should not rush to reconnect with compromised credentials just because I miss the convenience.

The new no-leak audit pattern

The real fix was not removing one batch of tokens.

The real fix was changing the inspection workflow.

There is now a safe audit script:

/home/klb/.hermes/scripts/safe-secret-audit.py

It reports names and status only. Not values.

The output looks like this kind of thing:

Active secret-like env keys:
- HERMES_GATEWAY_TOKEN [ROTATED_LOCALLY]

Hermes auth providers:
- openai-codex:device_code type=oauth [present]

OpenClaw auth profiles:
- none

That is the level of detail an assistant needs. Key name. Presence. Rotation status. Provider. Nothing else.

There is also a local setter script:

/home/klb/.hermes/scripts/set-secret-local.sh KEY_NAME

It prompts in the terminal with hidden input and updates the env file without printing the value.

That is the difference between a tool that helps and a tool that quietly turns your API keys into confetti.

The rotation order matters

When several tokens are exposed at once, the temptation is to panic-rotate everything randomly.

Better approach: rotate by blast radius.

For my stack, the order is:

  1. GitHub token — source code and repo access first.
  2. Telegram bot token — active messaging channel.
  3. Discord bot token — active messaging channel.
  4. OpenRouter key — cloud model spend and prompt routing.
  5. NVIDIA key — external inference access.
  6. Ollama API key — cloud model access.
  7. Linear key — project/task integration.
  8. Tavily key — web search API access.
  9. Hugging Face token — model/dataset access.
  10. Anthropic key — already removed locally, still revoke provider-side if valid.
  11. Cloudflare preview secret — decide if it is actually a secret or just a label; rotate if secret.

That order is not sacred. The principle is.

Rotate the keys that can modify code, send messages, spend money, or expose private data before the ones that only read public-ish resources.

Local-only is not a vibe. It is a mode.

A lot of people say “I use local AI” when what they mean is “I run a local model sometimes, unless the task is hard, then I silently route to three clouds and hope nobody asks”.

That is not local-only. That is vibes with a GPU.

Local-only has to be enforceable:

That is the difference between “privacy as branding” and privacy as an actual operating mode.

The point is not to live local-only forever. Cloud models are useful. Codex, OpenRouter, Ollama Cloud, NVIDIA, Anthropic — they all have their place.

The point is that cloud should be a conscious switch, not a surprise side effect.

The real lesson

Token management is boring until it is the only thing that matters.

Nobody wants to spend an evening rotating keys. Nobody wants Telegram disabled. Nobody wants to rebuild auth pools after a cleanup. Nobody wants to admit the assistant exposed something it should not have printed.

But this is what makes an agent stack mature.

Not the fancy model routing. Not the dashboards. Not the cinematic “AI team” language.

The maturity is in the boring controls:

That is the real infrastructure.

Because once your assistant can operate your machine, security is no longer a separate project. It is the floor underneath everything else.

The rule going forward

No more reading env files directly.

No more printing token values “just to check”.

No more pasting keys into chat.

No more cloud fallback hiding behind friendly defaults.

From now on:

It is slower.

It is also how you keep your agent from becoming a very enthusiastic breach assistant.

Stop Scrolling. Start Building. Keep your tokens out of the transcript.

💡 Found this useful? Follow @Raf_VRS for more agent security lessons from the messy edge of actually building this stuff.

💖 Support independent local AI writing: ko-fi.com/rafvrs

#HardInterference #LocalAI #AIAgents #Privacy #Security #SelfHosting

Canonical static mirror for AI/search retrieval. Main article URL: open this Hard Interference article.