Knowledge base · TOPIC-04

HTTP 401 or 403 from an AI service: authentication or connectivity?

Short answer: A genuine HTTP 401 or 403 is not the same as “the network cannot reach the service.” It shows that an HTTP responder was reached, while the status describes an authorization decision. It does not prove successful login, entitlement, or end-to-end product health.

The protocol meaning

RFC 9110 defines 401 Unauthorized as a response saying the request lacks valid authentication credentials for the target resource. It defines 403 Forbidden as a response where the server understood the request but refuses to fulfill it. Both are valid HTTP responses.

That means a measured 401/403 can be observed evidence that resolution, a connection, TLS, and an HTTP exchange completed to some responder. The response may still come from an intermediary, security gateway, or challenge layer, so the exact origin and application state require separate evidence.

What it proves—and what it does not

It may prove:

  • an HTTP status was received rather than a timeout;
  • the preceding network/TLS stages completed for that request;
  • the request encountered an authentication or policy boundary.

It does not prove:

  • the credentials are correct;
  • the account is entitled to the product;
  • the whole provider is healthy;
  • a streaming or WebSocket workflow will work;
  • the responder is necessarily the final application origin.

Safe checks

  1. Capture only the status class, timestamp, TLS outcome, and approved diagnostic headers. Never record an Authorization or Cookie value.
  2. Distinguish HTTP response received from application access approved in the report.
  3. Confirm that the endpoint is approved for anonymous measurement. Do not use private or undocumented provider URLs.
  4. Compare official provider status and the actual authenticated workflow, without turning either into proof of the other.
  5. If the response contains an authentication challenge, follow the provider’s normal sign-in flow; do not retry credentials through a diagnostic tool.

Tivor’s perspective

Tivor represents a measured 401/403 as an HTTP response plus challenge or incomplete semantics when appropriate. This product behavior follows the public RFC semantics; it does not claim that every 401/403 is benign, and it never treats missing credentials as permission to collect them.

Verify

After the normal authentication or policy issue is resolved, repeat the same approved request and the real user workflow. Verify each result independently. If the HTTP response remains reachable but the product fails, continue with product-specific evidence rather than blaming the network.