Docs_archive
A2A ops audit
Source docs/A2A_OPS_AUDIT.md · All_docs
Review document: quality, scalability, maintainability, and alignment with a same-OS deployment (single host or single container). Last update: includes Phase C (configurable RBAC, GET /api/a2a/status, mesh.a2a.* logs, UI Settings, mesh Redis docs).
1. What is solid
2. Remaining limitations (multi-worker)
Everything runs in the same Node process per replica: suitable for "single OS" / one VM / one pod. With multiple workers or replicas:
3. Maintainability
4. Security (brief reminder)
- JSON-RPC requires at minimum the
A2A_JSONRPC_MIN_ROLErole (defaultviewer): in sensitive prod environments, switching tooperatorreduces the attack surface (dashboard viewers can no longer call JSON-RPC). GET /api/a2a/status: viewer+ — exposes configuration (TTL, rate limit, SDK flags), no secrets; acceptable for any user who can open Settings; do not make public without review.- Public agent card: no secrets; sensitive endpoints remain behind auth.
- Ongoing review: A2A extensions (
HTTP_EXTENSION_HEADER), SDK quotas and audit perTHREAT_MODELif present.
5. Summary: "perfect / scalable / maintainable"
- Perfect: no — v1 (stub executor); SDK audit/circuit breaker remain optional on the cluster side.
- Vertically scalable: yes.
- Horizontally scalable: yes for A2A tasks + quota + stable keys (Redis + env); strict audit still requires evolution or
A2A_SDK_AUDIT_ENABLED=false. - Maintainable: yes — A2A modules +
public-status.ts+api/a2a/*routes. - Phase C: good trade-off — policy and observability without over-engineering; the
MESH_V1_DONEchecklist still reflects honest gaps (business transport, DX compose, bus tests).
For the mesh product checklist, cross-reference with MESH_V1_DONE.md, A2A_INTEGRATION.md, and MESH_V1_REDIS_BUS.md.