City security reviews how a 311 agent refreshes OAuth credentials to call resident email APIs. What practice should they verify?
Select an answer to reveal the explanation.
Short Explanation
Think of tokens as temporary hall passes, not souvenirs. You should verify secure storage, short lifetimes, and controlled refresh for agent API access—not plaintext chat logs, emailed long-lived tokens, or client secrets in FAQs. Sloppy token handling can turn a 311 helper into a stolen mailbox key.
Full Explanation
When city security reviews how a 311 agent refreshes OAuth credentials for resident email APIs, they should verify secure token storage, short lifetimes, and controlled refresh for agent API access. The agent needs credentials that are protected, expire quickly, and refresh through a controlled client flow. This limits replay windows if logs or agent memory leak and follows standard OAuth hygiene. Logging refresh tokens in plaintext chat transcripts fails because transcripts are widely readable operational data that can become a token vault for attackers. Emailing long-lived access tokens to the agent’s public distribution list broadcasts bearer credentials to many mailboxes and archives. Embedding the client secret in every resident-facing FAQ answer exposes confidential client credentials in public content. Exam caveat: short-lived tokens and controlled refresh improve credential hygiene but do not replace least-privilege scopes or egress controls on what the email API may send. Practical check: inspect the agent’s secret store for tokens, confirm access-token TTL is short, verify refresh occurs through the protected client flow without writing refresh tokens to chat logs, and rotate a test credential to ensure the agent recovers without FAQ or transcript leakage.