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. Composable guardrails via the Guard policy engine: rate limits, scope filtering, time windows, and custom rules that run before any token is issued.

What Cred Is NOT

Not an auth provider.

Cred never handles login. It receives verified identity from your existing provider (WorkOS, Supabase, Clerk, NextAuth) and manages outbound credential lifecycle from there.

Not a vault/secret manager.

HashiCorp Vault manages infrastructure secrets (DB passwords, API keys you own). Cred manages user-delegated OAuth tokens: credentials users grant to your agent.

Not an API proxy.

Cred is not in the hot path of API calls. The agent calls the service directly with the brokered token. Token proxy mode is optional for maximum security.

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.