Akamaiが発表した内容
Akamaiは10月27日、Akamai Agent SandboxとAkamai Inferenceを発表しました。発表では両方をbetaとして提供し、Agent SandboxはSpin SDK経由で提供するとしています。Akamaiによると、sandboxはSpin frameworkのopen-source componentで、agentをAkamai Functions上で動かし、agentが生成したJavaScriptまたはPythonを別の制限された環境内で実行します。
AkamaiはWebAssembly isolationによりcompute、memory、outbound connection、system capabilityを制限できると説明しています。Product documentationでは二つのboundaryを示し、Spin applicationをWebAssembly sandboxで実行し、agent生成codeをその内側のrestricted runtimeで実行します。Outbound accessはdefaultでblockされ、operatorは選択したtool、skill、MCP serverへのaccessを許可できます。Akamai Inferenceは別途、OpenAI-compatible APIを通じたopen-weight modelのmanaged servingをserverlessまたはdedicated optionで提供します。
ここまではAkamaiが公表した機能とavailability statusであり、以下はIneezaの本番運用分析です。Beta accessはgeneral availability、独立したsecurity assessmentの完了、あらゆるlong-runningまたはregulated workloadへの適合を示すものではありません。Product pageは現在のpreviewが約1分のintermittent stepに対応するとし、長期間stateを保持するcomponentは今後の機能として説明しています。
Isolationはboundaryであり、authorization decisionではない
Nested runtimeは任意codeをcontainできますが、要求されたbusiness actionが正当かどうかは判断しません。Payment API、customer database、deployment toolを呼べるagentは、正しくisolateされた環境からでも未認可のeffectを起こし得ます。
Ineezaの分析: 外部capabilityはtenant、agent identity、tool、operation、resource scope、data classification、time window、approval requirementを結び付けた狭いcontractとして表し、runtimeで強制すべきです。Generated-code sandboxには再利用可能なcredentialではなく、承認済みcapabilityへの短命なreferenceだけを渡します。Model request、tool selection、sandbox実行の成功をbusiness authorizationとして扱ってはいけません。
Deny-by-default egressには完全なcontrol planeが必要
Outbound accessをdefaultでblockする設計は、生成codeによる自由なdata exfiltrationやuntrusted content取得を防ぐ強い出発点です。しかし許可されたendpointがより広いnetworkへのproxyになる、attacker-controlled destinationを受け付ける、または後続のagent behaviorを変えるcontentを返すと、riskは戻ります。
Ineezaの分析: Egress policyはdestination identity、protocol、method、path、payload class、response size、call budgetを結び付けるべきです。DNS resolution、redirect、TLS identity、private-address range、service側のURL fetchも明示的に扱う必要があります。ToolとMCP gatewayは一般的なnetwork tunnelを公開せず、structured requestとresponseを検証すべきです。Allowlistとgateway implementationの変更はapplication codeと同じrelease reviewの対象です。
Stateとretryはsandbox boundaryを越える
Akamaiはstep間のkey-value contextと、step終了後に停止し次のinstructionで再開するintermittent agentを説明しています。このexecution modelは継続的に露出するruntime stateを減らせますが、step間のhandoff自体がsecurityとcorrectnessのboundaryになります。
Ineezaの分析: Persisted stateはtenant-bound、encrypted、schema-versioned、size-limitedとし、secretから分離すべきです。Resume時に無条件で信頼するopaque transcriptではなく、decision inputと外部effect identifierを保存します。各stepにはidempotency keyとcompleted、failed、uncertain、awaiting approvalなどの明示的outcomeが必要です。外部call後のtimeoutでは生成codeを自動再実行せず、status recoveryを行うべきです。
各runで有効だったcapability setを証明する
Resource limitとnested isolationは、特定executionで何が強制されたかをoperatorが証明できるときに最大の価値を持ちます。OpenAI-compatible APIによるmodel portabilityは、model identityとbehaviorがsandbox configurationとは独立して変わり得ることも意味します。
Ineezaの分析: 証跡はagentとtenant identity、modelとversion、promptとtool-policyのdigest、sandboxとruntime version、generated-code hash、付与capability、egress decision、resource limit、state read/write、外部idempotency key、approval、output、termination reasonを相関させるべきです。Denied path、resource exhaustion、malicious redirect、cross-tenant access、partial external failureもtestします。Code実行の成功だけではcontainmentも正しいbusiness resultも証明できません。
Ineezaの見解
Akamai Agent Sandboxが重要なのは、deny-by-defaultのnested WebAssembly boundaryをdistributed agent runtimeへ組み込み、その基盤をopen-source SDKで公開する点です。本番patternはsandboxingより広く、未review codeをisolateし、ambient credentialではなくcapabilityを付与し、すべての外部effectをmediateし、controlled stateだけを永続化し、各runで有効だったpolicyを記録することです。Sandboxはgenerated codeを実行する場所であり、そのactionを統制可能にするのはcapability contractです。