feat(a2a): ship RAG retrieval in the shared image; fix the RAG that was inert in prod

[github-actions]

The defect

FuzeAgent's RAG has been dead in production. Not degraded — dead, while every log line, health probe and endpoint reported success.

Three bugs in services/orchestrator/rag_integration.py, and a fourth that hid the other three:

#	Defect	Effect
1	CHROMA_HOST defaulted to "localhost" and nothing set it in any deployment manifest	the pod dialled itself
2	chroma_client_auth_provider="basic"	Chroma resolves that string as an import path to a provider class, so "basic" resolved to nothing and the client was built unauthenticated while appearing to configure auth
3	chroma_client_auth_credentials=""	even with (2) fixed, it would have authenticated with an empty secret
4	a broad except Exception set collection = None	every search then returned an empty RAGContext — a well-formed "we found nothing" that no caller could distinguish from an empty corpus

(4) is the one that matters. The first three are ordinary bugs. (4) is why they were invisible for months.

The fixes are structural, not corrected literals

• No default for CHROMA_HOST. A default that is wrong but still lets the process start is worse than no default at all.
• The auth providers are dotted class paths held in one constant each, and services/orchestrator/tests/test_rag_provider_parity.py fails if the orchestrator's copy and the A2A copy diverge. The two images cannot import each other — the orchestrator builds with context services/orchestrator, the A2A image with context agent-templates — so the duplication is unavoidable. Leaving it silent is not.
• Unauthenticated access requires CHROMA_ALLOW_UNAUTHENTICATED=1, stated out loud in a values file. An empty credential is never read as "no auth wanted".
• Unreachable raises. /rag/search and /rag/enhance-prompt return 503, not 200-with-no-results.

New: agent-templates/a2a/rag/

Retrieval for the shared A2A server, shipping in ghcr.io/izzywdev/fuze-a2a, off unless the chart enables it.

Retrieval only. Indexing needs the original documents, and a multi-tenant pod must not hold any tenant's document store — FuzeAgent's orchestrator keeps them on a filesystem under KNOWLEDGE_STORAGE_PATH.

And no document database is needed for retrieval either. The open question was whether Mongo or Postgres would be needed to fetch the source when Chroma holds only vectors. Measured: it does not. The indexer stores the chunk text alongside each vector (collection.add(..., documents=text_chunks)) and the query reads it back (include=["documents", …]). A second hop would only be required if Chroma held vectors alone. The document store is for re-indexing and download, not for answering a query.

Isolation is structural:

FuzeInfra Chroma instance
└── database: a2a                 ← allocated to A2A, not the default
    ├── collection: a2a-fuzeagent
    ├── collection: a2a-fuzebi
    └── collection: a2a-<tenant>

Per-tenant collections, not one collection with a where filter — a filter is one forgotten argument away from returning another tenant's chunks; a separate collection cannot be read by omission.

Verification

The chart's guards are verified to fire, not assumed:

Case	Result
enabled + complete config	renders A2A_RAG_ENABLED, CHROMA_HOST, CHROMA_AUTH_TOKEN from the secret ref
enabled, host missing	helm template fails: deploy.rag.host is required when deploy.rag.enabled
disabled (default)	zero CHROMA_* vars rendered
helm lint	0 charts failed

15 new tests for the package, weighted toward asserting it refuses (no host, no database, no credential, two credentials, a bare "basic" provider, unreachable-≠-empty), plus the provider-parity test. 176 pass across agent-templates/a2a.

Note on the main.py diff size

services/orchestrator/main.py shows ~6000 changed lines. That is the CRLF→LF renormalisation this repo's own .gitattributes mandates and gate-line-endings hard-fails without — main.py is one of the 20 known pre-existing CRLF files, and touching it converts it. The semantic diff is 13 insertions, 1 deletion:

git diff --ignore-cr-at-eol -- services/orchestrator/main.py
 services/orchestrator/main.py | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

— the import, and the except RAGUnavailable handler on each of the two endpoints. I checked this specifically because a whitespace-only reformat silently reverting auth hardening has already happened in this repo once.

Blocked, deliberately: deploy.rag.enabled: false

