/**
 * Redirect handling that does not hand provider credentials to a third host.
 *
 * `fetch` defaults to `redirect: 'follow'`. On a cross-origin redirect it strips
 * exactly three headers — `Authorization`, `Cookie`, `Proxy-Authorization` — and
 * replays everything else. This codebase authenticates most providers with
 * headers that are NOT on that list:
 *
 *   - `x-api-key`      (Anthropic, MiniMax)
 *   - `x-goog-api-key` (Google)
 *   - arbitrary `cfg.headers` supplied for custom providers and gateways
 *
 * So a `307` from a configured base URL replayed the user's API key to whatever
 * host the redirect named. A misconfigured or hostile gateway is an obvious
 * route, but so is a compromised CDN in front of a legitimate endpoint (WS-084).
 *
 * The fix keeps the browser's rule and extends it to the headers this codebase
 * actually uses: redirects are followed, but every credential-bearing header is
 * dropped the moment the origin changes. A target that genuinely needs auth then
 * answers 401 — visible and debuggable — instead of silently receiving the key.
 */
export interface RedirectSafeFetchInit {
    method?: string | undefined;
    headers: Record<string, string>;
    body?: string | undefined;
    signal?: AbortSignal | undefined;
}
/**
 * Issue a request, following redirects manually so credentials can be dropped
 * when the origin changes.
 *
 * @param fetchImpl - the injected fetch (tests supply fakes; the network guard
 *   supplies a pinned-lookup dispatcher). Wrapping rather than replacing it
 *   keeps both working.
 */
export declare function redirectSafeFetch(fetchImpl: typeof fetch, url: string, init: RedirectSafeFetchInit): Promise<Response>;
//# sourceMappingURL=redirect-safe-fetch.d.ts.map