Limiting incoming webhook pipeline runs

Hi folks, I have a simple wishlist item for you- it'd be great if we could limit which pipelinerun files an incoming repository webhook-url could trigger. We currently have a repository that services multiple teams using different pipelines and pipelineruns, and it'd be nice to lock down those incoming webhooks a bit more; from the repository side, implementation could look like this:

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: my-repo
spec:
  incoming:
    - pipelineruns:
        - basic-pr
        - team-a-specific-pr
      secret:
        key: secret
        name: team-a-incoming-secret
      targets:
        - main
      type: webhook-url
    - pipelineruns:
        - basic-pr
        - team-b-specific-pr
      secret:
        key: secret
        name: team-b-incoming-secret
      targets:
        - main
      type: webhook-url
  url: 'https://github.com/owner/my-repo'

This would allow greater access control for which secrets could run which pipelineruns; e.g.

# Team A running basic-pr
curl -X POST 'https://pipeline-controller.example.com/incoming?secret=team-a-secret&repository=my-repo&branch=main&pipelinerun=basic-pr'
# Team B running basic-pr
curl -X POST 'https://pipeline-controller.example.com/incoming?secret=team-b-secret&repository=my-repo&branch=main&pipelinerun=basic-pr'
# Team A running team-a-specific-pr
curl -X POST 'https://pipeline-controller.example.com/incoming?secret=team-a-secret&repository=my-repo&branch=main&pipelinerun=team-a-specific-pr'
# Team B running team-b-specific-pr
curl -X POST 'https://pipeline-controller.example.com/incoming?secret=team-b-secret&repository=my-repo&branch=main&pipelinerun=team-b-specific-pr'

# Team A FAILING to run team-b-specific-pr
curl -X POST 'https://pipeline-controller.example.com/incoming?secret=team-a-secret&repository=my-repo&branch=main&pipelinerun=team-b-specific-pr'

Are there any thoughts/concerns/considerations with this?

The issue names no source files or tests. Start by tracing the Repository incoming configuration and the /incoming webhook entry point, then compare secret validation with the requested PipelineRun allow-list behavior. Done means each configured secret can trigger only its listed PipelineRuns, with the successful and rejected curl cases covered by tests.