Skip to content

Credential broker: a successful brokered call leaves no record, although the spec promises "an audit of every use" #4652

Open

Description

@WilcoLouwerse

Summary

The Purpose of openspec/specs/credential-broker/spec.md says apps act through OpenRegister "with per-app scoping, central revocation and an audit of every use". In CredentialBrokerService only refusals and failures are logged:

  • deny() (:1529) logs a warning.
  • performCall() (:1382) logs an error on a transport failure.
  • The success path of request() (:232 to :300) writes no log line, no audit-trail entry and no event.

After the fact, nobody can tell which app called which provider path with which credential, and on whose behalf.

Proposed

On every completed brokered call, record a secret-free entry: timestamp, calling app id, acting user (or system), credential id, provider, method, the canonical path (no query values, which may carry tokens or PII), response status and duration. Record it in OpenRegister's audit trail (ADR-003) or as a typed event an audit listener can store. Decide whether reads are sampled or always recorded, and the retention period. The credential's owner can then see the use of their own credential.

Done when

  • A brokered call that succeeds produces exactly one audit entry with the fields above, and no secret or query value appears in it (test).
  • The spec gains a requirement with a scenario for the success path, so the Purpose sentence is backed by a requirement.

Found during the persistence audit in the review of #4642 (archive of github-provider-code-search). This is pre-existing, not introduced by that PR.

Activity

  1. github-actions commented on Oct 15, 2026

    @github-actions
    Contributor

    Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

    What happens next:

    1. A maintainer will review this issue and determine the appropriate action
    2. If accepted, it may be converted into an OpenSpec change for structured development
    3. You will be notified of any status changes

    Triage labels:

    • triage:accept-feature — accepted as a new feature
    • triage:accept-bugfix — accepted as a bug fix
    • triage:needs-info — more information needed
    • triage:wontfix — will not be addressed
    • triage:duplicate — duplicate of another issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

securityA user can read or write what they must nottriageAwaiting triage

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions