Your agents call APIs. They never see the keys.

AgentCordon is a self-hostable Agentic Identity Provider and credential broker for AI agents.
AES-256-GCM encrypted vault · Cedar policy engine · credential proxy · MCP gateway · full audit trail.
The open-source alternative to hardcoded API keys in AI agent workflows.

Website · Docs · Discord

---

The Problem

AI agents need API keys. Most teams paste them into prompts, environment variables, or MCP config files. Every agent holds long-lived credentials with no access controls, no audit trail, and no revocation path. GitGuardian found 24,000+ secrets leaked in MCP config files alone. That doesn't scale.

How AgentCordon Fixes It

AgentCordon uses a three-tier architecture: a thin CLI in each agent workspace talks to a broker daemon that holds OAuth tokens, and the broker talks to the server which enforces Cedar policies and manages the encrypted vault. Credentials never leave the broker boundary -- agents never see secrets.

sequenceDiagram
    box rgb(219,234,254) Agent Host
    participant Agent as AI Agent
    participant CLI as agentcordon CLI
    end
    box rgb(253,230,243) Broker
    participant Broker as agentcordon-broker
    end
    box rgb(220,252,231) AgentCordon Server
    participant Srv as AgentCordon Server
    participant Cedar as Cedar Policy Engine
    participant Vault as Encrypted Vault
    end
    box rgb(254,243,199) External
    participant Ext as External API / MCP Server
    end

    Note over Agent,Broker: Workspace registration (one-time)
    CLI->>Broker: Register workspace (Ed25519 public key)
    Broker-->>CLI: Workspace registered

    Note over Broker,Srv: OAuth authorization (one-time per user)
    Broker->>Srv: Authorization code + PKCE flow
    Srv-->>Broker: Access token + refresh token

    Note over Agent,Ext: Credential proxy flow
    Agent->>CLI: agentcordon proxy github-token GET /repos/org/repo
    CLI->>Broker: Signed request (Ed25519)
    Broker->>Srv: Vend request + OAuth token
    Srv->>Cedar: Can this client access "github-token"?
    Cedar-->>Srv: Permit
    Srv->>Vault: Decrypt credential
    Vault-->>Srv: Plaintext secret
    Srv-->>Broker: Credential material
    Broker->>Ext: GET /repos/org/repo (Authorization: Bearer ... injected)
    Ext-->>Broker: Response
    Broker-->>CLI: Response
    CLI-->>Agent: Response

Loading

See It In Action

An AI agent checks a Cloudflare deployment and queries AWS IAM policies — using real credentials it never sees:

Every credential access shows up in the audit trail:

Quick Start

1. Start the server

docker compose up -d

Open http://localhost:3140. Default admin credentials are printed to the console on first boot.

2. Start the broker

The broker daemon runs on the user's machine (or as a shared service) and manages OAuth sessions with the server:

agentcordon-broker --server-url http://localhost:3140

The broker starts on port 3141 by default. On first run it requests a device code from the server and prints a short 4-word passphrase plus an activation URL — you approve the registration in any browser, on any host. There is no loopback callback and no ephemeral port to forward.

3. Set up a workspace

From your agent's project directory, point the CLI at the broker and run the one-command setup:

export AGTCRDN_BROKER_URL=http://localhost:3141   # default; set if broker is on another host/port
agentcordon setup http://localhost:3140

You will see something like:

To finish setting up this workspace, open:

    http://localhost:3140/activate

and enter the code:

    tidy-zoned-zit-ramp

Waiting for approval... (expires in 10 minutes)

Open the URL in any browser (including one on a completely different machine), sign in, paste the 4-word code, and click Approve. The CLI will detect the approval, generate an Ed25519 keypair, register the workspace with the broker, and write agent instruction files — all in one step.

This uses RFC 8628 OAuth 2.0 Device Authorization Grant, the same flow as gh auth login, az login --use-device-code, and aws sso login. The broker can run on a remote host, inside a container, or on a headless server without any port forwarding.

Manual setup (advanced)

If you prefer to control each step individually:

agentcordon init                 # Generate Ed25519 keypair + agent instruction files
agentcordon register             # Start the device flow and register workspace with broker

Installing on Windows

On Windows 10 / 11, the fastest way to install both the CLI and the broker is the one-liner PowerShell installer served by your AgentCordon server:

irm https://your-server.example.com/install.ps1 | iex

This downloads agentcordon.exe and agentcordon-broker.exe from the matching GitHub release, verifies their SHA-256 checksums, installs them to %LOCALAPPDATA%\AgentCordon\bin, and adds that directory to your user PATH. No admin rights required, no Windows service — the broker runs in the terminal you started it from and exits when that terminal closes, just like on Unix.

After the installer finishes, open a new terminal and run:

agentcordon-broker --server-url https://your-server.example.com
agentcordon setup https://your-server.example.com

The device flow works identically on Windows — copy the 4-word code into a browser and approve.

4. Use credentials

agentcordon credentials                    # List available credentials
agentcordon proxy github-token GET /repos/org/repo   # Proxied API call

5. Use MCP tools

agentcordon mcp-servers                    # List available MCP servers
agentcordon mcp-tools                      # Discover tools across all servers
agentcordon mcp-call github list_repos --arg owner=myorg  # Call an MCP tool

