No material or high-risk concern was identified in this review.
This advisory report describes what the named tools and contextual reviewer found at one exact commit. Unknown or unobserved behavior may still exist.
0 high0 material4 low
What this review found
No material or high-risk item was identified.
Expected scanner matches (2)
Gitleaks reported jwt
Expected behavior · high confidence
This is a public app identifier for JanitorAI's login system, not a private password or user token. It is normal for this kind of key to be visible in the code, and it only tells the login service which app is asking for access.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule jwt in this repository.
Contextual assessment: The flagged value is a hardcoded application anon key used as both the apikey and Bearer token when calling the JanitorAI auth endpoint for token refresh. This matches the Supabase anon-key pattern, which is designed to be public and embedded in client-facing code. It identifies the application to the auth service; it is not a user credential or secret session token. Actual user session tokens are obtained at runtime and stored in memory. The destination is the legitimate JanitorAI auth host, and usage is proportionate to the stated purpose of restoring JanitorAI login support.
The flagged value is a public app key needed to talk to JanitorAI's login service. It is not a private password or user token, and it is used exactly as needed for the JanitorAI feature described in the project.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule jwt in this repository.
Contextual assessment: The matched value is a hardcoded JanitorAI anon key assigned to a constant and used as the apikey and Bearer header when calling JanitorAI's auth token-refresh endpoint. This is a Supabase-style anon/public client key, which is structurally a JWT and therefore matches the gitleaks jwt rule, but is designed to be embedded in client code and is not a user secret. User session tokens are kept in memory only and are not hardcoded. The data flow is consistent with the stated purpose of restoring JanitorAI integration.
When a user logs in, their session tokens are kept in memory only and are not saved to files or sent anywhere unexpected.
Technical assessment
User access and refresh tokens are kept in an in-memory variable and refreshed against the legitimate JanitorAI auth endpoint. There is no persistence of user credentials to disk or external destinations, which is consistent with the stated login feature.
User login tokens for JanitorAI are kept in memory while the server runs and are not saved to files or sent anywhere unexpected.
Technical assessment
The janitorSession object holds accessToken, refreshToken, expiresAt, and email in a module-level variable with no persistence to disk or external destination. Tokens are refreshed via JanitorAI's auth endpoint and cleared on failure. This is consistent with the integration purpose and does not indicate exfiltration.