OAuth integration prompts should distinguish what an application requests, what a person approves and what a credential can actually do. A successful login does not establish permission for every operation. Creating a separate API token may also leave an existing browser connection unchanged. These prompts help map those boundaries, review a proposed integration and test permission changes without asking an agent to receive live credentials.
Describe the actors and the intended access
Provide the client type, authorization server, protected resource and callback flow. State whether the client is public or can securely hold a secret. Include requested scopes and the user-facing consent wording. For failures, share sanitized status codes and error fields instead of token values. Explain the operation that fails and whether read access still works.
The OAuth security best current practice, RFC 9700, covers modern security requirements including PKCE for public clients. Use it alongside the provider's current documentation and your actual client library. These prompts organize review work; they do not replace a full protocol implementation review.
Map credentials to operations
Ask the agent to show the path from authorization request to resource access. Include separate manual tokens if the product supports them. A clear table can reveal that a settings toggle changes a newly created token while the active client still uses another grant. Avoid treating all credentials for one account as interchangeable.
Map authorization for {{integration}} using {{client_and_server_paths}}.
List actors, requested scopes, consent, issued credential types and
resource checks. Include manual tokens separately if supported.
For {{failing_operation}}, show the permission required and evidence of
what the active connection received. Do not print, request or persist
live tokens. Identify unknowns that need a sanitized diagnostic check.
Review callback and code-exchange boundaries
A callback handler needs to bind the response to the authorization attempt that started it. Ask the agent to inspect redirect validation, transaction-specific values and code exchange. Include error and cancelled-consent paths. A successful happy-path login is not enough evidence when a second tab, stale response or wrong redirect can reach the same handler.
Review {{oauth_callback_and_exchange_paths}} for {{client_type}}.
Check redirect validation, transaction binding, PKCE where required,
credential handling and cancelled/error responses. Use our provider and
library versions. Give concrete findings with code evidence and focused
tests. Do not invent a client secret for a public client or weaken
validation to make a callback succeed.
Test consent changes, refresh and revocation
Permission tests should prove that the old grant does not silently acquire broader access. Then verify the newly approved connection exposes the intended operation. Include refresh narrowing and revocation if the integration supports them. Use fixture credentials in tests, keeping live account actions as a separate authorized verification.
Test permission changes for {{integration}} with fixture credentials.
Start with read-only approval and verify {{write_operation}} is unavailable.
Create any separate manual token and confirm it does not widen that grant.
Perform fresh consent for {{write_scope}} and verify intended access.
Test refresh and revocation boundaries supported by our implementation.
Report transport-level evidence without exposing credential values.
Diagnose the active connection before replacing it
Check the server name, endpoint, account and authentication method the client actually uses. Replacing a token in a different configuration may not affect that client at all. Prefer a documented reconnect path with visible consent when the issue is an old grant. After a tool-using agent reconnects, refresh discovery or restart it before checking available capabilities.
Save the approved integration prompt in Kipt with variables for actors, scopes and sanitized evidence. For the specific case where Codex can search Kipt but cannot save, use the Codex MCP write-access guide.