Apr 21, 2026

8 minutes read

Apr 21, 2026

8 minutes read

Cognee's CLI Replaces MCP OAuth in 100 Lines

David MyrielAI Researcher

MCP's pitch is authentication. Every debate about MCP versus CLI eventually lands on the same line: "MCP has real auth built in. CLI doesn't." That claim is wrong.

The Claude Code plugin that wraps cognee-cli runs a full register-login-token handshake against the Cognee backend before the first command fires. It hits the same OAuth-style endpoints an MCP server calls internally, just from a Python hook instead of a transport layer. Your agent ends up with a scoped, revocable credential tied to a real user record.

export COGNEE_SERVICE_URL="http://localhost:8000"
claude --plugin-dir ./cognee-integrations/integrations/claude-code
# → plugin registers the agent, mints an API key, reconnects with it

Where the authorization check runs

MCP and Cognee both enforce auth before returning data. The difference is which layer runs the check. MCP stops at the server; Cognee pushes it down to the database itself.

   MCP                           Cognee plugin

   Agent                         Agent
     ↓                             ↓
     ↓                             ↓
   MCP client                    Plugin hook
     ↓                             ↓
     ↓                             ↓
   MCP server   ←── authz         Cognee API
     ↓                             ↓
     ↓                             ↓
   Backend DB                    DB + ACL   ←── authz

Auth happens once, at session start

