セキュリティとプライバシー
このページにはあなたができることだけを書きます:トラフィックの行き先を知る、認証情報を正しい場所に置く、データがどこに残るかを知る、ローテーションできるようになる。tansr 内部の防御線(権限エンジン、保護パス、ハードなセキュリティレッドライン、監査チェーン)は各形態のガイドですでに展開されており、ここではあなたの操作に関係する場合にだけ参照します。
外向き通信:トラフィックはどこへ行き、どう絞るか
Section titled “外向き通信:トラフィックはどこへ行き、どう絞るか”CLI は何に接続するか
Section titled “CLI は何に接続するか”| 宛先 | いつ | 無効化できるか |
|---|---|---|
tansr プラットフォームゲートウェイ api.tansr.com |
プラットフォームモードにログイン後:モデル呼び出し、設定バンドルの取得、ハートビート、使用量の報告、残高 | TANSR_ESCAPE_LOCAL=1 を設定して完全ローカルモードに入れば全体を停止 |
公式配布サイト bash.tansr.com |
あなたが明示的に /update または tansr update を実行したときだけ。起動時に自動チェックは行わない |
TANSR_UPDATE_CHANNEL=none または TANSR_NO_UPDATE_CHECK=1。企業はセルフホストのマニフェスト TANSR_UPDATE_MANIFEST_URL を指定可能 |
| あなたが設定したモデルプロバイダー | 完全ローカルモードでの providers.*.baseUrl |
あなたが決める |
| あなたが設定した MCP サーバー / 自前の検索・メディアエンドポイント | セッション内のツール呼び出し | あなたが決める。プロジェクト層の MCP サーバーは明示的に信頼を付与する必要がある |
| モデルがツール経由でアクセスする任意の URL(WebFetch / Http) | セッション内 | 権限ルールの制約を受ける。deny ルールでツール全体を無効化できる |
無人運転のデプロイ(tansr serve / headless で auto に権限を開放)の推奨ベースラインはネットワーク出口の許可リストです:モデル API などの必要な宛先だけを許可し、DNS と確立済み接続以外はデフォルトで拒否します。コンテナや最小権限の専用ユーザーと組み合わせ、ファイルシステムの書き込み面は作業ディレクトリに限定します。参考テンプレートはリポジトリ内の deploy/serve/ にあります。
すでに存在する、ユーザーに見える 2 つの防御線:同じ 1 つのコマンドで秘密ファイル(.env、キー、.aws/credentials)を参照しつつ外部送信の動作(curl / scp / git push …)を伴うものは常に拒否され、どのモードやルールでも覆せません。セッションが一度秘密ファイルを読むと、その後の外部送信の動作はすべて確認に変わります(セッション汚染)。tansr CLI 0.5.0 で近日提供予定:すべての外向き通信(WebFetch / Http / hooks / 音声ダウンロード)を統一された出口経由に変更し、DNS 解決後にプライベートネットワーク、ループバック、リンクローカルアドレスを判定し、内部ネットワークやメタデータアドレスを指す取得は理由を示して拒否します。Http ツールと hooks が参照できる認証情報の環境変数は許可リスト http.allowedAuthEnvVars に収束し、リスト外ではリクエストを送信しません。
SDK とセッションサービスは何に接続するか
Section titled “SDK とセッションサービスは何に接続するか”@tansr/sdkのトークン方式は、あなたが渡したbaseUrl(プラットフォームゲートウェイ)と明示的に設定した MCP サーバーにだけ接続します。SDK はユーザーディレクトリをスキャンせず、自前の検索エンドポイントも持ちません。@tansr/serveの上流チェーンはappid/appkey → POST /v1/app-tokens → GET /t1/config + POST /t1/heartbeat → POST /t1/exchangeで、すべてapiBaseUrlを指します。ほかに、あなたが設定したターン終了時の webhook URL(アウトバウンドリクエストには認証情報のヘッダーを一切付けず、真正性は署名で確認)と、任意のコールド層オブジェクトストレージがあります。- モバイル SDK はあなたのセッションサービスの
baseUrlにだけ接続し、プラットフォームに直接接続しません。
認証情報:どこに置き、どこに置かないか
Section titled “認証情報:どこに置き、どこに置かないか”| 認証情報 | 誰を表すか | 正しい場所 | 決して置かない場所 |
|---|---|---|---|
| 個人アクセストークン(PAT) | あなた本人 | コンソールで生成後、tansr init(マスク入力)または CI の TANSR_PAT 環境変数にだけ渡す |
シェル履歴(--pat で直接渡すと痕跡が残る)、スクリプトの平文、リポジトリ |
| このマシンの派生アプリキー | あなたのこのデバイス | tansr init が自動で OS キーチェーン(macOS Keychain / Linux secret-service / Windows DPAPI)に書き込む。使えない場合は 0600 のファイルにフォールバックし明示的に警告 |
あなたが触る必要はない。tansr doctor の認証情報ストレージのセクションで保存先を確認できる |
| モデルプロバイダーの API キー(完全ローカルモード) | あなたのプロバイダーアカウント | 環境変数。設定ファイルには変数名だけを auth.env に書く |
settings.json、エラーメッセージ、/config の出力(これらは値を決して含まない) |
| アプリキー appid / appkey | あなたのアプリ | あなたのサーバー側プロセスの環境変数(Node プロセスまたは @tansr/serve) |
端末デバイス、ログ、エラーレスポンス、リポジトリ(.env は .gitignore に) |
短期 app_user トークン |
あなたのあるエンドユーザー | Electron メインプロセスのメモリ。@tansr/serve プロセスの内部 |
renderer プロセス、永続ストレージ。モバイル側は決して触れない |
| あなた自身のログイン token(モバイル) | あなたのユーザー | authProvider 経由でリクエストごとに提供し、SDK は永続化しない |
SharedPreferences / DataStore / UserDefaults / ログ |
セッションサービス /v1 Bearer(--token / TANSR_SERVE_TOKEN) |
運用者 | 環境変数 | /v2 面とは相互に通用しない。エンドユーザーに再利用しない |
webhook secret |
あなたのプッシュバックエンド | セッションサービスと受信側それぞれの環境変数 | ログ。エンジンは決して出力しない |
繰り返し言う価値のあるレッドラインが 3 つ:appkey は決してあなたのサーバーの外に出さない。app_user トークンは決してセッションサービスの外に出さない。セッション id は認証要素ではない。
CLI にはもう 1 層、あなたのためのマスキング規律があります:レポート、ログ、エクスポートしたトランスクリプトの中のキーは一律 sk-...末尾 4 桁 の形にマスキングされます。tansr sessions export の成果物はそのままチケットに添付できます。
データの保持:どこに、どれだけ、誰が削除するか
Section titled “データの保持:どこに、どれだけ、誰が削除するか”ローカルマシン(CLI)
Section titled “ローカルマシン(CLI)”- セッション、設定キャッシュ、使用量キュー、プロジェクトメモリは
<storageRoot>/(デフォルト~/.tansr。TANSR_STORAGE_ROOTまたは総ルートTANSR_USER_HOMEでリダイレクト可能)に保存されます。プラットフォームにログイン後、新しいデータはアカウントごとに<storageRoot>/identities/<アカウント指紋>/に分離されます。 - セッションごとに 1 ディレクトリ:
journal.jsonl(ハッシュチェーン)、meta.json、attachments/、上限超過の成果物spill/。画像バイトは<storageRoot>/image-cache/<sessionId>/にキャッシュされます。Shell の長い出力は<作業ディレクトリ>/.tansr/shell-output/に、TTS 音声は<作業ディレクトリ>/.tansr/artifacts/<sessionId>/に保存されます。 - 自動削除はされません。 クリーンアップは
tansr sessions pruneで行います(デフォルトは dry-run で一覧を表示するだけ。--applyで初めて削除。保持ポリシー--keep-daysのデフォルト 90 と--keep-lastのデフォルト 500 の和集合。当日のセッションと使用中のセッションは決して削除しない。壊れたディレクトリには--include-brokenが必要)。tansr logoutはアイデンティティストアのデータを削除しません。 - セッション終了時の
metrics.jsonにはカウントと比率だけがあり、パス、コマンド、ルールの原文は含みません。外部テレメトリはデフォルトで無効:現在のバージョンには外部への報告チャネルは一切存在しません。 - プラットフォーム側は端末のセッション内容を保存せず、計量だけを行います。プラットフォームのセッションレジストリには 30 日間の非アクティブリースがあり、期限が来るとアーカイブされます。
セッションサービス(@tansr/serve)
Section titled “セッションサービス(@tansr/serve)”- セッション履歴は、あなたが設定した
storeディレクトリの<dir>/agent-sessions/<endUserKey>/sessions/<sessionId>/に保存されます。endUserKeyはエンドユーザー id のハッシュであり、身元ではありません。コールド層をあなたのオブジェクトストレージにマウントでき、セグメントは平文の JSONL(圧縮)です——暗号化、キー管理、データの所在地、アクセス制御はあなたの責任です(policy.transformフック)。 - メモリ上の短いウィンドウ:終了レコードは 30 分保持、アイドル 24 時間でディスクへ永続化。
DELETE /v2/sessions/:idはクローズであり削除ではありません。今日の store はデフォルトで永続保存です。ストレージ保持期間のスキャン(日齢とユーザーごとの件数で休眠セッションを削除)は @tansr/serve 0.7.0 で近日提供予定。実際の削除はstore.deleteで行います。 - 構造化ログのフィールドにはトークンとメッセージ内容を決して含めません。メトリクスのラベルには sessionId / endUserId を決して含めません。
- 端末に下ろす権限要求フレームには完全なツール引数を決して載せず、ターゲットの概要だけを載せます。webhook のペイロードにはメッセージ内容と認証情報を決して載せません。
Android / iOS SDK は認証情報をキャッシュしません。ビュー状態はメモリにあります。sessionId をローカルに保存するか(コールドスタートで resume するため)はあなたが決めます——id だけを保存し、内容も認証情報も保存しません。
ローテーションと失効:各認証情報をどう替えるか
Section titled “ローテーションと失効:各認証情報をどう替えるか”| 認証情報 | 替え方 | 影響範囲 |
|---|---|---|
| PAT | コンソールで新しく 1 つ作成し、このマシンで tansr init --fresh を実行して再ログインし、その後コンソールで古い PAT を削除する |
PAT は tansr logout では決して失効しない——他のデバイスがまだ同じものを使っている可能性がある |
| このマシンの派生アプリキー | tansr init を再実行すればローテーションして期限が延びる(期限が近いとセッション内に「キーの期限が近づいています」の通知が出る)。tansr logout はローカルを消去しリモートでの無効化を試みる。デバイスを紛失した場合はコンソールでそのデバイスキーを手動で無効化できる |
各デバイスがそれぞれのキーを持ち(ホスト名 + デバイス id で命名)、互いに置き換わらない |
| アプリキー appkey | コンソールでローテーション(対応する POST /v1/apps/:id/rotate)。サーバー側の環境変数を更新してプロセスを再起動する |
最終手段の全断:古い appkey は即座に無効になる |
| あるエンドユーザーのトークン | コンソールまたは管理 API でエンドユーザー単位に失効(POST /v1/apps/:id/app-user-revocations)。そのユーザーの既存トークンは即時すべて拒否される。あなたのシステムでそのユーザーのログイン状態を止めれば自然に供給が止まる(トークンの TTL は 60–86400 秒で、更新は存在しない) |
そのユーザーにだけ影響 |
| アプリ全体 | コンソールでアプリを無効化 | 末端はすべて拒否 |
セッションサービス /v1 Bearer |
TANSR_SERVE_TOKEN / --token を替えて再起動 |
/v1 面の呼び出し側は同期が必要 |
webhook secret |
受信側でまず新旧 2 つの値を同時に受け付け、次にセッションサービス側を替え、最後に古い値を撤去する | 期間中の配信ロスはゼロ |
| あなた自身のログイン token(モバイル) | あなたのログインの仕組みに属する。SDK は 401 時に authProvider 経由で最大 2 回再取得し、それでも 401 なら終端状態に入ってあなたの明示的な再接続を待つ |
トークンを更新しても 401 なら失効か設定ミスであり、一時的な揺れではない |
プラットフォーム側でトークンの無効を引き起こすコードは 1 つだけです:unauthorized(401)。セッションサービスがこれを受け取ると、同じリクエスト内でキャッシュしたトークンを追い出し、再発行し、1 回再送します。端末側の SDK がこれを見たら、上記の 2 回で収束する手順を踏みます。他のコード(403、429、5xx)はいずれもトークンが壊れたことを意味しないので、それを理由に再発行しないでください。
クイック自己チェックリスト
Section titled “クイック自己チェックリスト”tansr doctor:認証情報はキーチェーンにあるか、平文ファイルにあるか?localProvidersのセクションはあなたの想定どおりか(プラットフォームモード / エスケープハッチ)?無人運転ベースラインに関する通知は出ていないか?- リポジトリで
TANSR_APP_KEY/sk-/tansr_sk_を一度grepして、実際の値が入っていないことを確認する。 - セッションサービスを
0.0.0.0にバインドしているとき、/metricsは内部ネットワークにだけ公開されているか?storeディレクトリはローカルディスクで、共有されていないか? - あなたのトークン発行エンドポイントは自前のログイン状態の後にだけ発行し、
endUserIdは常にサーバー側のセッションから取得してリクエストボディを信頼していないか? - コールド層オブジェクトストレージのライフサイクルルールと暗号化は設定済みか?
このページは役に立ちましたか?
フィードバックありがとうございます。この記事の改善に活かします。