Access Key credential fields lack autocomplete metadata and trigger Chrome warnings

[Vonng]

Environment

• SILO Console v2.0.0 at b952a1202869b89e5cc7b821a0b5651f74e09d08
• Chrome desktop, tested against m.pigsty on 2026-08-05

Reproduction

1. Open Access Keys.
2. Open Create Access Key; no credential needs to be submitted.
3. Inspect the Access Key and Secret Key inputs and the browser console.

Actual result

Chrome reports that the credential inputs should have autocomplete attributes (it suggests current-password for the password-like field). The form sets autoComplete="off", but neither child input supplies an explicit field-level token:

• AddServiceAccountScreen.tsx
• AddUserServiceAccountScreen.tsx

Form-level autocomplete=off is commonly ignored for credential-shaped fields, so password managers may also misclassify or overwrite the generated values.

Expected result

Both the administrator Create Access Key form and the per-user Create Access Key form should declare intentional field-level autocomplete semantics.

Acceptance criteria

• Add appropriate explicit tokens to both inputs in both forms (for example, an identifier token for Access Key and new-password for a newly generated Secret Key; choose the final mapping based on password-manager behavior).
• Chrome no longer emits the missing-autocomplete warning.
• Password managers do not treat the form as an existing login or overwrite generated credentials.
• Existing copy/show/hide and form submission behavior remains unchanged.

[Vonng]

Fixed in v2.1.0 — 85fc0c6.

Resolution

Both forms now declare field-level intent instead of relying on form-level autocomplete="off", which Chrome ignores for credential-shaped inputs:

<InputBox id="accessKey" name="accessKey"
  autoComplete="section-service-account username" ... />

<InputBox id="secretKey" name="secretKey" type="password"
  autoComplete="section-service-account new-password" ... />

Applied identically in AddServiceAccountScreen.tsx (administrator) and AddUserServiceAccountScreen.tsx (per-user).

Two deliberate choices in that mapping:

• new-password, not current-password. Chrome's own hint suggested current-password, but that is semantically wrong here and would have been the harmful fix: it tells the password manager this is an existing login secret, inviting it to autofill a saved password over a freshly generated secret key. new-password describes what the field is — a secret being created — so managers offer to generate or save rather than overwrite.
• The section-service-account prefix. Access keys are not the user's console login. Scoping both fields to their own autofill section keeps the pair from being classified as, or merged into, the console sign-in credential.

The form-level autoComplete="off" is retained; it is now a hint rather than the only signal.

Copy/show/hide behavior, the generated-credential flow, and form submission are untouched.

Acceptance criteria

• Explicit field-level tokens on both inputs in both forms
• Chrome no longer emits the missing-autocomplete warning
• The form is not treated as an existing login, and generated credentials are not overwritten
• Existing copy/show/hide and submission behavior unchanged

Closing as fixed in v2.1.0.