Bring Your Own Identity Provider for AI Agents: Binding an OIDC Identity to an Overlay Address

Your agents have keys. Your company has an identity provider. Right now, those two worlds don't talk, and it's your job to connect them.

Here's the situation I kept running into: the platform team stands up a fleet of autonomous agents, each one minting its own cryptographic identity. Then the security team asks the inevitable question — how do we bring your own identity provider for AI agents, so an agent's identity means something to the rest of the org? They want the agent to authenticate against the same OIDC/OAuth IdP as every employee and service account. Same governance, same lifecycle, same audit trail.

This post is a practical how-to for that exact problem: linking an agent's keypair-based identity to an existing IdP so the agent is addressable both inside the overlay network and inside your corporate identity system.

Why an agent's identity starts as a keypair, not a login

Agents on a peer-to-peer network don't get usernames. They get addresses derived from keys. On Pilot Protocol, for example, every agent holds a permanent virtual address that survives restarts, IP changes, and moves across clouds — the identity is the key, not the host.

That's the right foundation: a machine identity that can sign and encrypt, that can't be spoofed by claiming a hostname. X25519 key exchange and signed handshakes beat password auth for unattended processes, because there's no human to type a password and no session to steal.

But a keypair answers "who is this agent?" only in the cryptographic sense. It doesn't answer "is this agent allowed to touch our production data?" That's a question your IdP already answers for every other principal in the company. The trick is making the two answers agree.

The two-identity problem

You now have two identity systems describing the same agent:

World	Identity	Issued by	Verified by
IdP (OIDC/OAuth)	client_id + claims	Your identity provider	Token signature (JWKS)
Overlay network	Public key / virtual address	The agent itself	Peers, at handshake

The overlap problem is real. An agent with address N:1234.ABCD.5678 might map to service account agents/checkout-worker in your IdP — or it might be a rogue instance claiming to be that worker. Nothing in the overlay world knows about the IdP world unless you make it.

The good news: you don't need to replace either system. You need a binding between them. Here are the three patterns I've actually used, in increasing order of ceremony.

Pattern 1: Present IdP-verified claims at handshake time

The overlay's trust model is an explicit handshake — two peers mutually approve before any traffic flows. That approval step is the natural enforcement point for IdP policy.

The flow:

1. The agent authenticates to your IdP (OIDC client-credentials flow, or a device flow if a human bootstraps it) and receives an ID token.
2. During the overlay handshake, the agent presents that token alongside its public key.
3. The receiving peer (or a policy agent acting on its behalf) validates the token signature against your IdP's JWKS endpoint, checks the claims — aud, expiry, group membership — and only then approves the handshake.

No new infrastructure. Your IdP stays the source of truth for "is this principal valid", and the overlay stays the source of truth for "can this address reach me". The binding is the signed token.

Pattern 2: A broker agent vouches for its fleet

If your agents are short-lived or spawn dynamically, making every peer verify JWKS signatures is noisy. Instead, run one well-known "registration agent" that holds a long-lived trust relationship with both worlds.

• Agents authenticate to the IdP once, through the broker.
• The broker verifies the token, then handshakes the new agent and attests to the fleet: "I vouch for this address; it holds IdP claims for agents/checkout-worker."
• Other peers trust the broker's attestation instead of doing their own token dance.

This is the same delegation pattern you already use for employee onboarding — a trusted authority performs the verification, everyone else trusts the result. It also gives you one place to revoke: kill the broker's attestation and the agent loses its standing in the fleet.

Pattern 3: Private networks with join rules

For the coarsest control, don't let strangers onto the shared network at all. Pilot Protocol supports private networks with group-level connectivity and join rules — you define who may join, and agents outside the allowlist simply can't reach the group.

This doesn't replace IdP binding, but it layers on top of it: the IdP decides who the agent is, the join rules decide whether it's in your network. Combined with pattern 1 or 2, you get identity verification at two independent layers, which is exactly what a zero-trust posture wants.

What the handshake actually looks like

Concretely, with Pilot's CLI, the enforcement point is the trust commands. On the receiving side:

pilotctl pending                # incoming handshake requests
pilotctl approve <node_id>      # approve after your policy check

And on the initiating side:

pilotctl handshake <peer> "agent authenticating as agents/checkout-worker (IdP token attached)"

The reason this pattern works is that Pilot's trust model is explicit — membership and trust are decoupled. Joining the network doesn't make you trusted; a peer has to approve you. That's the hook your IdP policy hangs on: approval can be gated on token verification instead of being automatic.

Where the two worlds meet, cleanly

What I like about this setup is that neither system contorts itself:

• The agent keeps its cryptographic identity — a permanent address it can be reached at, regardless of NAT or cloud moves. That's the overlay's job.
• The IdP keeps its job — issuing verifiable claims about principals, with expiry and revocation.
• The binding is a signed token exchanged at an explicit trust boundary.

If you want the full picture of the addressing and trust model — what an address is, how handshakes work, how private networks and join rules are configured — the trust model documentation covers it in detail, including the exact commands for handshakes, approvals, and network join rules.

Bring your own identity provider for AI agents: the takeaway

Bringing your own identity provider for AI agents isn't about choosing between cryptographic identity and corporate identity. It's about binding them at the right enforcement point. Handshake-time token verification, a vouching broker, and network join rules are three ways to do it, and they compose.

The agents get addresses that survive infrastructure churn. The IdP gets a seat at the table for every agent that joins your fleet. And the security team gets an answer to their question that doesn't start with "well, actually...".

If you're setting this up yourself, the install is one command:

curl -fsSL https://pilotprotocol.network/install.sh | sh

Then handshake, verify, approve — and your agents are both addressable and auditable.