AI 認証ブローカー

Agent/LLM実行系へ長期API key、OAuth refresh token、database password等を直接渡す設計は、prompt/tool/log/contextへの露出、共有資格情報による帰属不能、失効・rotation遅延、過剰権限を生みやすい。Credential Brokerは「agent identity」「authorization/delegation」「credential material」「egress/tool execution」を分離し、必要時だけ短命・限定credentialを発行またはbroker側で注入する統制点として整理する価値がある。

COMMON_CORE / IDENTITY+AUTHORIZATION / SECURITY / AUDIT / OPERABILITY。EA-043 Agent Identity、EA-044 Delegated Authorization、EA-046 AI Gatewayと隣接するが、EA-045はcredential lifecycleとsecret non-disclosureを主対象とする。

AI agent向けCredential Brokerをvendor-neutralに定義する際、どこまでを既存workload identity、OAuth token exchange/delegation、secrets manager/dynamic credential、agent product実装で裏付けられるか。特定製品の「agent credential broker」機能を一般標準と誤認しないためのfailure envelopeは何か。

• official standard --- RFC 8693, OAuth 2.0 Token Exchange, IETF, 2020, access 2026-09-28, https://datatracker.ietf.org/doc/html/rfc8693 VERIFIED_SPEC, token exchange / delegation-vs-impersonation semantics.
• official specification --- SPIFFE Workload API / SVID documentation, SPIFFE, current docs accessed 2026-09-28, https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/ and https://spiffe.io/docs/latest/deploying/svids/ VERIFIED_SPEC, workload identity and short-lived X.509/JWT SVID delivery.
• author-maintained product documentation --- HashiCorp Vault, Understand static and dynamic secrets / Database secrets engine, accessed 2026-09-28, https://developer.hashicorp.com/vault/tutorials/get-started/understand-static-dynamic-secrets and https://developer.hashicorp.com/vault/docs/secrets/databases VERIFIED_SPEC / PRODUCT_VOLATILE, dynamic credential generation, leases and revocation.
• provider official documentation --- Amazon Bedrock AgentCore Identity, provider setup / outbound authorization, AWS, accessed 2026-09-28, https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-idps.html and https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html PRODUCT_VOLATILE, managed inbound/outbound OAuth credential-provider implementation.
• standards-development primary source --- Credential Broker for Agents (CB4A), draft-hartman-credential-broker-4-agents-00, IETF Internet-Draft, 2026, https://datatracker.ietf.org/doc/html/draft-hartman-credential-broker-4-agents-00 RESEARCH, emerging design evidence only; not an RFC/standard.
• independent security research --- Palo Alto Networks Unit 42, The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE, 2026-09, accessed 2026-09-28, https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/ SOURCE_REPORT, counterevidence/failure envelope for attestation/selector compromise.

F1 [RESEARCH]: Credential Brokerは単一の既存標準名として固定できない。実装可能なvendor-neutral patternは、(a) workload/agent identity、(b) delegation/authorization decision、(c) secret/dynamic credential store、(d) short-lived issuance/token exchangeまたはbroker-side injection、(e) target-bound egress、(f) issuance/use/revocation auditを分離する構成である。

F2 [VERIFIED_SPEC]: RFC 8693はtoken exchangeにおけるdelegationとimpersonationを区別する。agentがuserを代表して動く場合、actor identityを消してuser impersonationだけにする設計と、actorを保持したdelegationは監査意味が異なる。Credential Brokerはこの差をcredential issuance recordへ保持すべきである。

F3 [VERIFIED_SPEC]: SPIFFEはworkloadがWorkload APIからSVIDを取得する標準面を提供する。これは「agentが外部SaaSのcredentialを取得するbroker」そのものではなく、brokerへ提示するworkload identityの一候補である。

F4 [VERIFIED_SPEC/PRODUCT_VOLATILE]: Vaultのdynamic secretsはon-demand credential、lease、TTL、revocationというcredential lifecycle primitiveを提供する。一方、static secret retrievalではcredential materialがclientへ渡る構成もあり得るため、「Vaultを使えばmodel/agentがsecretを見ない」は一般化できない。

F5 [PRODUCT_VOLATILE]: Amazon Bedrock AgentCore Identityはmanaged OAuth providerとoutbound authorization/credential providerを提供している。これはCredential Broker patternの現行provider実装例であり、全provider/plan/region/tenantで同じ機能がある証拠ではない。

F6 [RESEARCH]: 2026年のCB4A Internet-DraftはSPIRE/SPIFFE identity、task request envelope等をCredential Broker for Agentsとして提案しているが、Internet-Draftであり標準化完了を意味しない。将来仕様の方向性を示すcounterpartとしてのみ扱う。

