発表された内容
Apolloは10月7日、AI agentとenterprise APIの間に置くcontrol layerであるGraphOS Agent Servicesを発表しました。同社によると、domain modelを横断するsearch、appと人を分離したidentity、upstream credentialのbrokering、field単位のpolicy、audit recordを提供します。Intuitは本番のGraphOS deployment上でpreviewを試行しています。ここまではApolloが公表した機能と顧客の説明であり、以下はIneezaの本番運用分析です。
Apolloのlaunch articleはpublic previewかつ利用可能なpreviewと説明する一方、現在のproduct documentationはApolloによるonboardingが必要なprivate previewと記載しています。この差は運用上重要です。teamは「preview」を安定したdeployment contractとみなさず、実際に提供されたservice tier、documentation snapshot、有効な機能、support commitmentを記録すべきです。
identityはすべてのhopを通過する必要がある
Apolloによると、各agent appはscope付きidentityを使い、interactive requestではsign-inした人のidentityをupstream systemまで伝達できます。agentはupstream credentialを保持しません。policyは、requestの背後にいる人またはgroupであるactorと、agent appやinteractive sessionなどのclientの両方を評価できます。
Ineezaの分析: この分離は適切ですが、本番証跡ではconnector、queue、retry、background jobのどこでもidentityが失われないことを証明する必要があります。すべてのside effectにagent identity、代理される人またはservice principal、承認済みpurpose、policy version、upstream credential exchange、結果のtransaction identifierを結び付けます。downstream systemがshared service accountへfallbackする場合、graphでの判断だけでは誰が操作を認可したかを証明できません。
field policyの完全性はclassificationに依存する
Agent Servicesのruleはactor、client、tag付きdata、allow、mask、denyのeffectを対象にします。より具体的なactorまたはclientのruleは広いruleより優先され、複数tagがあるfieldではより厳しいeffectが優先されます。Apolloのlaunch articleはtagのないfieldは制限されないと説明し、documentationはidentity providerのgroupまたはuser identifierを誤記すると通知なくmatchに失敗すると警告しています。
Ineezaの分析: したがってschema coverage自体がsecurity perimeterです。owner、classification、review済みpolicyのないfieldはfail closedでonboardingを止め、live schemaと承認済みcatalogを継続的に比較すべきです。testには新規field、改名されたidentity group、競合rule、introspection、partial response、hidden fieldを含めます。API callの成功だけでは意図したpolicyがmatchした証拠になりません。
data認可はtransaction認可ではない
Apolloはdenyされたwriteをupstream systemへ到達する前にblockすると説明しています。documentationにはmutationまたは承認が必要なfield向けの定義済みrequire-approval tagもあります。これはmodel外部にdeterministicなenforcement pointを作り、customer、infrastructure、金融状態を変更できるagentにとって重要です。
Ineezaの分析: field単位のallow判断だけでpayment、wallet操作、refund、本番変更を認可すべきではありません。実行境界では現在のbusiness stateに対して、送信先、金額、assetまたはresource、jurisdiction、budget、approval quorum、time window、nonce、idempotency keyも検証する必要があります。agentが操作を調査または提案しても自動的にcommitできないよう、read access、proposal authority、execution authorityを別のpolicyに分けるべきです。
audit viewだけでは完全なexecution receiptにならない
ApolloのMonitorはrequest、client、tool、operation、service、policy effect、rule適用後のresponse shapeを記録します。documentationによるとinspection panelは返却値を表示せず、CSV exportの対象は現在読み込まれたpageだけです。clientは接続済みservice全体でsuspendでき、反映には約1分かかります。
Ineezaの分析: これらのrecordは調査に有用ですが、影響の大きいworkflowにはrequestとresponseのhash、policyとschemaのversion、approval、upstream transaction identifier、retry、最終状態を保存する外部のdurable receiptが必要です。logをtamper-evident storageへ継続的にexportし、system of recordと照合すべきです。global kill switchより速くsettleできる操作には、suspension latencyを補うcontainment controlも必要です。
Ineezaの見解
GraphOS Agent Servicesは、分散したtool wrapperにあったagent governanceを、identity、credential brokering、field policy、観測可能なdenyを備えた共有API認可層へ移す点で重要です。本番で価値を得るにはgraphをより大きなcontrol systemの一境界として扱う必要があります。classification gapではfail closedにし、identityをend-to-endで維持し、実行時にtransaction固有の認可を適用し、重要な操作ごとに独立検証可能な証跡を保存する設計が必要です。