A plain-language privacy FAQ for Connect AI Pass

"Connect your wallet" is a reasonable place for a user to hesitate. They may hear "give this app control of my money," "share all my documents," or "create another account I cannot leave."

A useful FAQ answers those concerns separately. OAuth describes an authorization mechanism. It does not, by itself, tell a person which data your app stores, what a model provider receives, or when your interface starts a paid request.

The answers below distinguish AI Pass's role from promises an app developer must implement and verify. Use them as a writing checklist, not as a substitute for your own privacy notice.

Is this the same as giving you my provider API key?

No. Provider-key BYOK means connecting a credential issued by a model provider. AI Pass is a wallet-funded OAuth option: users connect through an authorization flow and fund model usage through AI Pass without handing the app their provider keys.

That distinction does not mean the app receives no authorization capability. The approved connection enables supported actions within its permissions. Users should read the actual approval screen rather than assume "no key" means "no access."

The AI Pass integration guide explains the intended connection paths and credential boundaries.

Does connecting replace my login to this app?

For an existing app, it should normally remain a separate funding connection. Your projects and app account can stay where they are, with the same hosting and sign-in system.

Suggested copy: "You are connecting a funding method for AI features. Your existing app account and saved projects are unchanged."

Only publish that sentence if your implementation does preserve them. A new app that deliberately uses AI Pass for identity needs a different explanation; do not hide that design behind funding-only copy.

Can the app spend just because I connected?

A connection and a decision to run a paid task are different things. Your app should make the paid action visible and identify its funding source before dispatch. Do not promise that OAuth itself requires a fresh confirmation for every possible request unless the relevant contract actually says so.

For a user-triggered rewrite, proposed consent copy is: "Rewrite the selected paragraph using my AI Pass wallet. Review the displayed pricing before continuing."

For a batch feature, name the batch and its scope. "Process these selected files" is more informative than "Continue." An authorization screen cannot rescue an app that disguises a recurring job as a one-time button.

Who sees my prompt and files?

Explain your actual route. A backend app may receive the input before forwarding the required content through AI Pass to a model provider. A browser integration has a different architecture. Do not claim the app cannot see prompts simply because it does not collect provider keys.

Suggested notice: "This action sends the selected text to the services needed to generate a response. Do not include material you are not permitted to share. Review our processing details before using confidential documents."

Follow that with named processors and real retention information in your privacy notice. The SDK documentation and REST reference help developers choose an integration route; neither replaces an app-specific explanation of data handling.

Can other connected apps read my saved work?

A shared funding wallet is not a reason to make documents shared by default. AI Pass's integration guidance distinguishes private app persistence from explicit cross-app sharing. Developers should use private storage for ordinary app work and request broader access only for an intentional feature.

If your product offers sharing, explain the recipient and the material: "Allow this workflow to use the selected document in the named connected app." Keep that separate from the funding connection. Do not suggest wallet connection alone authorizes unrestricted access to every project.

What happens when I disconnect?

Explain both effects and limits. Your app's Disconnect control should stop it using that connection for new requests and clear the credentials it is responsible for retaining. Account-side revocation may be a separate control; link users to the current supported route rather than inventing a menu path.

Disconnecting does not automatically delete saved app projects, cancel a separate software subscription, erase already processed prompts, or reverse charges. Nor should you promise it cancels an in-flight model request without evidence.

Give each separate need its own instruction: disconnect access, delete app data, manage the software plan, and ask about a disputed usage record.

What should I never send to support?

Do not send provider keys, OAuth tokens, wallet credentials, passwords, or full payment details. An app operation reference and a description of the problem should usually be the starting point.

A trustworthy FAQ leaves room for "we do not know yet" when an outcome is uncertain. Replace broad reassurance with controls the user can find, specific data boundaries, and a clear explanation of the next paid action.