/**
 * Extract auth claims from incoming HTTP request headers.
 *
 * Used by the standalone HTTP server (Track C closure) to discover which
 * claim bag the per-claim instance pool should key on. Two sources are
 * recognized today, matching what `extractInstance` in the Cloudflare
 * Worker template recognizes — same headers, same precedence:
 *
 *   1. `Cf-Access-Authenticated-User-Email` — set by Cloudflare Access at
 *      the edge after JWT verification. Trusted (origin is behind CF).
 *   2. `Cf-Access-Jwt-Assertion` — the raw JWT. Decoded payload fields
 *      (email, sub, ...) are merged into the claim bag. The signature is
 *      NOT re-verified; CF already validated it before forwarding to the
 *      origin. If you run the standalone server outside Cloudflare and
 *      want a different trust boundary, add a verification step here.
 *
 * The standalone server is the only consumer right now. The MCP daemon
 * pulls claims from its CLI / streamable-HTTP authentication path; the
 * Cloudflare Worker template does its own header read. Keep the three
 * surfaces in sync when adding a new claim source.
 */
import type { IncomingHttpHeaders } from 'node:http';
/**
 * Read claims from CF Access headers. Returns undefined when no
 * recognized auth headers are present so the caller can fall back to the
 * default instance without a bound claim.
 *
 * The returned bag uses lowercased standard claim names (`email`, `sub`,
 * etc.) so `resolveInstanceFromClaims` finds them by their canonical key
 * regardless of the JWT's casing.
 */
export declare function extractClaimsFromHeaders(headers: IncomingHttpHeaders): Record<string, unknown> | undefined;
//# sourceMappingURL=extract-claims.d.ts.map