/**
 * Environment policy for child processes that may execute UNTRUSTED code.
 *
 * `filterDangerousEnvVars` is a deny-list of exec-hijack names (NODE_OPTIONS,
 * LD_PRELOAD, …). It strips no secret and no credential, so a caller that holds
 * production secrets in `process.env` and spawns with it hands every one of them
 * to the child. That is correct on an operator's laptop — the child is the
 * operator's own code, running as the operator — and wrong in a multi-tenant
 * worker, where the child is a customer's `infrastructure.ts`, their
 * `node_modules/typescript`, or their `npm` install scripts.
 *
 * The two cases cannot share a default, so the policy is REQUIRED at every seam
 * that builds a child environment: an absent policy would silently select the
 * permissive one, and no gate in either repository would fire.
 */
/**
 * How a child process inherits its parent's environment.
 *
 * - `inherit` — the parent's environment minus the exec-hijack deny-list. The
 *   child is trusted to the same degree as the parent. `reason` records why,
 *   so the choice is visible at the call site rather than defaulted into.
 * - `isolate` — an ALLOW-LIST. Only names the child demonstrably needs survive;
 *   everything else, secrets included, is dropped. `extraAllowed` admits names a
 *   specific caller must add; it never re-admits a name on the never-list.
 */
export type ChildEnvPolicy = {
    kind: "inherit";
    reason: string;
} | {
    kind: "isolate";
    extraAllowed?: readonly string[];
};
/**
 * Names an isolated child may read. Anything absent is dropped, so this list is
 * the contract: a child that needs a new name gets it added here (or via
 * `extraAllowed`) rather than by widening the policy.
 */
export declare const CHILD_ENV_ALLOWED_NAMES: ReadonlySet<string>;
/**
 * Names an isolated child may NEVER read, even via `extraAllowed`.
 *
 * The ECS entries are the reason this list exists rather than being folded into
 * "absent from the allow-list": they are how the container runtime hands a task
 * its OWN role credentials. A customer child that reads
 * `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` fetches the deploy worker's
 * production identity from 169.254.170.2 — a strictly larger prize than any
 * single secret in the environment, and one no amount of secret-scrubbing
 * removes. The web-identity pair is the same hazard on the IRSA and GitHub-OIDC
 * lanes.
 */
export declare const CHILD_ENV_NEVER_NAMES: ReadonlySet<string>;
/**
 * For a `CdkArgumentBuilder` constructed purely to build argv — it never calls
 * `buildCdkEnv`, so the policy is never consulted. Named rather than inlined so
 * the reader can see the constructor argument is deliberate, and `isolate` so a
 * future call to `buildCdkEnv` on such a builder fails safe rather than open.
 */
export declare const ARGV_ONLY_ENV_POLICY: ChildEnvPolicy;
/**
 * Build the environment for a child process under an explicit policy.
 *
 * `overrides` are applied after the policy and are NOT filtered — they are the
 * caller's own deliberate writes (the credentials it just minted, the stage it
 * resolved), not inherited ambient state. Under `isolate` the never-list is
 * re-applied afterwards, so an override cannot reintroduce the task-role seam.
 *
 * The never-list does NOT apply under `inherit`: it carries `AWS_PROFILE` and
 * the web-identity pair, which are exactly how an operator's laptop finds its
 * identity. Removing them there would break every profile-based deploy to fix
 * nothing — under `inherit` the child is already as trusted as the parent.
 */
export declare function buildChildEnv(policy: ChildEnvPolicy, source: NodeJS.ProcessEnv, overrides?: NodeJS.ProcessEnv): NodeJS.ProcessEnv;