AI Agent Marketplace：工具认证与治理架构
AI agent marketplace 不是服务目录，也不是把 internal tools 放进一个漂亮页面。它是一套 permissioned capability platform：把 agent、tool、prompt、MCP server、API、RAG corpus、workflow 和 eval pack 都当作可治理的业务能力，要求它们在被发现之前先被描述，在被复用之前先被认证，
AI Agent Marketplace / Tool Certification Governance Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_AGENT_MARKETPLACE_TOOL_CERTIFICATION_GOVERNANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
重要说明: 本文只讨论企业内部 AI agents、tools、prompts、MCP servers、APIs、RAG capabilities 和 reusable workflows 的平台治理架构，不构成法律、合规、网络安全认证、审计、采购、供应商准入或监管结论。真实项目必须由 AI Governance、Enterprise Architecture、Cyber Security、Privacy、Data Governance、Model Risk、Third-Party Risk、Legal、Compliance、Internal Audit、Platform Engineering、API/Product Owners 和业务负责人共同确认。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| OWASP Top 10 for LLM Applications | https://genai.owasp.org/llm-top-10/ | 用 prompt injection、sensitive information disclosure、excessive agency、insecure output handling、supply chain 等风险语言定义 agent/tool marketplace 的 threat-informed certification baseline |
| CISA Secure by Design | https://www.cisa.gov/securebydesign | 用 secure-by-design、默认安全、可证明控制和供应商责任语言设计 signed packages、owner attestation、secure defaults 和 marketplace admission gate |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 marketplace risk tier、evaluation evidence、monitoring、risk acceptance 和 lifecycle review |
| ISO/IEC 42001 overview | https://www.iso.org/standard/42001 | 用 AI management system、policy、roles、operation、performance evaluation、internal audit 和 continual improvement 组织 operating model |
| OpenAPI Specification | https://spec.openapis.org/oas/latest.html | 用 contract-first API specification、schema、security scheme、operation metadata 和 versioning 支持 tool/API certification |
| AsyncAPI Specification | https://www.asyncapi.com/docs/reference/specification/latest | 用 event-driven contract、message schema、channel、binding 和 consumer/producer boundary 支持 agentic event tools 与 asynchronous capabilities 的认证 |
核心导读
AI agent marketplace 不是服务目录，也不是把 internal tools 放进一个漂亮页面。它是一套 permissioned capability platform：把 agent、tool、prompt、MCP server、API、RAG corpus、workflow 和 eval pack 都当作可治理的业务能力，要求它们在被发现之前先被描述，在被复用之前先被认证，在被调用时受到权限和策略约束，在退役时能够切断依赖和迁移消费者。
AI 真正改变的是企业能力复用的决策链。过去 API catalog 主要支持“谁提供、如何调用”；agent marketplace 还要支持“这个能力会不会产生 side effect、能否被其他 agent 安全组合、当前调用是否符合目的和授权、失败后能否回滚、事故后能否证明当时用的是哪个版本”。在金融零售中，这条链可能连接退款、投诉处理、欺诈调查、账户限制、客户通知和监管记录，任何一个 capability 的描述不完整，都会在组合调用时放大成业务伤害。
学习这个主题时，重点不是 marketplace UI，而是 capability control plane：risk tiering、owner attestation、signed provenance、contract-first specification、eval evidence、runtime entitlement、approval gate、invocation ledger 和 deprecation path 是否形成闭环。治理边界也必须清楚：认证只能证明某个版本在某个用途和控制集合下可用，不能把高风险业务决定外包给 marketplace；当 capability 影响资金、信用、账户状态或客户权利时，仍需要业务 owner、合规 owner、人工审批和可审计证据共同约束。
问题定义
企业内部 agent ecosystem 会快速从若干试点扩展为可组合能力网络：complaint response agent、fraud investigation copilot、case update tool、refund request API、MCP connector、prompt bundle、RAG index、event stream、eval pack、guardrail service。普通 service catalog 只能回答“有什么服务、谁负责、如何申请访问”。Agent marketplace 必须继续回答：
这个 capability 能让 agent 做什么?
会访问哪些数据、产生哪些 side effects?
谁是 owner，谁证明它仍可信?
哪些风险 tier 已认证，证据在哪里?
运行时 token 是否真的被 scope 限制?
哪个 signed package / spec / prompt / tool version 被调用?
谁在何时用哪个 agent 对哪个数据执行了什么动作?
deprecated 或 compromised 时如何停止调用并迁移消费者?
金融零售的风险更高，因为 tool side effects 可能影响客户资金、信用、投诉、欺诈冻结、费用减免、KYC/AML、客户通知和合规记录。Agent 会组合工具、重试、生成参数、读取 RAG 内容，也可能被 prompt injection 引导越权。
核心原理/方法
第一条原则：marketplace card 必须能驱动 runtime policy。不能约束调用的 catalog 只是文档。
第二条原则：certification 必须覆盖 agentic behavior，而不只是代码质量。普通 API 安全评审不足以证明 prompt injection、tool misuse、excessive agency、unsafe chaining、fallback path 和 side-effect reversibility 已被控制。
第三条原则：capability risk 是组合风险。一个 read-only customer lookup tool 单独可能是 Tier 2；当它与 message-sending、refund、account restriction 或 case closure tool 链接时，workflow risk 可能变成 Tier 4。
第四条原则：signed provenance 是审计基础。agent runtime 使用的是 prompt、tool wrapper、MCP server、OpenAPI spec、AsyncAPI channel、RAG corpus manifest、eval pack、guardrail config 和 workflow graph 的组合；没有 hash 和 release attestation，事故后只能靠叙述。
系统/架构模型
参考架构：
provider submits capability
-> capability card and contract validation
-> risk tier classification
-> security, data and side-effect review
-> eval / red-team / policy evidence review
-> owner attestation and signed package
-> marketplace publication
-> consumer use-case attestation
-> runtime entitlement and scoped token issuance
-> tool / MCP / API gateway policy enforcement
-> invocation ledger and monitoring
-> renewal, exception, deprecation and exit management
能力类型不能被压扁成“服务”：
| Capability type | 示例 | 认证重点 |
|---|---|---|
| Agent product | claims triage agent、onboarding agent、complaint assistant | use case、autonomy、human oversight、eval、business owner |
| Tool / function | create_case、lookup_customer、refund_fee、send_message | schema、scope、side effect、idempotency、approval |
| Prompt / policy bundle | system prompt、regulated response prompt、refusal policy | source of truth、versioning、test cases、forbidden behavior |
| MCP server / connector | ticketing、document repository、data warehouse connector | resource boundary、server identity、tool manifest、audit log |
| API product | OpenAPI-described REST capability | contract、auth scheme、rate limit、error semantics、versioning |
| Event capability | AsyncAPI-described stream / command channel | message schema、retention、ordering、producer/consumer boundary |
| RAG / knowledge asset | curated corpus、vector index、knowledge graph | lineage、ACL、freshness、citation、purpose constraint |
| Eval / guardrail asset | prompt injection suite、PII redaction、policy checker | coverage、thresholds、bypass rule、monitoring |
关键机制与取舍
Capability card 是平台的核心产品对象，应同时适合人读和机器执行。
| Section | 必须回答 |
|---|---|
| Identity | capability id、type、owner、steward、domain、version |
| Purpose | intended use、non-goals、business process、customer impact |
| Risk tier | data sensitivity、side effect、autonomy compatibility、regulated workflow flag |
| Contracts | OpenAPI / AsyncAPI / MCP manifest / prompt bundle / eval pack references |
| Inputs/outputs | schema、data class、allowed/prohibited fields、retention expectations |
| Permission scopes | action、data boundary、environment、identity、time、volume、purpose、approval |
| Invocation controls | approval、dual control、rate/spend/transaction limit、safe-stop |
| Evaluation evidence | prompt injection、tool misuse、policy compliance、red-team cases |
| Provenance | signed package、source repo、build attestation、dependency/SBOM or AI BOM |
| Telemetry | traces、audit events、metrics、alerting、log retention、evidence export |
| Lifecycle | certification date、renewal、deprecation、replacement、exit support |
Risk tiering 不是标签工程，而是控制差异化：
| Tier | Pattern | Required posture |
|---|---|---|
| Tier 0 | static reference、doc、sample prompt | peer review、no production invocation |
| Tier 1 | low-sensitivity read-only | owner attestation、schema validation、basic eval |
| Tier 2 | sensitive read | data steward approval、ABAC、prompt injection testing、evidence logging |
| Tier 3 | controlled write/action | human approval、rollback、rate limits、strong eval、periodic review |
| Tier 4 | money movement、account restriction、credit/insurance/investment impact、customer notice | dual control、segregation of duties、model risk review、command gate、incident drill |
关键取舍：
| Decision | 推荐边界 |
|---|---|
| sandbox assets 是否可见 | 可以可见，但必须和 production runtime 隔离，搜索默认不混淆 |
| central board vs delegated certification | 低风险 delegated，高风险和例外进入 central governance |
| gateway 是否 mandatory | production agentic invocation 必须经 governed gateway 或等效强控制 |
| broad app access vs capability scope | 按 action、data、purpose、identity、environment、approval scope 授权 |
| eval 复用 | shared baseline eval 覆盖通用风险，本地 eval 覆盖业务伤害 |
| exception | 必须有过期时间、owner、compensating controls 和 evidence |
证据与控制
运行时模型：
agent request
-> identity and delegation context
-> marketplace entitlement check
-> policy decision point
-> tool / MCP / API gateway
-> schema and parameter policy validation
-> approval or dual-control gate
-> execution
-> invocation ledger and evidence export
Invocation evidence schema：
| Field | 说明 |
|---|---|
| invocation_id | unique tool/capability call id |
| agent_id / workflow_run_id | calling agent or workflow |
| human_delegator_id | human user or approver where relevant |
| capability_id / version | marketplace record |
| artifact_hash | signed package / prompt / spec hash |
| risk_tier_effective | isolated tier plus composition tier |
| scope_granted / scope_used | 授权范围与实际使用 |
| purpose_code | declared business purpose |
| policy_decision | allow、deny、step-up、draft-only、dual-control |
| input_schema_result | validation outcome |
| data_objects | data categories or object references |
| side_effect | record updated、message drafted/sent、refund created |
| approval_packet_id | human or dual-control evidence |
| trace_export_status | complete、partial、failed |
控制矩阵：
| Control objective | Control activity | Evidence |
|---|---|---|
| 防止 unsafe discovery | 搜索按 risk tier、environment、certification、eligibility 过滤 | search policy、publication status、eligibility logs |
| 明确 ownership | 每个 capability 有 owner、steward、support、attestation | owner record、support SLA、renewal record |
| 限制 agentic action | gateway enforce scopes、approval、limits、purpose binding | policy decision log、token scopes、approval packet |
| 保护敏感数据 | field allowlist、ABAC、classification、retention | data map、steward approval、access logs |
| 测试 prompt/tool misuse | adversarial eval and tool-call scenario testing | eval run id、test cases、pass/fail evidence |
| 建立 provenance | production artifacts signed and traceable | signature、hash、release manifest |
| 安全变更 | breaking change 触发 consumer impact and recertification | change record、consumer inventory |
| 支持 deprecation | block new adoption、notify consumers、migration path | deprecation notice、shutdown record |
金融零售/AI产品场景
- Complaint case update tool：agent 只能 draft 或提交内部 disposition；每次 write 需要 assigned-case authorization 与 human approval，禁止自动 refund、关闭 regulatory complaint 或发送客户通知。
- Fraud investigation copilot：可读取 case evidence、transaction graph 和 policy snippets；不能单独冻结账户、联系客户或 file report。
- Fee refund capability：属于高 side-effect tool；需要金额上限、双人审批、政策理由、客户沟通模板和 evidence ledger。
- Customer messaging tool：draft 与 send 分开授权；complaint、collections、fraud、adverse-action-like 内容必须进入 approved content guardrails。
- MCP document connector：每个 exposed tool 都应作为 capability 认证，而不是把整个 server 当成一项泛化权限。
- RAG policy corpus：索引本身也需要 owner、source lineage、freshness、ACL、citation 和 deprecation 控制。
反模式
| 反模式 | 后果 | 更好的设计 |
|---|---|---|
| Marketplace 变成链接目录 | unsafe assets 看起来像官方能力 | 只有 card、tier、evidence、runtime path 完整才发布 |
| Certification 与 gateway 脱节 | slide approval 无法约束 token | certification 绑定 entitlement and policy enforcement |
| Tool provider 不描述 side effect | agent chain 产生非预期动作 | side-effect taxonomy、reversibility、approval model |
| 一次批准永久有效 | stale prompt/source/model/endpoint 持续运行 | renewal cadence and change triggers |
| broad service accounts | attribution weak, over-permission | agent identity + delegated user + scoped token |
| eval theater | 只有 happy path 测试 | threat-informed eval + business harm scenarios |
| 无 consumer inventory | incident/deprecation 无法触达 | entitlement graph + invocation graph |
| audit 手工拼证据 | 监管/内审响应缓慢 | evidence-by-design invocation ledger |
最终心智模型
Agent marketplace 的本质是 agentic capability control plane。它必须把 discovery、certification、provenance、permission、runtime enforcement、telemetry、ownership、exception、renewal 和 deprecation 串成一条证据链。成熟系统不是让团队“更快找到工具”，而是让企业能证明：每个可复用 agentic capability 在被正确描述、正确认证、正确授权、正确调用、正确监控，并在信任过期时能被安全退役。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。