Replace static seed API keys with production-grade credential lifecycle management

[llinsss]

Problem

Production authentication is backed by a repository JSON file loaded once into process memory. The repository ships usable raw seed keys in the README, there is no startup guard preventing those keys/accounts in production, no supported issuance/revocation/rotation workflow, and account changes require a process-local cache reset/restart. A leaked key remains valid indefinitely and provides the full fixed student scope attached to that account.

This is adequate for a demo, not for a child-data service deployment.

Proposed change

• Introduce a pluggable credential/account store with a production implementation backed by the deployment's secret manager or database; keep file auth explicitly development-only.
• Fail closed at startup when production uses seed credentials, the default account file, malformed roles/scopes, or insecure auth configuration.
• Store key records with a public key ID plus a slow/verifiable secret hash or provider-managed token reference, creation/expiry/revocation timestamps, and least-privilege scopes.
• Support overlapping key rotation, immediate revocation, expiry, and auditable account/student-scope changes without restarting every worker.
• Avoid exposing whether a key ID/account exists and use constant-time verification where locally applicable.
• Provide a migration/provisioning command that does not print secrets after initial creation and never commits generated credentials.
• Add runbooks for rotation, compromise response, and local development.

Acceptance criteria

• Production refuses to start with repository seed credentials or development file-auth mode.
• Keys can be issued, rotated, expired, and revoked; revoked keys stop working across all workers within a documented bound.
• Credential material and bearer tokens never appear in source control, logs, errors, or API responses.
• Role and student-scope changes are validated and audited.
• Tests cover expiry, revocation, rotation overlap, malformed stores, multi-worker cache invalidation, and timing-safe comparison behavior.
• Existing local examples continue through an explicitly enabled development configuration.

Relevant code

• agent/auth.py
• data/accounts.json
• main.py
• README.md
• SECURITY.md

[EmmanuelAdah]

I'd love to take this on! My experience in enterprise backend engineering and database management—specifically building secure, distributed Python ecosystems—makes me a strong fit for this task. I will implement the pluggable, database-backed credential store with strict production startup guards, build out the full key lifecycle for rotation and revocation, and ensure constant-time verification without exposing secrets in logs or responses. Please assign it to me if available!

[grantfox-oss]

🦊 GrantFox — @EmmanuelAdah has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #27)
2. Your PR will be reviewed by the DogStark maintainers

Good luck! Track your progress on GrantFox.