The Chroma service DNS, the a2a database on it, and a scoped auth token delivered as a SealedSecret in the fuzeagent namespace are FuzeInfra allocations. FuzeInfra is never edited from a consuming repo, so that request goes over separately via @claude with the allocation named.

Turning the flag on before those exist does not produce a degraded pod — it produces one that refuses to start. That is the intended behaviour and the whole point of the change.

[izzywdev]

dependency-check is red, and it is not this PR

The failing job scans services/orchestrator/requirements.txt. This PR does not touch that file. The advisories come from chromadb>=0.5.0,<2.0.0 — a floating range that resolves to 1.1.1 today.

chromadb 1.1.1  CVE-2026-45830
chromadb 1.1.1  CVE-2026-45833
chromadb 1.1.1  CVE-2026-45831

The two exceptions ci.yml carries (PYSEC-2026-311, PYSEC-2026-1325) predate these three. This will red every PR in the repo until it is decided, not just this one.

No upstream fix exists — measured, not assumed

I ran pip-audit against eight pins rather than reading the empty "Fix Versions" column and stopping there:

version	advisories
0.4.24	45830, 45833
0.5.23	45830, 45833, 45831
0.6.3	45830, 45833, 45831
1.0.0 → 1.3.0	45830, 45833, 45831, + PYSEC-2026-311

No version is clean. Upgrading cannot fix this and neither can downgrading, so I am not pushing a pin to make the check pass. I am also not adding --ignore-vuln for three advisories I did not assess and whose acceptance is not mine to decide.

What they actually are — and why this matters more than a red check

Two of them are cross-tenant isolation failures in Chroma's server-side authorization:

• CVE-2026-45830 — "lack of authorization validation … allows any authenticated user to arbitrarily read, write, update, or delete data in any tenant's collection regardless of which tenant they belong to" (0.4.17+)
• CVE-2026-45831 — "SimpleRBACAuthorizationProvider … evaluates whether a user holds a given permission but never checks which tenant, database, or collection that permission applies to" (0.5.0+)
• CVE-2026-45833 — code injection via trust_remote_code on a collection update, requiring UPDATE_COLLECTION

That lands directly on this PR's design, which is why I chased it rather than just reporting a red job. The isolation claim here — per-tenant collections inside a dedicated database — would be worthless on stock Chroma, because those two CVEs say stock Chroma does not enforce the tenant boundary at all.

It holds here for a reason that was implicit and is now written down (937ecaf): FuzeInfra does not use the built-in provider. helm/fuzeinfra/templates/chroma-authz.yaml ships TenantDatabaseAuthorizationProvider, which resolves the immutable collection UUID in SysDB instead of trusting the request's tenant/database — its own comment says it "prevents a token from using a known collection UUID to cross an allocation boundary" — and the provisioning job then verifies the denial by attempting a foreign-tenant write with each token.

So the mitigation for the two isolation CVEs is already deployed, and it is tested. docs/a2a/rag.md now says so explicitly, because a confident boundary claim that silently depends on someone else having replaced a CVE'd component is exactly the kind of thing that survives until the component is swapped back.

What I think should happen — owner's call, not mine

The exposure is server-side, and the server FuzeInfra runs is chromadb/chroma:0.5.23 with the stock authorization provider replaced. The Python package failing this scan is a client dependency; it is not running the vulnerable endpoints. That is the same shape of reasoning test.yml already uses for PYSEC-2026-311 ("uses chromadb.HttpClient() … never serves the vulnerable endpoint") — and PYSEC-2026-311 is additionally 1.0.0+, which 0.5.23 is not.

If that reasoning holds for these three, the honest resolution is a documented exception with the same rationale block the existing two carry, plus pinning the floating range so the gate stops being non-deterministic. Both are security decisions and belong to security / the owner, not to a PR about A2A retrieval — so I have not made them here.

Tracked as the pre-existing item "3 unfixable chromadb CVEs + a floating pin that makes the gate non-deterministic". Everything else on this PR is green as far as it has run; say the word and I will open the exception + pin as its own PR.

---

Generated by Claude Code