「信じてください」は答えになりません。
Klornは、あなたの代わりに他人が書いたメールを読みます。この一文そのものが脅威モデルです。主な入力は見知らぬ人が書いたテキストで、その中には悪意を持つ人もいます。アーキテクチャが実際に保証していることを、それぞれを実装しているファイルとともに示します。
この翻訳は便宜上提供しているものです。英語版が優先します。英語版を読む
Googleの検証と独立した評価
Googleは2026-10-03に、KlornのOAuth検証の審査を完了しました。それに先立ち、KlornはTAC SecurityによりCASA Tier 2に基づく独立した評価を受け、結果はIn Compliance（適合）でした。その評価の検証レター（Letter of Validation）は、その後Googleに提出されています。
- 評価
- CASA Tier 2、動的アプリケーションセキュリティテスト（DAST）、TAC Securityによる実施
- 結果
- In Compliance（適合）、保証レベルAL1（OWASP ASVS Level 1）
- 日付
- 評価 2026-08-12 · 報告書発行 2026-08-30 · Googleの審査完了 2026-10-03
- 再評価
- 毎年。次回の評価は2027年8月の予定です
5つのGoogleスコープと、それぞれが必要な理由
この5つがその審査で承認されたGoogleスコープで、Klornが求めるメールとカレンダーのスコープはこれだけです。Gmailのフルアクセススコープは求めず、カレンダーでも求めるのはcalendar.eventsとcalendar.readonlyだけです。カレンダーのフルスコープは決して求めません。
gmail.readonly- メッセージを読み取り、Klornが振り分けて各判断の理由を示し、頼まれたときにスレッドを要約できるようにします。
gmail.modify- Klornで操作したときにメッセージの状態を変更します：アーカイブとその解除、ゴミ箱への移動と復元、スター、既読・未読の切り替え、そしてGmailへの返信の下書きの保存。
gmail.send- メールを送信するのは、あなたが承認したとき（確認した返信や、依頼したmailtoによる配信停止）か、自分で設定したルールによる自動返信のときだけです。
calendar.readonly- すべてのカレンダーの空き状況を読み取り、会議のメールを実際の予定と照合して重なりを見つけます。
calendar.events- Klornに頼んだときに、メインのカレンダーで予定を作成・変更・削除します。カレンダーの設定や共有には触れません。
Googleでのログイン時に求めるのは、名前とメールアドレスだけです。メールとカレンダーのスコープは、受信トレイを接続するときに2つ目の同意画面で求めます。カレンダーだけを接続する場合はcalendar.readonlyのみを求め、メールのスコープは一切求めません。（そのファイルにはopenidとuserinfo.email/userinfo.profileも含まれています。これらはどのアカウントでログインしたかを識別するためのもので、機密性はなく、Googleの審査対象にも含まれていません。）
データの行き先
OAuthトークンは保存前にAES-256-GCMで暗号化され、ホストされるすべての画面はTLSのみで、分析にメッセージの内容が含まれることはありません。それぞれの根拠となるファイルは下の表をご覧ください。ログはデータの保存期間にある固定スケジュールで期限切れになります。メールを私たちのサーバーに一切通したくない場合は、同じコードをセルフホストして、自分のモデルキーかローカルモデルで動かせます。プライバシーポリシーは/privacyにあります。
これが意味すること、意味しないこと。この審査と評価が確認するのは、Klornが求めるGoogleのデータをどう扱うかです。GoogleがKlornを推奨しているという意味ではなく、それらのスコープ以外のことは対象に含まれません。現在接続できるのはGmail、Googleカレンダー、Naverメール（ベータ）、iCloudメール（ベータ）で、ほかのプロバイダーにはまだ対応していません。
アーキテクチャが保証していること
| 項目 | 実際の状態 | 確認する場所 |
|---|---|---|
| メールは敵対的な入力 | すべてのメール本文、件名、第三者の文字列は、モデルに届く前に<untrusted_content>マーカーで囲まれます。既存のラッパータグは先に除去されるため、細工したメッセージでラッパーを閉じることはできません。プロンプトインジェクションは対策の範囲内であり、受け入れた制限ではありません | SECURITY.md |
| 保存時のトークン暗号化 | トークンがデータベースに触れる前にAES-256-GCMで暗号化します。キーリングのローテーション（v1/v2エンベロープ）により、漏えいが疑われる場合も一斉切り替えの日を設けずにキーを切り替えられます。dev/test以外でキーがない場合は、フォールバックせずに起動を中止します | crypto-tokens.ts |
| 外部への操作 | 送信・完全削除・外部への転送は、分類器の確信度だけでは実行されません。それぞれに、承認時に発行され正規化したペイロードのsha256を固定するレシートが必要で、実行時に再検証されます。その間に何かが変わっていれば、操作は拒否されます | attention-floor.ts |
| 開発用の便宜機能 | 開発用JWTシークレット、開発用暗号化キー、localhostのCORS、デモユーザーはdev/testの許可リストの内側にあり、それ以外のNODE_ENVでは安全側に閉じます（fail closed） | env.ts |
| 分析 | ファーストパーティのみ。Klorn自身のPostgresに、大まかなイベント名の短い許可リストだけを記録します。外部トラッカーはなく、メッセージの内容は決して含みません | analytics.ts |
| 通信時の暗号化 | ホストされるすべての画面でTLSのみ — API、ウェブ、Google API、モデル提供元 | self-hosting.md |
データの保存期間
ログの保存期間は、約束ではなく定期的な削除処理によって強制されています。エージェントの操作、メール処理、プッシュ配信、Webhookの記録は90日後に、レート制限の記録は30日後に、トークンの使用量記録はコスト変動の分析のため180日後に削除されます。この期間はソースコード内の表であり、差分に現れないままこっそり延ばせる設定ではありません。
脆弱性の報告
説明と再現手順を添えてk0820086@gmail.comにメールしてください。悪用可能な発見については、公開のissueを立てないでください。数日以内に受領のご連絡をします。承認フロアとトークン暗号化の経路に関する修正は、何よりも優先します。機械可読の連絡先情報は/.well-known/security.txtにあります。
主張していないこと。上記のCASA Tier 2評価を除き、Klornは第三者によるペネトレーションテストもSOC 2監査も受けておらず、このページもそれを示唆するものではありません。ひとりで保守しているベータ版の製品です。それを補う管理策は、コードがAGPL-3.0であり、セキュリティに関わる経路を上でファイル名とともに示していることです。私たちの言葉を信じる代わりに、コードを読んで確かめられます。
SECURITY.mdには、省かずに明記することを選んだ既知のギャップも含めた詳しい版があります。