secret-hygiene

Store raw secrets in the encrypted SQLite-backed CTOX secret store and replace literals with stable references.

2|Updated Apr 12, 2026
One-click install
npx skills add https://github.com/metric-space-ai/ctox --skill secret-hygiene
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: secret-hygiene
Source: https://github.com/metric-space-ai/ctox/tree/main/skills/system/security_access/secret-hygiene
Command: npx skills add https://github.com/metric-space-ai/ctox --skill secret-hygiene

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Only the encrypted SQLite-backed secret store and related runtime records count as durable secret knowledge. Workspace notes or copied values do not count as durable knowledge by themselves.

Use this skill whenever a raw secret appears in active CTOX context.

This skill does not decide by kernel heuristic that some string is a secret. The skill makes that judgment from context, then uses explicit kernel primitives to protect the value.

Core Rules

  • Do not leave raw secrets in ordinary follow-up messages, ticket notes, or knowledge entries.
  • Store the value in the encrypted CTOX secret store.
  • Rewrite conversation memory to a stable reference handle when the raw literal already entered LCM/continuity.
  • Keep the replacement handle human-readable enough for operators to understand what happened.

Primary Command

Prefer the one-step intake path:

ctox secret intake --scope "<scope>" --name "<name>" --value "<secret>" --description "<text>" --metadata-json '<json>' --db "<path-to-ctox.sqlite3>" --conversation-id "<id>" --match-text "<secret>" [--label "<human label>"]

This stores the secret in the encrypted SQLite secret store and rewrites the specified conversation memory to [secret-ref:<scope>/<name>].

Fallback Commands

If the secret is already stored, rewrite memory only:

ctox secret memory-rewrite --db "<path-to-ctox.sqlite3>" --conversation-id "<id>" --scope "<scope>" --name "<name>" --match-text "<secret>" [--label "<human label>"]

If the secret was supplied outside the current conversation and no rewrite is needed:

ctox secret put --scope "<scope>" --name "<name>" --value "<secret>" --description "<text>" --metadata-json '<json>'

Operating Pattern

  1. Decide whether the pasted value is actually a secret that needs protection.
  2. Choose a stable scope and name.
  3. Store it through ctox secret intake when the current conversation already contains the literal.
  4. Confirm that future work refers only to the secret handle.
  5. Use ctox secret get only for bounded local execution steps that truly require the raw value.

Boundaries

  • Do not invent fake secret rotations or claim revocation if none happened.
  • Do not silently rewrite unrelated text.
  • Do not expose the raw secret again after the rewrite step.

Quick Start

Store the detected secret in the encrypted secret store using the intake flow and replace the memory with a stable secret handle.

Frequently Asked Questions about secret-hygiene

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I securely store secrets and replace raw credentials with references in conversation memory?

To securely store secrets, use an encrypted SQLite-backed secret store to intake the raw value and rewrite conversation memory, replacing the literal with a stable human-readable handle like [secret-ref:<scope>/<name>].

What happens if a raw password or private key is already stored in the encrypted secret store but remains in chat history?

If the secret is already stored, run a memory-rewrite command to replace the raw literal in the existing conversation memory with a stable secret reference handle without re-intaking the value.

When should I use an encrypted secret store to handle tokens in CTOX contexts?

You should use an encrypted secret store whenever raw credentials, tokens, passwords, or private keys appear in active CTOX contexts across TUI, mail, chat, or tickets and require intake, memory rewrite, or reference replacement.

Can I retrieve a raw secret from the encrypted store for local execution after replacing it with a reference?

Yes, you can use a secret get command to retrieve the raw value from the encrypted SQLite store, but only for bounded local execution steps that truly require the raw secret.

What are the limitations when rewriting conversation memory to protect pasted secrets?

You must not silently rewrite unrelated text, invent fake secret rotations, or expose the raw secret again in follow-up messages or ticket notes after the memory rewrite step is complete.

Does the secret intake process automatically detect sensitive values like private keys?

No, the skill does not use kernel heuristics to detect strings as secrets; it makes the judgment from context, then uses explicit kernel primitives to protect the value in the encrypted store.