Your agent logs in one time per session and reuses the credential for everything after. When Claude Code fires the SessionStart hook, the plugin calls a single function: ensure_identity(). That function checks for a backend URL and, if found, runs a six-step handshake (four HTTP calls to /api/v1/auth/* plus two local steps).

Every later hook (PostToolUse, UserPromptSubmit, SessionEnd) inherits the credential through a cache file at ~/.cognee-plugin/resolved.json. No refresh dance inside the hot path. You pay the cost of auth exactly once per session.

Claude Code session starts
↓
├─ SessionStart hook fires
│   └─ ensure_identity()
│       ├─ POST /auth/register  (first run only)
│       ├─ POST /auth/login     → JWT
│       ├─ GET  /auth/api-keys  → existing key?
│       └─ POST /auth/api-keys  → mint if missing
│
├─ cognee.serve(url=..., api_key=<agent_key>)
│
└─ Every later hook reads ~/.cognee-plugin/resolved.json

Six steps mint a real agent identity

The handshake is six short steps that create an account for your agent and hand it a key. Half of them run only on first launch; after that, the plugin detects the existing API key and skips registration entirely. The cost amortizes to near-zero within two sessions.

Each call maps directly to something an MCP OAuth server does under the hood. The difference is that you can read the whole flow in 100 lines of Python. There's no protocol specification to chase.

Cognee call	What MCP OAuth calls it	When it runs
`POST /auth/register`	Dynamic client registration	First session only
`POST /auth/login`	Token endpoint (password grant)	Every session
`GET /auth/api-keys`	Introspection	Every session
`POST /auth/api-keys`	Client credential issuance	If no key exists
`cognee.serve(api_key=...)`	Authenticator reconnect	Every session
`~/.cognee-plugin/resolved.json`	Token cache	Passive, shared across hooks

Your agent is a real user, not a session token

The registration step creates a dedicated identity: claude-code@cognee.agent. That's a real row in Cognee's user table, not a synthetic session token. It shows up in the Cognee UI's agent list alongside any human users.

You revoke the key like any OAuth app. Delete it from the UI and the next agent call returns 401; the plugin re-runs ensure_identity and mints a new one. That's the same behavior MCP's refresh flow gives you, with one fewer specification to implement.

# integrations/claude-code/scripts/config.py
async with session.post(
    f"{base}/api/v1/auth/api-keys",
    json={"name": "claude-code-plugin"},
    cookies={"auth_token": jwt},
) as resp:
    agent_key = (await resp.json())["key"]
    await cognee.disconnect()
    await cognee.serve(url=service_url, api_key=agent_key)

MCP handles authentication. Cognee handles authorization.

MCP's auth spec does one thing well, which is answering the question of who is calling. It does not answer the next question, which is what that caller is allowed to do. Security researchers have been calling out this gap across multiple widely-read posts since late 2025.

The industry term for the first question is authentication. The term for the second is authorization. They sound similar but they protect against completely different attacks.

"OAuth decides who gets in, while these frameworks decide what they can do once inside."¹

Cognee does both. The plugin mints a scoped identity through the handshake above, and the backend runs every subsequent query through the same permission system that governs human users. Turn on ENABLE_BACKEND_ACCESS_CONTROL=True and the ACL layer filters results before any response leaves the database.

That second half is where most MCP deployments fall short. The spec tells servers to validate tokens and check scopes. It stops short of defining what those scopes mean or who can invoke them on which resources.

"The spec handles authentication. Authorization, the actual permission decisions, is left entirely to implementers."²

Each agent gets its own storage files

With ENABLE_BACKEND_ACCESS_CONTROL=True and a supported backend (Kuzu, LanceDB, or Falkor), Cognee provisions separate storage per user. The agent's knowledge graph, vector embeddings, and metadata live in their own files on disk. Another agent running on the same backend cannot see them without a second set of valid credentials.

The isolation is physical, not rule-based. There's no shared query plane for an attacker to poison, no row-level filter to bypass, no multi-tenant pool to exploit. Each agent reads from a namespace Cognee will not even open unless the API key checks out.

The agent shows up in the same ACL system that gates human users. One policy. Two client types.

The mistakes the plugin doesn't make

Security researchers at Obsidian disclosed multiple one-click account takeover vulnerabilities in production Remote MCP deployments during 2025.³ Square's MCP server was one of them. The root cause was a structural pattern called MCP-as-OAuth-proxy, which the plugin avoids entirely by going direct.

The proxy pattern creates four categories of failure. MCP servers share static client_ids that cache consent across clients, while browser-based consent flows get hijacked through CSRF when attackers complete the consent step themselves. Token passthrough leaks downstream credentials, and revocation fixes often miss pre-existing clients while patching only newly-registered ones.

Real-world pitfall (per Obsidian)	What the plugin does instead
Shared static client_id across MCP clients	Each agent registers as its own user with its own key
Token passthrough: MCP JWT contains downstream credentials	Cognee API key is scoped to Cognee only
CSRF via browser redirect in consent flow	No browser flow, pure HTTP handshake
Revocation gaps for pre-existing clients	Revoke in UI, next call 401s, plugin re-mints

The plugin sidesteps the proxy pattern entirely. There's no browser redirect to poison, and no shared client_id that caches consent across agents. Revocation applies immediately because no consent layer sits between the backend and the caller.

The TypeScript side shares the same auth transport

Python and TypeScript share one auth implementation instead of each rewriting their own. integrations/openclaw/src/client.ts exports CogneeHttpClient, a shared HTTP transport used by both the memory plugin and the skills plugin. It handles cloud mode (X-Api-Key), local mode (JWT Bearer), and auto-relogin on 401.

A comment near the top of the file makes the intent explicit. The transport was extracted on purpose. It exists so plugins stop reinventing their own fetch-and-auth wrappers.

"Extracted so both the memory plugin and skills plugin can share one implementation instead of duplicating ~200 lines of fetch/auth logic."

Try it

Point the plugin at your backend and check the UI. Your agent is there, with its own API key, scoped to its own dataset. No MCP server, no OAuth client registration, no manual tokens.

Install Cognee, set the service URL, and launch the plugin. That's the whole setup. The handshake runs before your first prompt.

pip install cognee
export COGNEE_SERVICE_URL="http://localhost:8000"
claude --plugin-dir ./cognee-integrations/integrations/claude-code
# → open the Cognee UI → Agents → claude-code@cognee.agent

The next time someone tells you skills+CLI can't do auth, send them to integrations/claude-code/scripts/config.py. The full handshake is 100 readable lines of Python. MCP's remote auth stack pulls in seven separate RFCs plus an external identity provider you have to run separately.⁴

The code is at github.com/topoteretes/cognee-integrations. Python lives under integrations/claude-code/, TypeScript under integrations/openclaw/. Both share the same auth story.

Join the Discord community: Discord

References

Further reading:

Dan Moore, "Is that allowed? Authentication and authorization in Model Context Protocol," Stack Overflow Blog, January 21, 2026.
"Authorization," Model Context Protocol Specification (revision 2025-11-25).

Hazal Mestci, "Authorization for MCP: OAuth 2.1, PRMs, and Best Practices," Oso Security, October 28, 2025. ↩
Sam Kim, "MCP is Not Secure," AuthZed, December 1, 2025. ↩
Obsidian Security, "When MCP Meets OAuth: Common Pitfalls Leading to One-Click Account Takeover," January 29, 2026. ↩
Ashish Dubey, "MCP Authentication and Authorization: Key Differences Explained," TrueFoundry, April 14, 2026. ↩

Cognee is the fastest way to start building reliable Al agent memory.

Latest

Cognee's CLI Replaces MCP OAuth in 100 Lines

Deep DivesApr 21, 2026