[scale-ballen]

What

GET /agents?agent_card_metadata={"skill":"x\u0000"} returns 500. This makes it a 400, like every other malformed value of that parameter.

Why

\u0000 is valid JSON. json.loads decodes it to an ordinary str, so it sails through _parse_agent_card_metadata — but a PostgreSQL text value cannot hold a NUL. The driver only discovers that while encoding the JSONB bind parameter, and raises asyncpg.exceptions.UntranslatableCharacterError from inside the query, past every specific exception handler and into the catch-all.

_parse_agent_card_metadata already exists to catch exactly this class of input — values Python's json accepts but PostgreSQL will not store: NaN, Infinity, floats that overflow to infinity, integers past CPython's conversion limit. NUL was the one remaining hole in that guard.

Caller error reaching the catch-all handler is bad on its own terms: it burns error budget, pages on the wrong signal, and writes a driver-level stack trace to the logs for what is just a bad query string.

How

_reject_nul_bytes walks the decoded object — keys, values, nested dicts, nested lists — and the parser turns a hit into a 400 with the same shape as the existing rejections.

Tests

test_list_agents_agent_card_metadata_nul_byte_returns_400, parametrized over the NUL in a value, in a key, inside a list and inside a nested object.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge.

Summary

Rejects decoded NUL characters in agent_card_metadata before the database query, returning HTTP 400 instead of 500.

• GET /agents returns 400 for NUL characters in metadata filters.

_{Reviews (4) · Last reviewed commit: "Merge branch 'main' into sec/agent-card-..." · Reviewed by Greptile}