Expose agent MCP runtime helpers

[haasonsaas]

Summary

• export bounded async Runner/NewRunner used by agent-mcp background work
• add auth principal context helpers and shared HTTP browser guardrails from the platform runtime surface
• accept the earlier downstream.New(name, policy, config) call shape while preserving Config{FailureMode: ...}
• add managed startup HTTP server helpers required by the public agent-mcp mirror

Validation

• go test ./authmw ./async ./downstream ./httpkit ./startup
• go test ./...
• git diff --check
• agent-mcp mirror build with local replace to this service-runtime branch: go mod tidy && go build ./...

[cursor]

PR Summary

Medium Risk
Touches request authentication context propagation and HTTP server startup defaults, which can impact authorization checks and client compatibility. Also changes downstream.New signature to accept legacy call shapes, so incorrect argument usage will now panic at runtime.

Overview
Adds a bounded background task runner (async.Runner/NewRunner/TryGo) that can reject fire-and-forget work when at capacity, preventing unbounded goroutine growth under load.

Extends authmw.WithAuth to also attach a normalized Principal (with scopes) into request context and adds helper authorization methods like RequireScope/RequireOrganization.

Makes downstream.New accept both the current Config-based constructor and a legacy (policy, config) call shape (plus a FailurePolicy alias), and adds shared HTTP browser guardrails (httpkit.WithBrowserSecurityDefaults) that are applied by the new managed startup.RunHTTPServer helper.

^{Reviewed by Cursor Bugbot for commit 2e4ccad. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Bugbot Autofix prepared fixes for both issues found in the latest run.

• ✅ Fixed: TLS cert and key file paths silently discarded
  • RunHTTPServer now passes the configured cert/key paths into the TLS serve calls and applies TLSClientCAFile to Server.TLSConfig for mutual TLS.
• ✅ Fixed: Case-sensitive service type check inconsistent with human check
  • PrincipalFromActor now treats service actor types case-insensitively so mixed-case service tokens still populate principal.Service.

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 2e4ccad. Configure here.}

[cursor]

TLS cert and key file paths silently discarded

High Severity

cfg.TLSCertFile and cfg.TLSKeyFile are checked to decide whether to enter the TLS branch, but empty strings "" are passed to ServeTLS and ListenAndServeTLS instead of the actual file paths. Unless the caller has pre-populated Server.TLSConfig.Certificates, the server will fail to start with a TLS handshake error. The TLSClientCAFile field is similarly logged but never applied to configure mutual TLS.

Additional Locations (1)

• startup/http.go#L89-L90

 

^{Reviewed by Cursor Bugbot for commit 2e4ccad. Configure here.}

[cursor]

Case-sensitive service type check inconsistent with human check

Low Severity

PrincipalFromActor uses a case-sensitive comparison principal.TokenType == "service" to decide whether to populate the Service field, while isHumanActorType (called two lines earlier on the same actor.Type value) uses strings.ToLower for its comparison. If a TokenVerifier implementation returns an actor with type "Service" or "SERVICE", the principal would not get the Service field set from the Subject, yet isHumanActorType would correctly handle equivalent casing for human/user types.

Additional Locations (1)

• authmw/principal.go#L134-L142

 

^{Reviewed by Cursor Bugbot for commit 2e4ccad. Configure here.}