How We Solved Agent Auth Without a Single PAT

A TOFU-based authorization model for headless AI agents

By Mohamed Sherif

If you’ve built an AI agent recently, you’ve probably run into the same problem.

The first integration is easy.

Your agent needs access to GitHub, so you create a Personal Access Token (PAT), add it to .env, and move on.

GITHUB_PAT=ghp_xxxxxxxxxxxx

Then you add Slack.

SLACK_BOT_TOKEN=xoxb-xxxxxxxxxxxx

Then Notion.

NOTION_TOKEN=secret_xxxxxxxxxxxx

Then Linear.

LINEAR_API_KEY=lin_api_xxxxxxxxxxxx

Before long your AI agent depends on a growing collection of long-lived credentials scattered across local environments, CI/CD pipelines, Kubernetes secrets, and production infrastructure.

It works.

Until it doesn’t.

⸻

The Problem Every Agent Builder Eventually Hits

Traditional software authenticates users.

AI agents authenticate themselves.

That’s a subtle but important difference.

OAuth was designed around a human sitting in front of a browser who can click Allow when an application requests access.

AI agents don’t have browsers.

They don’t have users.

They don’t have anyone available to approve access while they’re running.

Most developers eventually fall back to one of four patterns.

1. Personal Access Tokens

Fastest to build.

Also the easiest way to accumulate technical debt.

You end up with:

• long-lived secrets
• credentials living in runtime memory
• manual rotation
• no attribution
• difficult incident response

1. Custom OAuth

The “proper” solution.

For every provider you need to:

• register OAuth applications
• handle callbacks
• encrypt refresh tokens
• refresh access tokens
• manage expirations
• build consent flows

Repeat this for every integration.

Your authentication layer quickly becomes larger than the product you’re actually trying to build.

1. Secrets Managers

AWS Secrets Manager, Vault, Azure Key Vault…

These solve storage.

They don’t solve authorization.

Someone still has to provision credentials.

The agent still eventually receives them.

There’s still no approval workflow and no way to distinguish one agent from another.

1. Service Accounts

Convenient.

But every agent sharing that account effectively becomes the same identity.

If one agent is compromised, every workload using that service account is affected.

⸻

What We Actually Wanted

After looking at these approaches, we realized we wanted something fundamentally different.

Our requirements were surprisingly simple.

• Agents should never receive long-lived credentials.
• Humans should approve new agents exactly once.
• Every action should be attributable to a specific agent.
• Revoking one agent shouldn’t impact every other deployment.
• Existing agent frameworks shouldn’t need to change.

That combination turned out to be harder than expected.

⸻

Borrowing an Idea from SSH

The breakthrough came from an unexpected place.

SSH solved a very similar problem years ago.

The first time you connect to a server, SSH asks:

“Do you trust this host?”

If you approve it, the server fingerprint is remembered.

Future connections are automatic.

If the fingerprint changes unexpectedly, SSH warns you.

This model is called Trust On First Use (TOFU).

We asked ourselves:

What if AI agents worked the same way?

⸻

Applying TOFU to AI Agents

Instead of trusting a server fingerprint, we trust an agent fingerprint.

The first time an unknown agent requests access to a connected service:

1. The gateway pauses the request.
2. The owner receives an approval notification.
3. The owner approves (or rejects) the agent.
4. The fingerprint is stored.
5. Future requests from that fingerprint proceed automatically.

Visually, the flow looks like this:

Developer connects GitHub once
│
▼
Gateway stores OAuth credential
│
▼
Developer gives agent one Passkey URL
│
▼
Agent requests GitHub access
│
▼
Unknown fingerprint?
│
Yes ─────────► Human approval
│
▼
Fingerprint trusted
│
▼
Short-lived token exchanged
│
▼
Agent calls GitHub

The important distinction is what the agent doesn’t receive.

It never sees:

• OAuth refresh tokens
• Personal Access Tokens
• stored credentials
• client secrets

Instead, it receives a short-lived token for the current session.

⸻

Fingerprints Instead of Secrets

Every agent has an identity.

Rather than identifying it with a shared secret, we derive a fingerprint from characteristics of its runtime.

That fingerprint becomes the identity we authorize.

This enables several useful properties.

Attribution

Every API request can be tied back to one specific agent identity.

Audit

You know exactly which agent accessed which service and when.

Revocation

Deleting one trusted fingerprint immediately blocks that agent without rotating credentials or redeploying infrastructure.

Blast Radius Reduction

A compromised agent only affects itself.

Not every deployment using the same credentials.

⸻

What Integration Looks Like

Connecting a service happens once through the dashboard.

After OAuth completes, the credential stays inside the gateway.

The agent configuration remains extremely small.

{
"mcpServers": {
"passkey": {
"command": "npx",
"args": ["passkey-mcp"]
}
}
}

From the perspective of LangChain, CrewAI, Strands, Bedrock AgentCore—or any MCP-compatible framework—nothing changes.

The agent simply discovers tools like:

github_list_issues
githubcreate_comment
slackpost_message
linearcreate_issue
notion_query_database

The authentication layer becomes invisible.

⸻

Why We Chose Token Exchange

One design decision deserves explanation.

Instead of proxying every request, the gateway performs a token exchange.

Once authorized, the agent receives a short-lived upstream token.

The API traffic then goes directly to the provider.

That provides several advantages:

• lower latency
• no gateway bottleneck
• no proprietary protocol
• compatibility with existing MCP tooling

⸻

Other Design Decisions

Rotating Connection URLs

Connection URLs use rotating slugs.

Capturing yesterday’s URL isn’t enough to gain access.

It must also match a trusted fingerprint.

Dynamic Client Registration

Where supported, every customer receives their own OAuth client rather than sharing one across the platform.

That reduces rate-limit contention and isolates failures between organizations.

MCP-Native

Rather than invent another SDK, we built around MCP.

Any framework that already supports MCP can use the same authentication model without additional integration work.

⸻

When This Approach Makes Sense

This model is particularly useful if:

• your agent talks to multiple SaaS platforms
• you’re deploying beyond prototypes
• credential management has become operational overhead
• you need attribution and auditability
• security teams don’t want PATs spread throughout infrastructure

If you’re building a weekend project with one integration, a PAT is probably sufficient.

Once multiple integrations and production deployments enter the picture, the trade-offs begin to change.

⸻

Try It

If you’re interested in experimenting with this model, install the local broker:

npx passkey-mcp

Then manage everything through:

👉 https://dashboard.v2n2x.com

Connect your first OAuth provider through the Passkey dashboard, then point any MCP-compatible agent at it.

Today the platform supports 19 integrations including GitHub, Slack, Jira, Confluence, Notion, Stripe, Salesforce, HubSpot, and Linear.

I’d love to hear feedback from developers building production AI agents.

The biggest question we wanted to answer was simple:

Can we eliminate long-lived credentials from AI agents without making developer experience worse?

So far, the answer has been yes.