feat(product): identify this crate's backend traffic as opencompany - #513
1 finding
The prior finding (product header on hub_identity's /auth/me) is fixed in this diff. The new commits add product-identity tagging to HostedProvider::invoke and request_plan in src/harness/provider.rs, with tests for both. One concern: invoke adds the header unconditionally while request_plan gates it on provider == "managed" only — if HostedProvider is ever used for a non-managed provider, the unconditional header in invoke leaks the product identity to a third-party endpoint, defeating the careful guard in request_plan. The two code paths need to be reconciled. A secondary concern is a possible duplicate header when both paths add it for the managed case. (1 earlier finding(s) still open) The code index is behind this pull request (indexed at 8b2bf54ac08a), so retrieved context may be out of date.
| Finding | Where | |
|---|---|---|
 |
Verify HostedProvider is never used for third-party providers | src/harness/provider.rs:674 |
 Verify HostedProvider is never used for third-party providers
src/harness/provider.rs:674
[RULE] Return Result<T> using the crate error type from src/error.rs.
The PR adds the product-identity header unconditionally to every request HostedProvider::invoke makes, with a comment asserting it "always speaks to the TinyHumans-owned managed endpoint." But the same file's request_plan function carefully gates the same header on decl.provider == "managed" only, explicitly excluding openrouter, openai_compatible, and ollama as third-party BYOK endpoints that must never see the product identity. If HostedProvider is ever constructed for one of those non-managed providers — and HostedProviderConfig.base_url is clearly configurable rather than pinned to DEFAULT_TINYHUMANS_INFERENCE_URL — the unconditional .header() in invoke defeats the third-party guard in request_plan and leaks x-sdk-name: opencompany to an external operator. The two code paths disagree about which providers HostedProvider serves, and one of them is wrong. If HostedProvider truly only serves managed, the request_plan branch for managed is redundant with invoke's unconditional header (and would duplicate it if extra_headers is populated from request_plan's output). If it serves other providers too, the unconditional header is a privacy leak.
Fixed since the last review
- Cover the product header on hub_identity's /auth/me call — fixed. The first diff adds
.header(product_header_name, product_header_value)to the/auth/meGET inHttpHubIdentityExchange::identify.