[uk-ai-resilience] [security] Review reflected CAPI endpoint routing for SSRF/injection risk (#45490, Tier B)

[github-actions]

Finding

PR #45490 introduced reflected CAPI endpoint routing — Claude and Codex engine providers now resolve their API endpoints dynamically via a reflected endpoint source. This opens a new Tier B attack surface with High exposure amplification: if the endpoint reflection source can be influenced by untrusted input, an attacker could redirect LLM API calls to an attacker-controlled server (SSRF) or inject crafted endpoint paths.

Risk Scoring

Dimension	Score	Rationale
Exposure amplification	High	LLM provider endpoints; compromise could intercept model I/O
Patchability	Medium	Requires architectural validation of trust boundary
Detectability	Medium	Endpoint mismatch may not surface in normal observability
Operational fragility	Medium	Wrong endpoint = silent routing failure
Ownership confidence	High	pelikhan active maintainer

Tier: B — Open With Conditions
SLA: High — 7 days

Remediation Actions

1. Audit the source of reflected endpoint values in #45490 — confirm they come from a trusted, static configuration and not user-supplied or workflow-supplied input.
2. Add validation that resolved endpoints match an allowlist of known provider domains (e.g. api.github.com, api.anthropic.com, api.openai.com).
3. Add a test asserting that a crafted/invalid reflection value is rejected before it reaches the HTTP client.
4. Document the trust boundary for reflected endpoints in the engine provider interface.

References

• PR Split engine provider selection from harness execution and route Claude/Codex via reflected CAPI endpoints #45490: Split engine provider selection from harness execution
• Governance report: [uk-ai-resilience] Governance Report 2026-07-15
• Run: §29430209261
• UK AI open code guidance: (www.gov.uk/redacted)

Generated by UK AI Operational Resilience · 51.7 AIC · ⌖ 8.06 AIC · ⊞ 5.1K · ◷