WAPのApplication Passwordが持つ権限

WAPと表示されたアプリケーションパスワードは、独立したロールではありません。それを所有するWordPressユーザーとしてリクエストを認証します。実際の権限は、そのユーザーのロールとケイパビリティ、呼び出すエンドポイントまたはAbility、組み込みプラグインが追加で実行する権限チェックによって決まります。

ラベル、通信方式、ツールの検出成功によって権限が広がることはありません。影響を抑えるには、承認された処理に必要な最小限の権限だけを持つ専用WordPressユーザーを使用します。

考えられる原因

• 認証情報がクライアントの想定とは異なるWordPressユーザーに属しています。
• アシスタントが専用の制限付きIDではなく、人間の管理者アカウントを使用しています。
• 認証されたWordPressユーザーにエンドポイントまたはツールが必要とする権限がありません。
• IDが意図的に読み取り専用なのに、ワークフローが書き込みを要求しています。
• 似た名前の認証情報が複数あり、所有者と実際の使用先が不明確です。

診断手順

1. クライアントが送るユーザー名がApplication Passwordの所有者と一致するか確認します。
2. 最小の認証済みID確認で、リクエストが表すWordPressユーザーを特定します。
3. 認証ユーザーのcapabilityをルートまたはツールが必要とする操作と比較します。
4. このIDで許可される既知の限定的な読み取りを繰り返します。
5. 意図的に禁止した書き込みを試し、拒否境界を確認します。
6. 秘密情報を表示せず、対象プロフィールのApplication Password欄を確認します。

最小限の修正を適用する

1. 人間の管理者を再利用せず、専用のWordPress IDを作成します。
2. 承認済み操作を完了できる最小のWordPressアクセスレベルを選びます。
3. 専用IDと一つの連携目的に対して名前付きApplication Passwordを一つ作成します。
4. 未使用または不要と確認できた認証情報を取り消します。
5. 誰が認証情報を作成、ローテーション、再利用、取り消すかと各トリガーを記録します。

結果を検証する

• 認証済みリクエストが意図した専用WordPressユーザーに対応します。
• 承認された限定的な読み取りが再現可能な応答で成功します。
• 意図的に禁止した書き込みは引き続き拒否されます。
• 取り消し後、同じ認証情報では認証できません。

避けるべき対応

• 接続テストを通す目的だけで管理者権限を付与しないでください。
• 認証成功と、すべてのWordPress操作の許可を混同しないでください。
• すべての 403 を接続障害と判断しないでください。正しい権限拒否の場合があります。
• Application Password、Authorizationヘッダー、トークン、Cookieをプロンプト、チケット、ログ、画像に含めないでください。
• 別の承認済みワークフロー、staging、ロールバックなしに制限付きIDからFull Powerへ移行しないでください。

関連ガイド

• WordPressでWAPのApplication Passwordを確認する方法
• AIアシスタントが使用するWordPressユーザーを特定する方法
• AIにどのWordPressアクセスレベルを与えるべきですか？
• AIアシスタントがWordPress管理者アカウントを使うべきではない理由
• WAP AI Assistantのアクセスを取り消す方法