The Account Security block (see "Giving your app's users their own two-factor authentication") also lets a signed in visitor generate their own personal API key. This is a key issued by an end user, to themselves, so they can call your published app's own records API from their own script or tool, it has nothing to do with your project's REST API Builder keys (a different project type entirely) or the OAuth credentials you connect from your Integrations tab (those are yours, this is theirs).
What an API key can do
A key can do exactly what that same visitor could already do while signed in through a normal browser session, reading and writing the records, collections, and scopes their account already has access to, nothing more. It cannot see or act on another visitor's private records, and it cannot reach anything an admin only collection restricts from that visitor's role.
Creating and revoking a key
From the Account Security panel, a visitor gives their key a label (so they can tell multiple keys apart later) and generates it. The full key is shown exactly once, at creation, save it somewhere safe, it can't be recovered afterward, only replaced with a new one. The panel lists every key's label, when it was created, and when it was last used, and any key can be revoked at any time, immediately ending its access.
Using the key
Send it as a Bearer token, an Authorization: Bearer <key> header, on requests to your app's records API. It's rate limited at least as strictly as a normal signed in session, since a script is easier to run at high volume than someone clicking around a browser.
Tip: If a key is ever exposed by accident, revoking it from the Account Security panel takes effect immediately, the safest response is always to revoke and generate a fresh one rather than trying to figure out whether it was actually misused.