/**
 * The one place the "publishable key only" rule lives. Every client-side fetch boundary ({@link ../components/location-search.ts}, {@link ./fetch-controller.ts}) calls through here so a secret or legacy unprefixed key is refused identically: no network call, the same visible message, the same `roxy-validation-error` event. Centralising it is what stops the two paths drifting, which is exactly how `<roxy-location-search>` used to warn-then-fetch a secret key while the controller fail-closed.
 */
/** Canonical refusal message. Both fetch boundaries surface this exact wording. */
export declare const KEY_REFUSED_MESSAGE = "Client-side components accept a pk_ publishable key only. Use a publishable key with an origin allowlist, or render server-side.";
/** True when the key is a browser-safe `pk_` publishable key. */
export declare function isPublishableKey(key: string | undefined | null): boolean;
/**
 * The fail-closed condition: a key is PRESENT and is NOT a `pk_` key. An absent key is not refused, so a keyless public call (a form-slotted city search with no key set) still proceeds; only a real secret/legacy token in the browser is stopped.
 */
export declare function keyIsRefused(key: string | undefined | null): boolean;
/**
 * Announce a refused key: dispatch the shared `roxy-validation-error` (bubbling, composed) and, when `warn` is set, log it once for the developer. The caller sets its own visible error state and skips the fetch; this only handles the parts both boundaries share.
 */
export declare function dispatchKeyRefusal(host: EventTarget, opts?: {
    warn?: boolean;
}): void;
//# sourceMappingURL=key-guard.d.ts.map