DCR and the Agent Era: Why Static Credentials Are Dead

For the last 20 years, applications have authenticated using static credentials: an API key, a client secret, a bearer token that lives in a config file and never changes.

This works fine for humans. You log in once, you get a session token, it lasts for days or weeks. For applications and agents, it’s a problem.

An agent that runs in your infrastructure needs to call APIs — your company’s internal services, third-party SaaS, whatever. How does it authenticate? It reads a client secret from somewhere (an environment variable, a file, a secret manager). That secret never rotates. If it leaks, an attacker has permanent access.

OAuth 2.0 solved this with Dynamic Client Registration (DCR).

The Problem: Static Agent Credentials

Imagine an AI agent that manages your infrastructure. It needs to:

• Call your internal APIs to fetch deployment info
• Call Stripe to check billing
• Call Slack to send notifications

How does the agent authenticate to each service?

Old way: Give it static credentials. Store a Stripe API key, a Slack token, an internal service secret somewhere. Hope they don’t leak.

Problems:

1. Credential sprawl: The agent carries multiple credentials. Each is a secret to manage.
2. No rotation: Static credentials don’t rotate. If one leaks, you’re exposed indefinitely.
3. No scoping: A single credential grants all permissions. If the agent is compromised, the attacker has full access.
4. Audit nightmare: You can’t easily tell which agent used which credential.

DCR: Dynamic Credentials for Agents

Dynamic Client Registration (RFC 7591) lets an agent request a new credential from an authorization server on demand. The flow:

1. Agent starts up
2. Agent presents its identity proof (e.g., a signed JWT) to the authorization server
3. Authorization server verifies the agent’s identity
4. Authorization server issues a fresh OAuth 2.0 client (client_id + client_secret)
5. Agent uses those credentials for the current session
6. Agent shuts down, credentials are discarded
7. Next time the agent starts, it gets a fresh credential

Each agent instance gets a short-lived credential. If a credential leaks, it’s only useful for that one agent run. Next time the agent starts, it’s a different secret.

DCR in Practice: MCP Agents

Model Context Protocol (MCP) brings this to life. An MCP server (e.g., your company’s internal service) needs to authenticate MCP clients (e.g., Claude, Cursor, or a custom agent).

With DCR:

1. MCP client connects to MCP server
2. Client proves its identity (e.g., via OAuth 2.0 Bearer grant)
3. Server issues a new client registration
4. Client receives a fresh client_id and client_secret
5. Client uses those to make subsequent requests
6. When the client disconnects, credentials are revoked

The benefit: each MCP client session gets unique, short-lived credentials. If Claude accesses your internal API via MCP, it gets a credential just for that session. When the session ends, the credential is worthless.

Why This Matters for Agents

Least privilege: An agent can request a credential scoped to exactly what it needs. Instead of “give the agent all access to Stripe,” you get “this agent session can read invoice data for the next 30 minutes.”

Auditability: Every credential is tied to a specific agent instance at a specific time. You can audit which agent did what.

Security recovery: If an agent is compromised, you revoke its current credential. It stops working immediately. No need to hunt down and replace a static secret embedded in a config file.

Operational ease: Agents manage their own credential lifecycle. No human has to rotate secrets by hand.

Implementing DCR

If you’re building a service that agents (or other applications) will call:

1. Implement OAuth 2.0 client credentials flow. This is the standard agent authentication mechanism.
2. Add DCR support. Implement RFC 7591 so clients can register themselves dynamically.
3. Scope credentials carefully. Issue credentials with minimal permissions. An agent reading data shouldn’t be able to delete it.
4. Set expiration. Credentials should expire after a reasonable time (hours, not days or weeks).
5. Revoke on demand. Let agents revoke their own credentials when they shut down.

A minimal DCR endpoint:

POST /oauth/register
{
  "client_name": "my-agent",
  "grant_types": ["client_credentials"],
  "scope": "read:data"
}

Response:
{
  "client_id": "abc123",
  "client_secret": "xyz789",
  "expires_in": 3600
}

The agent now has a credential valid for 1 hour. It can use it to authenticate. When the hour is up, it either requests a fresh one or stops making requests.

The Future: Agents as First-Class Citizens

As agents become more common, the authentication model has to change. Static credentials are a legacy of a time when all the actors in a system were long-lived (humans, services, applications running for months or years).

Agents are different. They’re ephemeral. They might run for seconds or hours, not months. Each agent instance is new. Authentication has to match that reality.

DCR + OAuth 2.0 gives us that model. It’s not perfect yet — we’re still building the tooling and standards around agent identity. But it’s the direction the industry is moving.

What This Means for You

If you’re building infrastructure agents, MCP servers, or SaaS APIs that agents will call:

1. Think about agent authentication early. Don’t bake in static credentials.
2. Implement OAuth 2.0. It’s the standard.
3. Add DCR support. Let agents request credentials dynamically.
4. Scope credentials. An agent shouldn’t be a skeleton key.

The agent era is here. Authentication needs to evolve with it.