Disconnect an AI client by reviewing grants, keys and provider access separately

Map the access boundaries

Build a disconnect map with one row for each access path: AI OAuth grant, AdAce Ads API key, workspace membership, direct provider membership, provider connection and shared artifacts. Record the identity, owner, purpose, affected workspace or client, planned closure and verifier. Do not list access tokens themselves. Start with the relationship being ended: one assistant application, one person's engagement or the entire provider integration. Those goals require different closures.

For a teaching example, a contractor used an API key in one analysis session and also authorized an AI client through OAuth. Revoking only the key leaves the separate grant to review. Conversely, disconnecting the client's Google connection just to stop the assistant may interrupt the team's future data collection. The correct boundary is the contractor or AI credential, unless ending the underlying provider connection is independently intended and authorized. The example describes reasoning, not a completed live disconnection.

AdAce Ads exposes API-key management and AI grants, and its authentication checks reject revoked credentials. Provider disconnect has its own revocation behavior and can affect shared connection relationships. The runbook should record the result of each relevant control separately. Existing historical analytics and downloaded reports are not automatically erased by credential revocation. A lack of recent usage evidence should not be treated as proof that an authorization is absent or harmless.

Revoke the intended relationship

• Distinguish containment from ordinary offboarding. Suspected misuse may justify immediate closure of identified credentials; routine retirement can first inventory dependencies. Both need explicit ownership and safe evidence of the final state.
• Use the smallest intended boundary. Revoking one grant does not mean all grants for every user disappeared. Ending a person's workspace membership has a wider consequence than retiring one application authorization.
• Document retained data and remaining obligations. Technical revocation controls future access, not the assistant provider's copies or exported material. Do not claim complete data deletion without a separately verified retention and deletion process.

Close and verify each credential path

1. Identify the user, application and workspace involved without recording secrets. Inventory known grants and keys, including credentials that were used in separate environments. Record uncertainty when a consumer or authorization path cannot be confirmed.
2. Choose the closure scope with the authorized owner. Decide whether to end an AI credential, a person's membership or a provider connection. Check dependencies so unrelated reporting, automations or client users are not unintentionally removed.
3. Perform the authorized revocations through the relevant controls. Grant closure and API-key closure are separate actions. If a provider connection is also being ended, follow its own disconnect process and track pending provider revocation or manual follow-up.
4. Verify the intended access is denied using a safe controlled read or an appropriate credential-state check. Avoid logging authentication material. A vanished client-side shortcut is not sufficient evidence that the server-side credential stopped working.
5. Complete a closure record listing each boundary, action, result, verifier and time. Mark unresolved access or retained artifacts separately. Review future activity and failed consumers where evidence exists, without treating unavailable usage timestamps as observed inactivity.

Disconnection is not universal deletion

Sources and further reading

• AdAce Ads AI authorization controls
• AdAce Ads API keys
• AdAce Ads provider revocation