Research Preview — Cred is in active development and has not undergone a third-party security audit. Do not delegate production credentials with spending authority. Use test credentials while we harden the platform.

About Cred

AI agents need credentials to do useful work. Read a calendar. Post to Slack. Push to GitHub. But the current approach (hardcoded API keys, plaintext config files, tokens pasted into environment variables) doesn’t scale. It’s insecure by default.

Here’s the thing: OAuth already exists. Every major service supports it. Google, GitHub, Slack, Notion, Salesforce: they all have secure token exchange flows. The missing piece isn’t authentication. It’s delegation: something that brokers OAuth grants between users, developers, and agents.

“Delegation, not exposure.”

Cred is credential delegation middleware for AI agents. When your agent needs access to a user’s Google Calendar or Slack workspace, Cred validates the agent’s identity, checks that the user consented, and returns a short-lived access token. Refresh tokens never leave the vault. The agent never sees long-lived credentials.

Cred is middleware, not a platform. It works alongside your existing auth provider (WorkOS, Supabase, Clerk, NextAuth, or whatever you’re using). Three lines of code to integrate. Your auth provider handles who the user is. Cred handles what your agent can access on their behalf.

The infrastructure is live. The 7-step delegation pipeline works. AES-256-GCM encryption with per-account cryptographic isolation. Standards-compliant OAuth 2.0 with PKCE. Append-only audit trails. Five provider adapters shipping. TypeScript and Python SDKs. MCP server for Claude Desktop.

Core Principles

  • Tokens are brokered, never exposed. Short-lived access tokens only. Refresh tokens never leave the vault.
  • Users control delegation. Grant scoped access. Revoke anytime. Full visibility into what agents accessed.
  • Developers ship features, not plumbing. Three lines of code. No OAuth infrastructure rebuild.
  • Standards matter. OAuth 2.0, PKCE, AES-256-GCM, RFC compliance throughout.
  • Middleware, not lock-in. Works with your existing auth. Self-host or use managed.

Questions? Ideas? Want to integrate Cred into your product? Email kieran@kierans.net.