carlos / platform Public

The normal antivirus workflow currently requires two operator actions for one member request: carlos store scan grant enables scanning, then carlos store scan enforce on enables denial of reads for objects marked infected. A member cannot complete the second step because it requires CARLOSSTOREOPERATORS too.

Concrete case: Tony requested scanning for account bdn / app woodfamilytrust on 2026-10-03. Paul granted it on 2026-10-20. Tony then encountered the same operator restriction when trying to enable enforcement. The store had scanning enabled but enforcement off, and no sweep had finished at the last verification. Granting what the member understood as antivirus protection therefore left infected objects readable even after detection.

Paul asked why this needs a separate step: surely an account has antivirus access or it does not. The proposed product model is:

• A deployment operator approves an account's access to antivirus.
• An app owner opts in for a store and explicitly attests whether the objects can be read by the scanner. Preserve consent to scanning tenant bytes; account eligibility alone must not start scans.
• Normal activation includes scanning and enforcement. Monitoring-only remains available as an explicit alternative, with clear consequences.
• A member should not need a second operator intervention to complete the protection they already requested and were approved to use.

Design and implementation must address partial activation: do not report protection enabled unless the enforcement policy is actually installed and verified. Treat account eligibility and per-store consent/protection state as distinct. Specify how existing monitor-only stores migrate; do not silently change their production policies merely because the default changes for new activations.

Keep the protection claims precise. The current scanner runs asynchronously over stored objects. Enforcement denies reads of objects already marked infected; it does not reject uploads or block access to objects awaiting a scan. Activation must report pending coverage honestly. Blocking unscanned objects or scanning before accepting uploads would require a separate design decision, not an implied promise in the activation UI.

Related: discussion #332 covers the missing operator queue and notification path for antivirus requests. This discussion covers what approval and activation mean, and eliminating the second operator approval in the ordinary workflow.

Implementation pointers: scan.go, internal/console/apiscan.go (grant/enforce and policy delivery), internal/console/scanpass.go, and docs/site/cli.md. No enforcement or production configuration was changed while filing this request.