carlos / platform Public

App owners can request antivirus scanning, but deployment operators have no antivirus request queue in the console or CLI. The existing /fleet/store page and carlos store approvals list account applications for storage, not per-app scanning requests.

Observed on Carloku on 2026-10-20: account bdn, app woodfamilytrust had a request from tonywood@keymail.dev dated 2026-10-03T15:02:57Z, still waiting for an operator. The deployment-wide ClamAV engine was enabled and responding, but this store had no engine enabled. Paul learned about the pending request through Tony and asked where to see requests.

At Paul's explicit request, ran carlos store scan grant --account-id bdn --app woodfamilytrust. A separate status read confirmed ClamAV enabled at 2026-10-20T20:54:32Z. Enforcement remains off and no sweep had finished at verification. This resolves activation for this app, not request discovery for other apps.

Requested outcome:

• An operator-only console queue and API-backed CLI command listing pending scanning requests across accounts, including account, app, requester, request time and plaintext/client-encrypted attestation.
• A supported path from a queue entry to grant or decline, with clear status for the requesting member. Preserve member consent and the existing operator authority checks; explicitly design cross-account access rather than relying on operators also being account members.
• Surface pending requests to operators through a visible queue count and/or notification, so discovery does not depend on a member contacting an operator separately.
• Keep deployment engine health, per-store activation, scan coverage and enforcement distinct. Activation must not imply that a sweep has completed or infected objects are blocked.

Implementation pointers: scan.go (subcommands and shared account resolution), internal/console/apiscan.go (request/status/grant), internal/console/storepage.go and storenotify.go (existing storage approval UI and notification pattern). handleAPIScanRequest currently records the request and audit event, without adding it to an operator request queue.

The CLI currently returns only a recent discussion list; no matching issue appeared in that list. Link or consolidate with an older discussion if one exists.