AI Agentにアクセス権を与える前に確認すべきこと

AI Agentにaccessを与える前に、8項目を確認します。誰が指示できるか、何へ届くか、どこで実行するか、credentialのscope、信頼するplugin、approvalが必要なaction、dataとmemoryの行き先、accessのrevoke方法です。

taskに必要な最小permissionから始めます。選択肢があるだけでfull accessを与えず、実際の必要性に応じて広げます。

message accessとtool accessを一緒に見る理由

Agentはgroup message、web page、email、file、tool result、plugin outputからもinputを受けます。それらが次のactionに影響します。

riskはinputとauthorityの組み合わせです。read-only Agentと、shell、browser session、private file、message送信権限を持つAgentでは影響が違います。

1. 誰がAgentと話せますか？

private、pairing、allowlist、team限定、publicのどれかを決め、DMとgroupを分けて確認します。

OpenClaw公式Gateway Security guideはidentityを先に決め、pairingまたはallowlistを使うよう勧めています。公式Hermes Agent Security Policyもnetwork messaging surfaceにcaller authorizationを求めています。

2. どのfileとtoolへaccessできますか？

必要なcapabilityだけを列挙します。1つのprojectを読むためにhome folder全体へaccessする必要はありません。

restricted workspace、read-only、filesystem accessなしを優先し、shell、write、browser、automationは必要になってから有効にします。

AI Agentを1つのfolderだけに制限する方法

taskに必要なfileだけを置く専用working directoryを作ります。Agent frameworkとOSの両方で、そのdirectory外のpathをreadまたはwriteできないようにします。確認だけでよい場合はworkspaceをread-onlyで公開します。

symlink、mountされたfolder、shell command、browser download、共有temporary directory、workspace内のcredentialなど、境界を迂回できる経路も確認します。

実dataを使う前に境界をtestします。workspace内の使い捨てfileでread、create、edit、deleteを試し、外側でも同じactionを試します。外側のactionは失敗し、新しいfolderやtoolへの拡張には別approvalが必要です。

3. commandはどこで実行されますか？

host上、tool sandbox、container、whole-process isolationのどこで実行されるかを確認します。

Hermesはlocal backendがhostでcommandを実行でき、強いcontainmentにはOS-level isolationが必要だと説明しています。OpenClawもtool policy、sandbox、host isolationを分けています。

4. どのcredentialへ届きますか？

model key、cloud token、SSH key、browser session、email、service accountを確認し、不要なsecretをAgent hostに置かないようにします。

scopeが狭く交換可能なcredentialを分けて使います。

5. どのskill、plugin、connectorを信頼しますか？

pluginはAgentと同じprivilegeで動く場合があります。source、license、maintainer、install script、network behavior、update pathを確認します。

ClawChatのOpenClawとHermes connectorはClawlingがmaintainする独立integrationです。第三者pluginすべてが信頼できるという意味ではありません。

6. どのactionにhuman approvalが必要ですか？

account変更、publish、message送信、支払い、削除、production変更にはapprovalを使います。

ClawChatのAgent permission documentationは対応するin-app actionにAsk every time、Allow、Denyを用意しています。これはAgent hostのfilesystem、shell、browser、credential controlを置き換えません。

実用的なAllow、Ask、Deny policy

impact、reversibility、reachでpermissionを分類します。実workflowが必要とし、境界をtestするまでは、capabilityをDenyからAskへ、またはAskからAllowへ変更しません。

• Allow: 承認済みfileのreadやcopyの変換など、専用workspace内のlow-impactでreversibleな作業。
• Ask every time: fileのwriteやdelete、message送信、publish、software install、browser action、shell command、account変更、新しいfolderへのaccess。
• Deny: 無関係なdirectory、raw credential、billing control、production system、destructive command、不可逆なexternal action。明確にreviewされたworkflowが必要な場合だけ例外を検討します。

messaging approval、Agent tool policy、filesystem permission、credential scope、sandbox、OS isolationは別々のboundaryを守るため、各layerで同じpolicyを適用します。

7. message、memory、metadataはどこへ行きますか？

chat client、messaging service、connector、runtime、model provider、tool、memory storeのdata pathを描きます。

ClawChatのPrivacy Policyはservice運用に必要なmetadataを説明し、private Agent memoryはAgent runtimeまたはhosting providerが保持するとしています。modelとhostのpolicyも別に確認します。

8. どうtestし、revokeしますか？

低riskのfolder、account、conversationでtestし、denyされたactionが失敗し、未承認senderがAgentをtriggerできないことを確認します。

process停止、connector無効化、credential revoke、key rotation、pairingやallowlist削除の方法を把握します。

短いpermission checklist

• 意図した人とgroupだけが指示できる。
• 必要なfileとtoolだけが見える。
• 高impactの実行が適切にisolateされる。
• credentialが分離され、scopeが狭く、交換できる。
• skill、plugin、connectorをreviewしている。
• sensitive actionはapprovalまたはdenyになっている。
• message、model、memory、metadataの経路を理解している。
• denyをtestし、すぐrevokeできる。

ClawChatへAgentを接続する場合

ClawChatをconversation layer、Agent frameworkをexecution layerとして扱います。誰がconversationに参加できるかと、hostで何ができるかを別々に設定します。

自分で動かすAI AgentとのchatとAI agent messengerの定義も確認してください。

よくある質問

personal AI Agentにfull accessを与えるべきですか？

実際のworkflowが必要とし、input、isolation、credential、recovery planがそのauthorityに合う場合だけです。

approval promptはsecurity boundaryですか？

有用なguardrailですが、常に強いcontainmentになるわけではありません。OS-level isolation、sandbox、狭いcredentialと組み合わせます。

self-hostingでpermission問題は解決しますか？

いいえ。runtimeのcontrolは増えますが、host、network、credential、plugin、backupの責任も増えます。

慎重に接続する

小さなaccessから始め、boundaryをtestし、capabilityを1つずつ追加します。

permission modelが明確になったらAgentをClawChatへ接続し、低risk dataで最初のconversationを確認します。