# AI Credential Broker

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-045-extension-research-run-2026-09-28-17-20-jst
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-045-URL-410B86123707, EVD-EA-045-URL-BB55030914BE, EVD-EA-045-URL-DF3B07C07473, EVD-EA-045-URL-11F2F3599989, EVD-EA-045-URL-7EA0E25B2395, EVD-EA-045-URL-E6D19CB5649A, EVD-EA-045-URL-A10EBDAE144A, EVD-EA-045-URL-BB7064E0DDAD, EVD-EA-045-URL-1FB7FD98AE59, EA-045-R11-RESEARCH, EA-045-R11-WEB-READBACK
UNKNOWN_IDS: EA-045-UNKNOWN-01, EA-045-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
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を別途確認する。

## Current judgment
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を分離する構成である。

## Scope
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を主対象とする。

## Confirmed
- 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としてのみ扱う。

## UNKNOWN
- EA-045-UNKNOWN-01: 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-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-045-URL-410B86123707 (RESEARCH): https://datatracker.ietf.org/doc/html/rfc8693 — https://datatracker.ietf.org/doc/html/rfc8693
- EVD-EA-045-URL-BB55030914BE (RESEARCH): https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/ — https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/
- EVD-EA-045-URL-DF3B07C07473 (RESEARCH): https://spiffe.io/docs/latest/deploying/svids/ — https://spiffe.io/docs/latest/deploying/svids/
- EVD-EA-045-URL-11F2F3599989 (RESEARCH): https://developer.hashicorp.com/vault/tutorials/get-started/understand-static-dynamic-secrets — https://developer.hashicorp.com/vault/tutorials/get-started/understand-static-dynamic-secrets
- EVD-EA-045-URL-7EA0E25B2395 (RESEARCH): and — https://developer.hashicorp.com/vault/docs/secrets/databases
- EVD-EA-045-URL-E6D19CB5649A (RESEARCH): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-idps.html — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-idps.html
- EVD-EA-045-URL-A10EBDAE144A (RESEARCH): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html
- EVD-EA-045-URL-BB7064E0DDAD (RESEARCH): https://datatracker.ietf.org/doc/html/draft-hartman-credential-broker-4-agents-00 — https://datatracker.ietf.org/doc/html/draft-hartman-credential-broker-4-agents-00
- EVD-EA-045-URL-1FB7FD98AE59 (RESEARCH): https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/ — https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/
- EA-045-R11-RESEARCH (RESEARCH): EA-045 監査済みresearch / canonical revision binding
- EA-045-R11-WEB-READBACK (IMPL): EA-045 Web body identity / canonical readback

## Failure / limits
Brokerがsecretを保持していても、最終的にcredential valueをagent
    processへ返す設計ならcontext/log/tool
    subprocessへの漏洩面は残る。可能ならbroker-side injection/proxy
    executionとcredential non-disclosureを区別する。
## Failure / limits
short-lived credentialはstolen
    credentialの有効時間を短縮するが、発行時のidentity/authorizationが誤っていれば誤権限を短時間で正当化するだけである。
## Failure / limits
SPIFFE/SPIREはidentity primitiveでありauthorization policyやupstream
    SaaS scopeを自動的に正しくしない。attestation/selector
    compromiseやpost-exploitation identity misuseをfailure
    envelopeへ含める。
## Failure / limits
OAuth
    scopeが細粒度でないproviderではbroker側policyが細かくてもupstream
    tokenのblast radiusを十分に縮められない場合がある。
## Failure / limits
static API
    keyしか提供しないupstreamでは「短命credentialをmintする」ことが不可能な場合があり、broker-side
    injection、target pinning、request
    policy、rotationで代替する必要がある。
## Failure / limits
token exchange、delegation、impersonation、service/workload
    identityを同義語として扱わない。
## Failure / limits
broker自身は高価値な集中攻撃面になる。root/admin
    credential、encryption key、policy administration、audit
    logの分離とbreak-glass統制が必要。
## Failure / limits
product
    documentationは特定tenantでのentitlement、region、policy、retention、実際のaudit
    completenessを証明しない。
## Failure / limits
EA-045は、既存packet所在確認が未成功であることを保持したうえで、primary/author-maintained
evidenceによるbounded
backfillを完了した。今後は同一内容のフル再研究を行わず、canonical
sync、CB4A/製品更新時のVERSION_REFRESH、独立実運用または安全なTEST_PROFILE追加時のSUPPLEMENT_ONLYとする。

---
## Practice
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を分離する。
## Practice
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標準として確定扱いしない。
## Practice
安全な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では実施しない。
## Practice
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を運用対象にする。
## Practice
EA-043 Agent Identityからverified workload
    identityを入力として受ける。
## Practice
EA-044 Delegated Authorizationからsubject/actor/delegation
    semanticsを受ける。
## Practice
EA-045では credential reference → policy decision →
    issuance/injection → target call → revocation/audit
    のlifecycleを正本化する。
## Practice
EA-046 Gatewayとは「credential policy/secret
    boundary」と「traffic/tool routing
    boundary」を分離し、同一製品でも論理面を混同しない。
## Practice
provider mappingではAWS AgentCore等をimplementation
    exampleとして扱い、common Coreへ逆一般化しない。
## Practice
CB4Aが更新・標準化された場合はVERSION_REFRESHする。
## Practice
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.
## WHY_THIS_MATTERS_TO_UPDATE
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側で注入する統制点として整理する価値がある。

## SCOPE_ROUTING
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を主対象とする。

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

## EVIDENCE TABLE
1.  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.
2.  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.
3.  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.
4.  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.
5.  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.
6.  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.

## FINDINGS
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としてのみ扱う。

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
-   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を証明しない。

## AVAILABILITY_GATES
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を分離する。

## IMPLEMENTATION_STATE
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標準として確定扱いしない。

## BENCHMARK_OR_EVAL
安全な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では実施しない。

## SECURITY
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を運用対象にする。

## SAFE_WORDING_FOR_FUTURE_BOOK
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を別途確認する。

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

## UNKNOWN
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要件。

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

---

## AUDITED_BOUNDARY
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.

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.