Skip to content

fix(credentials): validate consuming tool provider compatibility - #7623

Open
BillLeoutsakosvl346 wants to merge 1 commit into
stagingfrom
fix/platform-credential-provider-compatibility
Open

fix(credentials): validate consuming tool provider compatibility#7623
BillLeoutsakosvl346 wants to merge 1 commit into
stagingfrom
fix/platform-credential-provider-compatibility

Conversation

@BillLeoutsakosvl346

Copy link
Copy Markdown
Contributor

Summary

  • Validate ordinary OAuth and service-account credentials against the consuming registered service before minting, refreshing, or returning a tool token.
  • Reuse provider compatibility metadata, preserving shared service accounts and alternate authorization providers; retain existing actor/workspace checks and credential-kind restrictions.
  • Keep legacy tools working through exact canonical block ownership and unambiguous declared service IDs. Reject unknown or ambiguous tool bindings without guessing.
  • Leave managed OAuth, non-tool token consumers, auth enums, and product integrations unchanged.

Validation

  • 195 focused tests passed across token resolution, token route, executor credential wrapper, and OAuth utilities.
  • App type-check, changed-file Biome, API validation, and git diff --check passed.
  • Read-only registry audit: all 57 metadata-less credential tools have an unambiguous declared service; every declared OAuth provider resolves.

Two existing files changed; no generated artifacts.

@vercel

vercel Bot commented Sep 8, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated
docs Skipped Skipped Sep 8, 2026 11:26pm UTC

Request Review

@greptile-apps

greptile-apps Bot commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

The PR appears safe to merge, with no concrete correctness, security, or repository-rule violations identified.

Summary

  • Resolves compatibility through registered OAuth service metadata, including alternate OAuth providers and shared service-account providers.
  • Preserves a fail-closed fallback for legacy tools using exact block ownership and unanimous declared service IDs.
  • Adds focused coverage for compatible and incompatible providers, credential-kind restrictions, authorization ordering, and ambiguous legacy bindings.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Credential token request] --> B[Resolve credential identity]
    B --> C{Managed OAuth?}
    C -->|Yes| D[Managed delegation and scope policy]
    C -->|No| E[Authorize actor and workspace access]
    E --> F{Credential kind}
    F -->|Service account| G[Resolve consuming tool service]
    F -->|OAuth| G
    G --> H{Provider and kind compatible?}
    H -->|No| I[Return CREDENTIAL_TOOL_MISMATCH]
    H -->|Yes, service account| J[Mint service-account token]
    H -->|Yes, OAuth| K[Load and refresh OAuth credential]
Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant