Skip to content

fix(mcp): webhook envelope profile falls back to active profile (KLA-420)#39

Open
jklaassenjc wants to merge 1 commit into
mainfrom
juergen/kla-420-webhook-profile-fallback
Open

fix(mcp): webhook envelope profile falls back to active profile (KLA-420)#39
jklaassenjc wants to merge 1 commit into
mainfrom
juergen/kla-420-webhook-profile-fallback

Conversation

@jklaassenjc
Copy link
Copy Markdown
Collaborator

@jklaassenjc jklaassenjc commented May 27, 2026

Summary

KLA-420 — surfaced during the 1.17.0 code-quality review.

In 1.17.0 (KLA-413), server.go wired stepUpConfig.Profile = opts.SigningProfile directly. The signer block beneath it falls back to config.ActiveProfile() when SigningProfile == "", but the webhook path didn't. Result: an operator who enables

```yaml
mcp:
require_step_up_for_destructive: true
step_up_authenticator: webhook
approval_webhook_url: ...
```

without also enabling mcp.sign_destructive_ops gets "profile": "" in every outbound approval envelope. Receivers keying on profile (Slack bot routing, audit dashboards) see empty strings instead of the active profile name.

Fix

Resolve the profile once at the server level, before building both stepUpConfig and the signer:

```go
profile := opts.SigningProfile
if profile == "" {
profile = config.ActiveProfile()
}
```

SigningProfile remains the explicit opt-in; empty means "use the active profile" and now applies uniformly to both consumers.

Tests

  • TestNewServer_WebhookProfileFallsBackToActiveProfile — empty SigningProfile → webhook authenticator profile = "default"
  • TestNewServer_WebhookProfileHonorsExplicitSigningProfile"staging" → webhook authenticator profile = "staging"

Test plan

  • go test ./internal/mcp/ ./internal/cmd/ green
  • go vet ./... clean
  • Both new tests pass; existing webhook + signer tests unchanged

🤖 Generated with Claude Code


Note

Low Risk
Small, localized server bootstrap change with regression tests; no auth or approval-gate logic changes beyond metadata in outbound envelopes.

Overview
KLA-420: Webhook step-up approval envelopes now get the same profile resolution as the destructive-op signer.

NewServer resolves profile once (SigningProfile, or config.ActiveProfile() when empty) and passes it into both stepUpConfig and the signer. Previously only the signer path fell back to the active profile, so webhook-only destructive approval (require_step_up + webhook, without sign_destructive_ops) posted "profile": ""—breaking Slack routing and audit views that key on profile.

Tests assert empty SigningProfile → active profile (default) on webhookStepUp, and explicit SigningProfile → that value unchanged.

Reviewed by Cursor Bugbot for commit 6b7fc55. Bugbot is set up for automated code reviews on this repo. Configure here.

…420)

In 1.17.0, server.go wired stepUpConfig.Profile = opts.SigningProfile
directly. The signer block beneath it falls back to
config.ActiveProfile() when SigningProfile is empty, but the
webhook path didn't. Result: an operator who enables

  mcp:
    require_step_up_for_destructive: true
    step_up_authenticator: webhook
    approval_webhook_url: ...

without also enabling mcp.sign_destructive_ops gets `profile: ""`
in every outbound approval envelope. Receivers keying on profile
(Slack bot routing, audit dashboards) see empty strings instead
of the active profile name.

Fix: resolve the profile once at the server level, before building
both stepUpConfig and the signer. SigningProfile remains the
explicit opt-in; empty means "use the active profile" and now
applies uniformly to both consumers.

Tests:
- TestNewServer_WebhookProfileFallsBackToActiveProfile (empty
  SigningProfile → webhook authenticator profile = "default")
- TestNewServer_WebhookProfileHonorsExplicitSigningProfile
  ("staging" → webhook authenticator profile = "staging")

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jklaassenjc jklaassenjc added bug Something isn't working patch labels May 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working patch

Development

Successfully merging this pull request may close these issues.

2 participants