You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Credential broker: a successful brokered call leaves no record, although the spec promises "an audit of every use" #4652
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
github-actions commentedon Oct 15, 2026
Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.
What happens next:
Triage labels:
triage:accept-feature— accepted as a new featuretriage:accept-bugfix— accepted as a bug fixtriage:needs-info— more information neededtriage:wontfix— will not be addressedtriage:duplicate— duplicate of another issue