A city permitting chatbot must call a third-party payments API to collect application fees, and the architecture team needs the agent to authenticate to that external tool without embedding long-lived credentials in the agent's code. What approach fits this requirement?

OAuth 2.0, configured through Auth Manager, lets the agent obtain short-lived, appropriately scoped access tokens for a specific tool call rather than holding a static, long-lived credential embedded in its code or configuration, which limits both the blast radius of a leaked token and how long any single credential remains valid. Hardcoding an API key creates exactly the long-lived embedded credential the requirement is trying to avoid, and it's hard to rotate or scope. Sharing one service-account credential across every agent multiplies the exposure of a single compromised credential across the whole fleet instead of isolating access per agent and per call. Disabling authentication removes the control entirely rather than securing it, trading a manageable risk for an unmanaged one. Scope caveat: OAuth token scopes and lifetimes still need deliberate configuration — an overly broad scope or an unnecessarily long token lifetime undermines much of the benefit even when OAuth is used. Operational check: verify the token issued for the payments API call carries only the specific scope needed for fee collection and expires within the expected short window.