• Brokerがsecretを保持していても、最終的にcredential valueをagent processへ返す設計ならcontext/log/tool subprocessへの漏洩面は残る。可能ならbroker-side injection/proxy executionとcredential non-disclosureを区別する。
• short-lived credentialはstolen credentialの有効時間を短縮するが、発行時のidentity/authorizationが誤っていれば誤権限を短時間で正当化するだけである。
• SPIFFE/SPIREはidentity primitiveでありauthorization policyやupstream SaaS scopeを自動的に正しくしない。attestation/selector compromiseやpost-exploitation identity misuseをfailure envelopeへ含める。
• OAuth scopeが細粒度でないproviderではbroker側policyが細かくてもupstream tokenのblast radiusを十分に縮められない場合がある。
• static API keyしか提供しないupstreamでは「短命credentialをmintする」ことが不可能な場合があり、broker-side injection、target pinning、request policy、rotationで代替する必要がある。
• token exchange、delegation、impersonation、service/workload identityを同義語として扱わない。
• broker自身は高価値な集中攻撃面になる。root/admin credential、encryption key、policy administration、audit logの分離とbreak-glass統制が必要。
• product documentationは特定tenantでのentitlement、region、policy、retention、実際のaudit completenessを証明しない。

provider/product、plan/contract、region、organization/tenant policy、IdP/authorization-server integration、supported credential type、OAuth grant/token-exchange support、target API scope granularity、Secrets Manager/Vault integration、agent runtime/network egress mode、preview/GA state、as-of dateを分離する。

PATTERN_SUPPORTED / PRODUCT_IMPLEMENTATIONS_EXIST / UNIVERSAL_STANDARD_NOT_ESTABLISHED。RFC 8693・SPIFFE・Vault等の既存primitiveで構成可能であり、AWS AgentCore等にagent向けmanaged implementationが存在する。一方、CB4AはInternet-Draft段階であり、共通agent credential broker標準として確定扱いしない。

安全なTEST_PROFILE（未実施）: 1. agent/workload A/Bを別identityで作成し同一target credentialへのgrant差を検証。 2. brokerがcredential valueをagent/model/logへ返さないmodeと返すmodeを区別して観測。 3. token/lease TTL、audience、scope、target binding、revocation propagationを測定。 4. user-delegated actionではsubject/actor chainがaudit evidenceへ残るか確認。 5. denied request、expired credential、revoked grant、wrong audience、cross-agent replayをnegative test。 6. static-key-only upstreamではbroker proxy/injectionのhost/path/method pinningを検証。 認証済みtenantや課金環境への危険なlive testは本RUNでは実施しない。

model contextへcredential valueを入れない。identity proofとauthorization decisionを分離し、credentialをaudience/target/scope/TTLへbindする。broker admin planeをagent runtimeから分離する。 PRIVACY: credentialそのものに加えOAuth refresh token、delegation subject、resource identifiers、audit metadataをsensitive dataとして扱う。 AUDIT: requester workload/agent identity、human subject（該当時）、delegation/impersonation semantics、policy decision、credential reference/type、target、scope、TTL、issuance/use/revocation/resultを相関可能にする。secret valueはauditへ記録しない。 COST: broker hop、token exchange、vault operations、audit retentionによるlatency/costを計測し、security controlを理由に無制限retryしない。 OPERABILITY: expiry/refresh race、clock skew、provider outage、revocation delay、secret rotation、broker HA、break-glass、policy rollbackを運用対象にする。

AI Credential Brokerは、agentへ長期credentialを配布する仕組みではなく、agent/workload identityとauthorizationを確認したうえで、必要なtarget・scope・期間に限定したcredentialを発行・交換する、またはbroker側でcredentialを注入して代理実行する統制パターンとして扱う。SPIFFE、OAuth Token Exchange、Vault等は構成primitiveであり、いずれか一つを導入しただけでagent credential isolationが成立するとは限らない。製品固有のmanaged identity/credential providerはplan・region・tenant設定・as-ofを別途確認する。

• EA-043 Agent Identityからverified workload identityを入力として受ける。
• EA-044 Delegated Authorizationからsubject/actor/delegation semanticsを受ける。
• EA-045では credential reference → policy decision → issuance/injection → target call → revocation/audit のlifecycleを正本化する。
• EA-046 Gatewayとは「credential policy/secret boundary」と「traffic/tool routing boundary」を分離し、同一製品でも論理面を混同しない。
• provider mappingではAWS AgentCore等をimplementation exampleとして扱い、common Coreへ逆一般化しない。
• CB4Aが更新・標準化された場合はVERSION_REFRESHする。

CB4A後続draft/標準化の行方、providerごとのtoken-exchange/RAR/delegation support、AgentCore等のplan/region/tenant entitlement、各providerのcredential non-disclosure保証範囲、revocation propagation実測、independent production evidence、organization固有break-glass/retention要件。

EA-045は、既存packet所在確認が未成功であることを保持したうえで、primary/author-maintained evidenceによるbounded backfillを完了した。今後は同一内容のフル再研究を行わず、canonical sync、CB4A/製品更新時のVERSION_REFRESH、独立実運用または安全なTEST_PROFILE追加時のSUPPLEMENT_ONLYとする。

---

Credential Broker is a vendor-neutral control pattern assembled from identity, authorization/delegation, credential lifecycle, target-bound execution and audit primitives; it is not an established universal agent standard. CB4A remains Internet-Draft -00 and its text states Expires 30 September 2026; official Datatracker current page was rechecked on 2026-09-30 and must be treated as work in progress, not an RFC/standard. Preserve SPIFFE/Vault/AWS implementation boundaries and all OPEN_UNKNOWN.