The CLI routes all requests through the broker. Credentials are injected server-side and never reach the agent.

Production deployment

For production, set a persistent master secret and mount a data volume:

docker run -d \
  --name agentcordon \
  -p 3140:3140 \
  -e AGTCRDN_MASTER_SECRET="your-strong-secret-here" \
  -v agentcordon-data:/data \
  ghcr.io/agentcordon/agentcordon:latest

Why AgentCordon

Problem	Without AgentCordon	With AgentCordon
Credential storage	API keys in .env, prompts, or MCP configs	AES-256-GCM encrypted vault with HKDF key derivation
Access control	None, or manual allow-lists	Cedar policy engine: deny-by-default, per-agent, deterministic
Agent sees secrets?	Yes, always	Never. Credential proxy injects server-side
Audit trail	Nonexistent	Every access logged with correlation IDs, SOC/IR ready
MCP security	Hardcoded secrets in config	Policy-controlled credential injection per tool call
Revocation	Find and rotate manually everywhere	One-click disable in dashboard, agents lose access instantly

Features

• Credential proxy -- agents call APIs through AgentCordon; raw tokens never leave the server
• Cedar policy engine -- deny-by-default, deterministic, testable authorization
• Encrypted vault -- AES-256-GCM, per-credential key derivation via HKDF
• MCP gateway -- proxy MCP tool calls with credential injection, policy enforcement, and response leak scanning
• MCP Marketplace -- one-click installation of popular MCP servers (GitHub, Slack, Linear, etc.) with automatic credential binding
• OAuth2 for MCP servers -- authorization code flow support for MCP servers that require OAuth2 authentication
• Broker daemon -- per-user service that holds OAuth tokens and proxies upstream requests; credentials never reach agents
• Workspace identity -- Ed25519 keypairs, passwordless enrollment, per-project isolation
• OAuth 2.0 authorization server -- authorization code + PKCE (S256), client credentials grants, consent page, token refresh
• OIDC / SSO -- Google, Azure AD, Okta, any OpenID Connect provider
• Audit trail -- every access decision logged with correlation IDs, SOC/IR ready
• Self-hosted first -- Docker, Compose, Kubernetes, air-gap capable
• AWS SigV4 signing -- proxy signs requests so agents never see AWS access keys
• Response leak scanning -- outbound responses checked for credential exposure before reaching agents

Building from Source

git clone https://github.com/agentcordon/agentcordon.git
cd agentcordon
cargo build --release

Produces three binaries in target/release/:

Binary	Purpose
agent-cordon-server	Control plane server and OAuth authorization server (default port 3140)
agentcordon-broker	Broker daemon — holds OAuth tokens, vends credentials, proxies upstream requests (default port 3141)
agentcordon	Thin CLI for workspace agents — manages Ed25519 identity, signs requests to the broker

Configuration

Environment variables prefixed with AGTCRDN_:

Variable	Default	Description
AGTCRDN_PORT	3140	Server listen port
AGTCRDN_DB_PATH	./data/agent-cordon.db	SQLite database path
AGTCRDN_MASTER_SECRET	auto-generated	Master encryption key (persist in production)
AGTCRDN_ROOT_USERNAME	auto-generated	Admin username
AGTCRDN_ROOT_PASSWORD	auto-generated	Admin password (printed on first boot)
AGTCRDN_LOG_LEVEL	info	Logging level (trace, debug, info, warn, error)
AGTCRDN_LOG_FORMAT	json	Log output format (json or pretty)
AGTCRDN_BASE_URL	—	Server base URL, required for OAuth2 MCP flows (callback redirect URI)
AGTCRDN_SESSION_TTL	28800	Session TTL in seconds (default: 8 hours)
AGTCRDN_PROXY_ALLOW_LOOPBACK	false	Allow proxy to localhost targets (dev only)
AGTCRDN_BROKER_PORT	3141	Broker daemon listen port
AGTCRDN_BROKER_URL	—	Override broker URL
AGTCRDN_OAUTH_AUTH_CODE_TTL	300	OAuth authorization code TTL (seconds)

Project Structure

crates/
  core/       Domain types, Cedar policy engine, crypto (Ed25519, AES-256-GCM, HKDF), OAuth token storage
  server/     Axum HTTP server, OAuth authorization server, web dashboard, credential proxy, audit pipeline
  broker/     Broker daemon — OAuth token management, credential vending, upstream HTTP proxy
  cli/        Thin CLI — workspace identity (Ed25519), signed requests to the broker
migrations/   SQLite schema migrations
policies/     Default Cedar policy files

Security

• Deny by default. All access requires an explicit Cedar policy grant.
• Encrypted at rest. AES-256-GCM with per-credential HKDF-derived keys.
• No credential exposure. Credentials stay within the broker boundary; agents never see secrets.
• OAuth 2.0 with PKCE. Authorization code flow with S256 challenge, consent page, and token refresh.
• Ed25519 workspace identity. No shared secrets between CLI and broker.
• Full audit. Every credential access, policy evaluation, and token operation is logged.

To report a vulnerability: open a security issue

Contributing

Contributions welcome. Open an issue before submitting large changes.

cargo test --workspace
cargo clippy --workspace -- -D warnings
cargo fmt --all

---

Website · Issues · Releases