Authentication: OAuth and API keys

Before an AI can attach to your memory, something has to confirm that this is you. Not just anyone gets to read and write someone else's memory. There are two ways to do that confirmation. OAuth and an API key. The difference comes down to one sentence.

OAuth has the system authenticate on your behalf. An API key binds authentication into a single key.

OAuth: approve once with your account and you're done

Add AiAkiv in an AI app and a sign-in window appears. Approve once with your AiAkiv account and from then on the system verifies your identity by itself.

• Identity is bound to your account. You're authenticated as you, not as the app.
• No secret ends up in your hands. Nothing to copy, nothing to manage.
• The system handles renewal and revocation. Clean up on the account side and access is cleaned up with it.

API key: authentication bound into the key

You issue a key in the console and paste it into the app's settings. There's no sign-in window. Instead, the key itself is the ID card.

• Whoever holds the key is you. App or person, the key alone grants your access.
• So a key must be handled with the same weight as a password (see Key hygiene below).
• Issuing and revoking is on you: API key management in the console (Console).

The console can issue two kinds.

Scopes: what kind of work a key can do

A connection carries scopes: the kinds of work it can do.

• manage is off by default on API keys. It is added only when you check "Allow console management by AI (manage)" while issuing the key. The checkbox is in two places: Project management (issuing a project-pinned API key on a project card) and API key management.
• With a key issued without it (every key issued before this feature), the AI can only read through the console app. To let it edit, issue a new key with the box checked and replace the key in the app's settings. Issuing a new key for the same target retires the old one.
• Even with manage, the AI can only do what you turned on in Reference → AI permissions in the console (Asking your AI to do console work).
• Scopes are capped by your team role too. A viewer in that team gets no manage, OAuth or key alike. In a session attached read-only (a public reading binding, a link binding), write and manage are both dropped.
• Even with manage, asking the AI to do console work only works on a connection that has app features. Folder connections, API key connections, plugin installs (Claude Code, Cursor) and connections attached with the address https://mcp.aiakiv.com/mcp?apps=all (a Claude account connector added with this address, a Codex connection (set up with the install prompt), and the like) have them; on the official ChatGPT plugin or a sign-in connection attached with an address that lacks ?apps=all, you do console work in the web console yourself → The app action tool.

Which to use: OAuth by default

If your client supports OAuth, use OAuth without thinking about it. There's no secret to manage, and it follows your account policy directly.

⚠ ChatGPT and ChatGPT classic are different apps. The names are similar and both get installed. They attach the same way: install AiAkiv Memory from the plugin directory inside the app and sign in over OAuth. What differs is pinning a folder. OAuth cannot pin a project per folder, so pinning a folder is done on the ChatGPT app with a project-pinned API key → Connecting ChatGPT.

For the bottom three this is not a choice. But the reason it's key-only differs for each.

For per-client setup, follow the setup guide.

Key hygiene

Since the key is your identity, leaking it means handing over access to your memory itself. Below is the minimum.

• It's shown once, at issue time. Move it somewhere safe then (a password manager). You cannot view it again.
• Issuing a new key for the same target automatically retires the old one. So re-issuing is revoking: if you suspect a leak, just issue a new one.
• Don't share it. Not into chat, issues, or documents. Not to an AI either.
• Don't commit it. If a key lives in a config file, exclude that file from commits (.gitignore).
• A key can't exceed your own permissions. Its access ceiling is your team role, a read-only person's key doesn't gain write access.
• And don't store keys inside memories in the first place → What to store.

Common confusions

• "It's OAuth: why does changing project ask me to sign in again?" Some OAuth clients (Claude Code, Cursor) need re-authentication when the save target changes. That's normal.
• "I pasted a key and saving goes somewhere unexpected." A dynamic key follows Main. To pin the target, use a project key or set up folder binding (Folder binding · Teams and projects).
• "The AI connected with my API key says it can't edit in the console." That key has no manage scope. Issue a new one with "Allow console management by AI" checked (see Scopes above). If an AI connected through OAuth says the same, first check whether that connection has app features. The official ChatGPT plugin and sign-in connections attached with an address that lacks ?apps=all (such as a Claude account connector added that way earlier) do not (The app action tool). If the connection has app features, reconnect it.
• "I lost my key." There's no recovery. Issue a new one: the old key is retired and you carry on with the new one.

Next

• Installation and per-client setup → Quickstart
• Where saving goes (teams and projects) → Teams and projects
• What not to store → What to store
• API key management in the console → Console