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

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.

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

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:

docker compose up -d

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

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 and opens a browser for OAuth consent on first run.

From your agent's project directory:

agentcordon init
agentcordon register

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

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

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

• 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
• 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

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

Produces three binaries in target/release/:

Environment variables prefixed with AGTCRDN_:

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

• 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

Contributions welcome. Open an issue before submitting large changes.

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

Website · Issues · Releases