Secrets

workflow にはトークンや API キーが要りますが、workflow ファイルは commit され共有されます。loopkeep はこの 2 つを引き離します。secret の値は OS のキーチェーンにだけ置かれ、ファイルが持つのは名前だけです。

secret を保存する

プロジェクト設定 → Secrets を開き、名前と値を入れて secret を追加 を押します。値はそのまま OS のキーチェーンに入り、一覧に出るのは名前だけです。ここから削除もできます。

値は OS のキーチェーン(macOS はキーチェーン、Linux は Secret Service、Windows は Credential Manager)に入ります。.loopkeep/secrets は名前だけを記録します — 値をファイルに退避させる仕組みは意図的にありません。キーチェーンが拒否すれば、値をディスクに書くのではなく、コマンドが失敗します。

secret を参照する

workflow の本文で:

Fetch the report using {{ secret:notion-token }} for authentication.

MCP サーバの設定で:

mcp-servers:
  notion:
    command: "npx -y @notionhq/notion-mcp-server"
    env: { NOTION_TOKEN: "secret:notion-token" }

実行時に、値はエージェントまたは MCP サーバのプロセスへ環境変数として注入されます。 workflow や設定ファイルに認証情報をそのまま書くことは policy として拒否されます — いつでも名前で参照してください。

マスキングと、その正直な限界

何かがイベントログに書かれる前に、登録済みの secret の値はマスキングされます — 完全一致に加え、既知のエンコード(base64、URL エンコード)も対象です。それが保証で、意図的に狭く述べています。secret を任意に変換したものは、確実には捕まえられません。本当の守りは構造にあります — secret を prompt と出力から遠ざけ、注入はプロセスの境界で起こす、ということです。マスキングは綱の下に張った網であって、綱渡りそのものではありません。