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.
Fastest to build.
Also the easiest way to accumulate technical debt.
You end up with:
The “proper” solution.
For every provider you need to: Repeat this for every integration.
Your authentication layer quickly becomes larger than the product you’re actually trying to build.
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.
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.
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:
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:
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 github
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:
⸻
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:
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:
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.