Custom Webhook triggers support header conditions to authenticate inbound requests, but a secret expression (e.g. referencing a stored secret by name) used as the expected value in a header condition does not resolve at trigger-firing time. It evaluates to a literal null instead of the secret's actual value, so any header condition written this way can never match, and the event is silently rejected after the initial 200 acknowledgment.

Today, the only workaround is to either move the check into the first pipeline step (which requires letting the pipeline start before authenticating) or hardcode the literal secret value directly into the trigger's header condition, which defeats the purpose of storing it as a secret in the first place, and only works if the sending system supports a custom header name.

Support resolving secret expressions when they're used as the comparison value in a Custom Webhook trigger's header condition, so a webhook can be authenticated at the trigger level using a securely stored secret, before a pipeline execution is created.

Many third-party systems that send custom webhooks (for example, experimentation or feature-flag platforms) sign or authenticate their webhook deliveries with a fixed header name and a shared secret value, and don't support arbitrary custom header names. Without secret resolution at the trigger level, teams integrating these systems with Harness triggers are forced to either expose the secret value in plaintext inside the trigger configuration, or push authentication logic into the pipeline itself, which still executes (and consumes build minutes) before the request is verified.

A webhook sender delivers a request with a fixed header (e.g. ). The trigger's header condition is configured to compare this header against a stored secret's value. The condition never matches because the secret expression resolves to null at evaluation time, so the trigger event is always rejected, even though the header value sent is correct and verified byte-for-byte against what's configured.

Hardcoding the literal secret value into the header condition works around the resolution gap but reintroduces the exact problem secrets exist to prevent: a sensitive credential stored in plaintext inside the trigger configuration. Moving authentication into the pipeline instead means unauthenticated requests already trigger a pipeline execution, which is both a security gap and a wasted resource cost.