コンテンツにスキップ

セキュリティとプライバシー

このページにはあなたができることだけを書きます:トラフィックの行き先を知る、認証情報を正しい場所に置く、データがどこに残るかを知る、ローテーションできるようになる。tansr 内部の防御線(権限エンジン、保護パス、ハードなセキュリティレッドライン、監査チェーン)は各形態のガイドですでに展開されており、ここではあなたの操作に関係する場合にだけ参照します。

外向き通信:トラフィックはどこへ行き、どう絞るか

Section titled “外向き通信:トラフィックはどこへ行き、どう絞るか”
宛先 いつ 無効化できるか
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 “データの保持:どこに、どれだけ、誰が削除するか”
  • セッション、設定キャッシュ、使用量キュー、プロジェクトメモリは <storageRoot>/(デフォルト ~/.tansrTANSR_STORAGE_ROOT または総ルート TANSR_USER_HOME でリダイレクト可能)に保存されます。プラットフォームにログイン後、新しいデータはアカウントごとに <storageRoot>/identities/<アカウント指紋>/ に分離されます。
  • セッションごとに 1 ディレクトリ:journal.jsonl(ハッシュチェーン)、meta.jsonattachments/、上限超過の成果物 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)はいずれもトークンが壊れたことを意味しないので、それを理由に再発行しないでください。

  • tansr doctor:認証情報はキーチェーンにあるか、平文ファイルにあるか?localProviders のセクションはあなたの想定どおりか(プラットフォームモード / エスケープハッチ)?無人運転ベースラインに関する通知は出ていないか?
  • リポジトリで TANSR_APP_KEY / sk- / tansr_sk_ を一度 grep して、実際の値が入っていないことを確認する。
  • セッションサービスを 0.0.0.0 にバインドしているとき、/metrics は内部ネットワークにだけ公開されているか?store ディレクトリはローカルディスクで、共有されていないか?
  • あなたのトークン発行エンドポイントは自前のログイン状態の後にだけ発行し、endUserId は常にサーバー側のセッションから取得してリクエストボディを信頼していないか?
  • コールド層オブジェクトストレージのライフサイクルルールと暗号化は設定済みか?