AWSが「AIエージェント＝LLM＋ハーネス」をOSS化した――安全性の主戦場はモデルの外側へStrands Harnessから考える、Memory・MCP・Tool・CredentialとSecurity Knowledge OS
2026年9月29日、Publickeyで興味深い記事を見つけた。
Amazon Web Services（AWS）が、AIエージェントを構築するための「Strands harness」をオープンソースで公開したという。
Publickey
Strands harnessは、Strands Harness SDKの上に構築された、Tool、Memory、Context管理などをあらかじめ組み合わせたAgent Harnessだ。
Amazon Bedrockだけでなく、Anthropic Claude、OpenAI GPT、Google Gemini、Ollama、LiteLLMなど複数のモデルに対応し、モデルを後から入れ替えることもできる。
一見すると、
「AWSが便利なAIエージェント環境を公開した」
というニュースに見える。
しかし私が気になったのは、そこではなかった。
Publickeyの記事では、AIエージェントについて、
「LLMとハーネスによって出来ている」
という整理がされている。
そしてハーネスには、
Memory
Context
Filesystem
Network
Tool
API
Policy
Permission
Guardrail
などが含まれる。
これはAI安全性を考える上で、かなり重要な変化だと思う。
AIエージェントの安全性は、もうLLMだけを見ていればよい問題ではない。
モデルの外側にあるArchitectureそのものが、安全境界になり始めている。
⸻
1. LLMだけではAIエージェントにならない
ChatGPT、Claude、Geminiなどを見ていると、
AI ≒ LLM
という印象を持ちやすい。
しかし実際にAIへ仕事をさせようとすると、LLM単体では足りない。
LLMは基本的には、
Input
↓
Reasoning
↓
Output
を行う。
ところがAIエージェントになると、
ファイルを読む
ファイルを書く
Webへアクセスする
APIを呼ぶ
Shellを実行する
Databaseへ問い合わせる
過去の情報を記憶する
別のAgentへ仕事を委任する
といった能力が必要になる。
概念的には、
となる。
Strands harnessは、この「Harness側」をかなり完成された状態で提供するものだ。
ここで重要なのは、
Agentの能力はLLMだけによって決まらない
ということだ。
同じLLMでも、
LLMだけ
と、
LLM
+
Filesystem
+
Shell
+
Network
+
Credential
では、現実世界へ及ぼせる影響がまったく違う。
⸻
2. モデルは交換できても、Architectureは残る
Strands harnessは特定のLLMに強く依存しない。
Claude、GPT、Gemini、Ollamaなど複数のモデルを利用できる。
つまり、
Claude
↓
GPT
↓
Gemini
↓
Ollama
とモデルを交換しても、
Memory
Context
Tools
Filesystem
Shell
Network
MCP
というAgent Architectureは残る。
安全性についても同じだ。
これまで、
「Claudeは安全か」
「GPTは安全か」
「Geminiは安全か」
とモデル単位で議論することが多かった。
しかしAgent化が進むと、
Model Safety
だけではなく、
Agent Architecture Security
を見る必要が出てくる。
LLMが安全でも、強すぎる権限を持つToolを与えれば事故は起き得る。
逆に、LLMそのものに完全な信頼を置かなくても、
Least Privilege
Isolation
Approval
Credential Management
などによって影響範囲を制限することもできる。
この構造は、かなりCybersecurityに近い。
⸻
3. Strands harnessは最初から強力である
Strands harnessには、標準のBuilt-in ToolとしてShellやファイル操作などが用意されている。
公式ドキュメントでは、ShellやFile Toolによってコマンド実行やファイル操作をAgentへ提供できる。
ただし、ここには重要な補足がある。
Strands harness標準のShell/File Toolは、単純にホストOSへ直接コマンドを投げるだけの設計ではない。
これらはSandbox経由で動作し、用途に応じてLocal、Docker、SSHなど異なるSandbox Backendへ切り替えることができる。
したがって、
Agent
↓
Shell
↓
即Host OS
と単純化するのは正確ではない。
より正確には、
Agent
↓
Harness Tool
↓
Sandbox Boundary
↓
Filesystem / Runtime
となる。
これはStrands側でも、安全性がかなり意識されていることを意味する。
一方で、Strands SDKへ登録するCustom ToolやCommunity Tool、外部Toolなどについては、そのTool自身のSecurity Boundaryを別途確認する必要がある。
ファイルアクセス、ネットワーク通信、Shell実行、外部API呼び出しなどを行うToolであれば、
「何を実行できるのか」
「どの権限で動くのか」
「どこまで到達できるのか」
を監査する必要がある。
つまり、
Strands標準Shell/File Tool
↓
Sandbox経由
Custom / Community / External Tool
↓
Tool固有のSecurity Boundary
と分けて考える必要がある。
⸻
4. MCPによって安全境界はさらに広がる
ここでMCPが登場する。
MCPを利用すれば、Agentから外部Tool Serverへ接続できる。
たとえば、
GitHub
Database
Browser
Cloud API
Filesystem
などを共通インターフェースで扱える。
これは非常に便利だ。
しかし、
Agentが触れられる世界が広がる
という意味でもある。
重要なのは、MCPそのものを危険視することではない。
問題は、
Agentは何を見ることができるのか
何を書き換えられるのか
何を送信できるのか
どのCredentialを使えるのか
というCapability設計である。
私は以前、MCPを利用する際の実践的な安全策として、
管理者/rootで動かさない
専用Workspaceを作る
ホームディレクトリ全体を渡さない
SSH鍵・API Key・CookieをWorkspaceへ置かない
削除・外部送信・Credential利用にはHuman Approvalを入れる
といった整理を行った。
参考：
MCPを安全に使うための実践ガイド
Strandsを見ても、結局同じ問題へ到達する。
Agent Securityでは、
「何ができるか」
だけでなく、
「何を許すか」
を設計しなければならない。
⸻
5. Strands Shellは「完全隔離」ではなく「仲介層」
ここで、Harness標準Toolが利用するSandboxとは別に、Strandsが提供する「Strands Shell」について見てみたい。
Strands Shellは、AIエージェント向けに設計されたin-processの仮想Shellである。
Filesystem、Network、Credentialへの操作をKernelが仲介し、Agentから見える範囲をLeast Privilegeで制限する。
ただし公式は、Strands Shellを
「hardened sandbox」
そのものではなく、
「mediation layer」
として位置付けている。
つまり、
Strands Shell
＝
Agentが何へ触れられるかを
細かく制御する仲介層
≠
Container / VMのような
OSレベルの隔離境界
である。
Strands Shellは同一プロセス内で動作する。
そのため、Agentが許可されていないファイルやURLへ触れることを制御する用途には向いているが、敵対的な任意コードを完全に封じ込めるOS境界とは異なる。
より強いThreat Modelでは、
Container
microVM
などOSレベルのIsolationを追加し、その内側でStrands Shellによる細粒度制御を組み合わせる構成が考えられる。
構造としては、
となる。
これは以前MCP安全設計で整理した、
最低限
専用Workspace
↓
より強く
専用User / Container
↓
さらに強く
VM / OS Sandbox
という考え方ともかなり近い。
結局、AI AgentへOSやToolを触らせると、
Least Privilege
Isolation
Credential Management
Network Control
という従来のCybersecurityへ戻ってくる。
⸻
6. CredentialをAgentそのものへ渡さない
Strands Shellでもう一つ面白いのがCredential管理だ。
通常、API Keyなどを環境変数としてAgentの実行環境へ渡した場合、
Agent
↓
Environment Variable
↓
API_KEY
となる。
AgentがShellを利用できれば、設計次第では秘密情報そのものへアクセスできる可能性がある。
Strands Shellでは別の方向が取られている。
CredentialをAgentへ直接見せるのではなく、HTTP Request時にKernel側から必要なCredentialを付与する仕組みが用意されている。
概念的には、
となる。
これはかなり重要な考え方だ。
AIへCredentialそのものを所有させる必要はない。
必要な処理だけを代理実行できればよい。
私は別の実験で、
Credential Proxy
短寿命Token
Capability制限
などを検討している。
もちろんStrands Shellと自作Credential Proxyは同じ仕組みではない。
しかし、
Agentに秘密を見せる
のではなく、
Agentに秘密を利用した処理だけ許す
というSecurity Principleには共通点がある。
⸻
7. ではSKOSは何をするのか
ここで、自作しているSecurity Knowledge OS（SKOS）へ繋げたい。
GitHub
解説記事
ただし、
「Strandsには安全機能がないのでSKOSが必要」
という話ではない。
それは明確に違う。
Strandsにはすでに、
Sandbox
Least Privilege
Network Control
Credential Mediation
Tool Selection
Intervention
Guardrail
などの安全機構が存在する。
ではSKOSは何をするのか。
私が考えている役割は、
実行基盤そのものではなく、設計や判断を支援するKnowledge / Governance Layer
である。
概念的には、
となる。
SKOSでは現在、
PI
Prompt Injection
MEM
Memory
TOOL
External Tool
CRED
Credential
などの観点から構成を評価する。
つまり、
SKOS
「このAgent Architectureには
どのようなリスクが存在するか？」
を見る。
一方でCPOSについては、
CPOS
「現在の状態において、
このAgentへどこまでCapabilityを許すか？」
という動的な権限制御層として研究している。
ここも誤解しないようにしたい。
CPOSがStrandsに欠けているApprovalやPolicy機能を単純に補う、という意味ではない。
Strandsにも実行時PolicyやApprovalに利用できるIntervention機構が存在する。
私がCPOSで検討しているのは、
Trust Score
Decay
Capability Ceiling
Isolation
Auditor
などを使い、
Agentの状態によって許可されるCapabilityそのものを変化させられないか
という別の研究課題である。
役割としては、
SKOS
Risk Knowledge
↓
CPOS
Dynamic Capability Governance
↓
Strands
Agent Runtime
という分け方が近い。
⸻
8. Memoryは便利だが、新しい安全境界でもある
Strands harnessにはLong-term Memoryも用意されている。
公式ドキュメントでは、Long-term Memoryによって会話から長期的に保持する情報を抽出し、Persistent Storageへ保存し、必要な情報を後のContextへ戻す仕組みが提供されている。
標準では、
./.agent/memory
以下へMarkdown形式で保存される。
またMemoryはSession Stateとは独立して保持され、関連するMemoryが後続の推論時に検索されてContextへ注入される。
概念的には、
となる。
非常に便利だ。
しかしSecurity視点では、
「何を記憶してよいのか？」
という別の問題が出てくる。
Credentialは？
個人情報は？
機密情報は？
誤情報は？
外部Toolから取得した情報は？
信頼できないWebページ由来の内容は？
ここから先は、Strandsに既知の脆弱性があるという話ではない。
Persistent Memoryを持つAgent一般に対するThreat Modelとしての問題提起である。
たとえば、Prompt Injection由来の内容や誤情報がMemoryへ保存された場合、それが後続Sessionでも利用される可能性について考える必要がある。
Session Stateとは独立したPersistent Memoryとして保持されるため、Sessionをまたいで後続の推論へ再利用され得る。
つまりMemoryには、
何を保存するか
どこから来た情報か
誰が保存したか
どの程度信頼できるか
いつまで保持するか
削除できるか
というGovernanceが必要になる。
Memoryは単なる便利機能ではない。
新しいSecurity Boundaryでもある。
⸻
9. Context Compressionと「証拠」の問題
今回Strandsを調べていて、個人的に一番面白かったのがContext Managementだった。
Agentは長時間動作すると大量のContextを抱える。
しかしLLMのContext Windowには限界がある。
Strands harnessでは、古い会話を要約したり、大きなTool ResultをContextの外へ退避させたりする仕組みが用意されている。
概念的には、
となる。
これは性能面では合理的だ。
しかしSecurityの観点から見ると、別の疑問が生まれる。
安全判断に必要な証拠が、現在のContextから外れていたらどうするのか？
仮に極端な例を置いてみる。
Toolが1万行の設定情報を返したとする。
その中に、
line 8314
API_KEY=xxxxxxxx
という情報があったとする。
しかし、その結果がOffloadやSummaryによって、
Configuration files were inspected.
程度の情報としてしか現在Contextへ残っていなかったとする。
その後Agentが、
この情報を外部サービスへ送信してよいか？
を判断するとしたらどうなるだろう。
重要なのは、
「Strandsでは証拠が永久に失われる」
という話ではない。
元データへ戻れる設計なら、必要なときに再参照できる。
問題は、
安全判断時にRaw Evidenceへ戻ることを必須にするかどうか
である。
ここには、
Raw Evidence
Evidence Pointer
Source / Provenance
Summarized Flag
Offloaded Flag
Risk Classification
のような情報管理が必要になるかもしれない。
これは現在SKOSで検討している、
「入力と証拠の厳密化」
という課題にも繋がる。
Context Engineeringは、
「どうやって少ないTokenでAgentを賢く動かすか」
という性能問題だけではない。
場合によっては、
Safety Evidence Management
でもあるのではないか。
これは今後実験してみたい。
⸻
10. AI安全性の主戦場が「モデルの外側」へ広がる
これまでAI Safetyというと、
Alignment
Jailbreak
Hallucination
Bias
Model Behavior
など、モデルそのものへ注目することが多かった。
もちろん、これらは今でも重要だ。
しかしAgent化が進むと、安全性の対象は広がる。
Model Safety
│
▼
Agent Safety
│
▼
Architecture Security
Agentには、
Memory
Tool
Network
Filesystem
Credential
Shell
MCP
が存在する。
Multi-Agentになれば、さらに、
Agent Identity
Delegation
Capability Transfer
Shared Memory
などが加わる。
すると、
「このLLMは安全ですか？」
という問いだけでは足りなくなる。
必要なのは、
何を見ることができるのか
何を書けるのか
何を実行できるのか
どこへ通信できるのか
どのCredentialを使えるのか
何を記憶できるのか
誰へ権限を委譲できるのか
という問いだ。
これは従来のCybersecurityで扱ってきた、
Least Privilege
Capability Control
Isolation
Identity
Credential Management
Audit
Zero Trust
とかなり近い。
AI SafetyとCybersecurityの境界が、徐々に重なってきている。
⸻
11. Capabilityが増えるほどGovernanceが必要になる
AIエージェント競争では、
より賢いモデル。
より多くのTool。
より長いMemory。
より高度な自律性。
が注目されやすい。
そしてToolを増やすこと自体は、以前より簡単になった。
MCP Serverを追加する。
Shellを与える。
Browserを与える。
Databaseへ接続する。
Credentialを利用可能にする。
しかし、本当に難しいのはその先だ。
Can the agent do this?
だけではなく、
Should the agent be allowed to do this?
を決める必要がある。
技術的に実行可能であることと、
安全上許可してよいことは同じではない。
だから、
Policy
Capability
Evidence
Trust
Identity
Human Approval
が必要になる。
Agentの能力を増やす研究と同時に、
その能力を誰が、いつ、どの条件で使えるのか
を設計する研究が必要になる。
私はこれを、
Capability Governance
として見ている。
⸻
12. Strands harnessが示しているもの
Strands harnessそのものもかなり面白い。
しかし個人的には、このOSSが示している方向性の方がさらに興味深い。
AIエージェントが、
LLM
だけではなく、
LLM
+
Memory
+
Context
+
Tools
+
Permissions
+
Runtime
+
Network
+
Policy
として構成されることが、より明確になってきた。
モデルは交換できる。
しかしAgent Architectureは残る。
ならば安全性も、
「どのLLMが安全なのか」
だけではなく、
「どんなArchitectureなら、安全に能力を与えられるのか」
という問題になる。
Strandsはその問題に対して、
Sandbox
Least Privilege
Credential Mediation
Network Policy
Tool Control
Intervention
などの仕組みを提供している。
そしてそのさらに外側には、
Risk Assessment
Evidence Provenance
Memory Governance
Capability Governance
Identity
Delegation
Human Review
といった課題が残る。
私は、その一部をSKOSやCPOSで実験している。
⸻
まとめ
AWSのStrands harness公開は、単なる新しいAgent開発ツールの登場ではないように思う。
少なくとも私には、
「AIエージェントとは何なのか」
をかなり分かりやすく見せる事例に見えた。
AI Agentは、もはやLLMだけではない。
LLM
+
Harness
である。
Harnessには、
Memory
Context
Tools
MCP
Shell
Network
Filesystem
Credential
Policy
Guardrails
が存在する。
だから安全性も、
Model Safety
だけでは終わらない。
Model Safety
↓
Agent Safety
↓
Architecture Security
まで考える必要がある。
AIを賢くすること。
AIにToolを与えること。
AIへMemoryを与えること。
AIへCredentialを利用させること。
それら自体は、これからさらに簡単になっていくだろう。
だからこそ、
何を許可するのか。
何を記憶させるのか。
どこまで権限を与えるのか。
秘密情報をどう扱うのか。
安全判断に必要なEvidenceをどう保持するのか。
誰が最後に承認するのか。
という「モデルの外側」の設計が重要になる。
AIが現実世界へ作用する能力を持ち始めた以上、
問題はもう、
「AIは何を考えるか」
だけではない。
「AIに、何をさせることを許すのか」
なのである。
⸻
参考資料
Publickey
AWS、AIエージェントを自作できるツール「Strandsハーネス」をオープンソースで公開
https://www.publickey1.jp/blog/26/awsaistrandsllm.html
Strands Agents
https://strandsagents.com/
Strands Harness Quickstart
https://strandsagents.com/docs/user-guide/harness/quickstart/
Strands harness - Shell and file tools
https://strandsagents.com/docs/user-guide/harness/tools/shell-and-files/
Strands Shell - Security model
https://strandsagents.com/docs/user-guide/shell/security/
Strands Shell - How it works
https://strandsagents.com/docs/user-guide/shell/how-it-works/7
Strands harness - Memory
https://strandsagents.com/docs/user-guide/harness/configure/memory/
Strands harness - Context and caching
https://strandsagents.com/docs/user-guide/harness/configure/context-and-caching/
Strands harness - Configuration reference
https://strandsagents.com/docs/user-guide/harness/reference/configuration/
Strands harness - Production
https://strandsagents.com/docs/user-guide/harness/production/
Security Knowledge OS
https://github.com/kagioneko/security-knowledge-os
Security Knowledge OS 解説
https://note.com/emilia_lab/n/nbe1bd393b042
MCPを安全に使うための実践ガイド
https://note.com/emilia_lab/n/n5b48254e753e
⸻
ハッシュタグ
#AI
#生成AI
#AIエージェント
#AWS
#StrandsAgents
#LLM
#MCP
#AIセキュリティ
#サイバーセキュリティ
#AI安全性
#AgentSecurity
#CapabilityGovernance
#SecurityKnowledgeOS
#SKOS
