Description

Today, when a Harness pipeline is triggered through the API using a service account token, the pipeline execution is attributed to the service account. This is expected for automation, but it creates an audit gap for organizations where a trusted external system authenticates real users and then triggers Harness deployments on their behalf.

Request: provide a supported API-level delegated attribution model for pipeline executions triggered by service accounts.

The desired capability would allow a trusted service account to pass a verified end-user identity, such as an email or Harness user identifier, when calling the pipeline execute API or custom webhook endpoint. Harness would then display the execution as being requested/executed by that end user, or clearly show the execution as performed by the service account on behalf of that user.

Example desired display:

Executed by: user@example.com

Triggered via: deployment-service-account

or

Executed by: deployment-service-account on behalf of user@example.com

This should not simply overwrite audit history. The audit record should preserve both identities:

* the authenticated automation principal/service account that made the API call;

* the delegated/requesting end user from the trusted external system.

Use Case

An enterprise uses an external deployment portal or internal platform where users are already authenticated and authorized. That system calls the Harness API using a service account token to trigger a CD pipeline.

For audit/SOX compliance, the deployment record in Harness needs to identify the real user who requested the deployment, not only the service account used by the external automation layer.

Requested Behavior

Add a supported field, header, or property to the pipeline execute API and/or custom webhook flow, such as:

The feature should allow customers to pass a verified user identity for display and audit attribution.

Why This Matters

For regulated environments, deployment audit records need to answer both:

Today, customers can pass the requester as a pipeline variable or metadata field, but that does not update the native Harness “Executed by” / execution history attribution. A first-class delegated attribution model would make API-triggered deployment records more useful for compliance, SOX evidence, and audit review.