Willowが公開した機能
Willowは10月11日、10月のproduct digestを公開しました。同社によると、background agentは単一のshared accountではなく、処理を開始した本人としてintegrationを実行できるようになりました。また、initiating user、guard、approval、MCP server、timing、token countをcall単位で表示するvisual Tool Call Flowと、Okta Cross App Accessへの対応も追加しました。ここまではWillowが公表したproduct capabilityであり、以下はIneezaの本番運用分析です。
このreleaseが重要なのは、agent systemで分断されがちなidentityとexecution evidenceを接続しようとしているためです。userがtaskを開始し、非同期agentが後で再開すると、downstream toolにはservice credentialしか見えないことがあります。initiating userをaccessとreviewの両方へ結び付ける設計は、すべてのactionを一つのshared agent accountへ帰属させるより強い運用境界になります。
user identityはcontextでありtransaction認可ではない
WillowのdocumentationはSlack deploymentをshared integration、personal integration、「Run as the initiator」の3 modeで説明しています。initiator modeではagentがtriggerしたuserの接続済みaccountを使い、未接続ならuserへ接続を求めます。product digestは、XAAによって既存のOkta policyをagent connectionへ適用し、audit trailを保持できると説明しています。
Ineezaの分析: user accessの継承は誰がtoolへ到達できるかを示しますが、個別actionが現在認可されているかまでは決めません。本番agentはside effectの直前にresource、action、amount、destination、data classification、environment、approval stateを決定的に検証する必要があります。長時間jobでは、その判断を短命なexecution grantへ結び付けるべきで、trigger時のuser roleがrevocationや権限変更後も黙って存続してはいけません。
証跡chainには安定したcorrelationが必要
WillowによるとTool Call Flowは、userからguardとapprovalを経てMCP serverへ至る経路を再構成し、step単位のtimingとtoken usageを表示します。この表現はincident reviewを短縮できますが、読みやすいdiagramの完全性は、その下にあるeventとidentifierの完全性に依存します。
Ineezaの分析: 各runはtrigger、planning step、policy decision、approval、credential発行、tool request、downstream response、retry、最終state changeをまたぐimmutable correlation IDを持つべきです。証跡にはpolicyとagentのversion、正規化済みargument、actorとsubject identity、credential audience、idempotency key、response hash、信頼できるclockのtimestampも必要です。この接続がなければ、もっともらしいcall pathを表示できても、そのapprovalが調査対象のside effectを本当に統制したとは証明できません。
可観測性は拒否と破損経路も含める
成功したcall flowだけでは統制面を網羅しません。agentはsession期限切れ、user revocation、identity provider停止、guard timeout、重複delivery、toolの部分障害、処理受理後にerrorを返すdownstream systemにも遭遇します。
Ineezaの分析: 運用teamは成功runと同様に、拒否、放棄、retry、部分完了runをtestしmonitorすべきです。stateを変更するtoolはinitiator identity、policy context、approval evidenceを検証できない場合にfail closedとします。復旧にはidempotent retryとsystem of recordとのreconciliationが必要です。これがなければ、整ったobservability viewの背後でpaymentの重複、ticketの再作成、認可消失後の処理完了が起こり得ます。
shared modeとinitiator modeはpolicyを分ける
Willowはinitiator-bound executionに加えてshared integrationとpersonal integrationも維持しています。各modeには異なる運用目的がありますが、切り替えるとdownstream serviceから見えるprincipalが変わり、authorizationとauditのmodelも変化します。
Ineezaの分析: deployment modeは便宜的なfallbackではなく、明示的かつversion管理されたconfigurationにすべきです。shared identityはnamed ownerと独立したtransaction policyを持つ狭いautomationへ限定します。initiator-bound executionはuser authenticationが失敗したときshared credentialへfallbackしてはいけません。mode変更はagent promptを変えずに実効権限とaccountabilityの両方を変え得るため、review、canary test、証跡が必要です。
Ineezaの見解
Willowのreleaseは、agent platformに必要な二つの本番要件、すなわちinitiating userのidentityで行動することと、そのtool pathを再構成することを同じ基盤へ取り込んだ点で重要です。安全なdeploymentには、freshなuser authority、action単位policy、短命credential、安定したcorrelation、完全なfailure evidence、実際のside effectとのreconciliationによってchainをend-to-endで維持する必要があります。identityとobservabilityは互いを強化しますが、どちらもtransaction認可の代わりにはなりません。