The Missing Auth Layer for Agents

AI agents are getting surprisingly good at doing things. They can browse the web, write code, work with files, call APIs, use tools, and increasingly operate across different services.

But the more capable agents become, the more I keep coming back to a pretty fundamental problem:

How exactly do I give an agent permission to act as me?

Not permanent access to my account. Not my password. Not a token that quietly lives somewhere indefinitely.

Permission to perform this action, under these conditions, right now.

I don't think we have a great abstraction for that yet.

Authentication was designed for humans

Most authentication systems answer a relatively simple question: Are you really you?

Password. Passkey. Face ID. OTP. Security key. OAuth.

Once that's established, an application receives some level of access. That model works reasonably well when I'm the one clicking the buttons.

Agents introduce another actor. Now there is me, the agent, the service the agent wants to use, and potentially the application running the agent. Those are not necessarily the same trust boundary.

If I tell an agent:

Find the best flight to New York next Friday.

that's one thing. If I then say:

Book it.

we've crossed a pretty meaningful boundary. The agent has moved from reasoning about something to acting on my behalf.

Today we mostly solve this with credentials

The easiest way to make an agent useful is to give it access. Connect Google. Connect GitHub. Connect Slack. Connect your calendar. Connect whatever else it needs.

Usually OAuth makes this considerably safer than handing over a password. But there is still something that bothers me about the abstraction.

We often grant access based on: What application is requesting access?

I think agents increasingly need authorization based on: What action is about to happen?

Those are different things.

Imagine a permission broker for agents

I've been thinking about a layer that sits between agents and the services they want to act on. Call it an authorization broker for now.

You set it up once. Your accounts connect to the broker rather than every random agent environment you experiment with: Google, GitHub, X, YouTube, maybe financial services eventually—whatever you're comfortable connecting.

The broker becomes the place where you define what agents are allowed to request. Not necessarily what they're permanently allowed to do. What they're allowed to ask you to authorize.

An agent requests an action, not your credentials

Imagine I'm working with an agent and tell it:

Upload this video to my YouTube channel.

Instead of the agent holding some broadly privileged YouTube credential, it sends a structured request to my authorization layer.

Agent: Codex
Service: YouTube

Requested action:
UPLOAD_VIDEO

Resource:
demo.mp4

Visibility:
UNLISTED

My phone gets a request:

Codex wants to upload demo.mp4 to YouTube as Unlisted.

Allow once?

I authenticate with a passkey, biometric confirmation, or another trusted mechanism. The broker then grants a narrowly scoped authorization for that action. The agent performs it. The authorization expires.

That's it. The important thing is that the agent never needed my actual account credentials.

Permission should have context

This becomes more interesting when authorization includes more than a simple yes or no. Maybe I've configured:

GitHub

READ_REPOSITORY        ALLOW
CREATE_BRANCH          ALLOW
OPEN_PULL_REQUEST      ALLOW
MERGE_PULL_REQUEST     ASK
DELETE_REPOSITORY      NEVER
CHANGE_BILLING         NEVER

Now my agents have a predictable boundary. They don't need to interrupt me for things I've already decided are safe. But they also can't silently cross boundaries I care about.

An agent could inspect those capabilities before attempting an action. Instead of:

I tried to merge the pull request but I don't have permission.

it could know:

Merging requires user authorization.

and request it before proceeding.

The token should represent the action

Traditional access tokens often represent some version of: This application can access this account with these scopes.

For agents, I think a useful primitive might be closer to: This agent may perform this specific action on this specific resource under these conditions.

subject:
  user_123

agent:
  agent_xyz

service:
  github

action:
  merge_pull_request

resource:
  repo/project#482

expires:
  2026-08-24T23:42:00Z

uses:
  1

A single-use capability. Short-lived. Specific. Auditable.

If intercepted later, it shouldn't give someone broad access to my GitHub account. It shouldn't even allow another pull request to be merged.

This also creates a much better audit trail

There's another part of this that I think becomes increasingly important as agents do more work for us:

Who actually made the decision?

Imagine looking at an activity log and seeing:

10:41 AM

Claude requested:
MERGE_PULL_REQUEST #482

Reason:
Tests passed and requested changes were resolved.

10:42 AM

User approved request with passkey.

10:42 AM

Authorization issued.
Single use · Expires in 5 minutes.

10:43 AM

Claude executed:
MERGE_PULL_REQUEST #482

Result:
SUCCESS

Now there's a clear trail. The agent proposed something. The human authorized it. The service executed it.

That's much better than an audit log that simply says: Chirag merged pull request #482. Because eventually that might not actually describe what happened.

Agents should be identifiable too

The broker shouldn't only authenticate the human. It should know which agent is asking.

I might trust one coding agent to create branches in my repositories. I might allow another assistant to read my calendar. I might allow a personal agent to draft emails but never send them. Different agents should be able to receive different capabilities.

So authorization becomes something closer to:

User × Agent × Service × Action × Resource × Time

rather than simply:

User × Application

That feels much closer to the world we're moving toward.

The broker could become portable

The part I find especially interesting is separating authorization from any individual AI provider. Today I might use ChatGPT. Tomorrow I might use Claude. For coding I might use Codex. Another workflow might use a local model.

I don't necessarily want to reconnect my entire digital life every time I try another agent. Instead, I could authorize agents through something I control.

I need permission to create a calendar event.

My authorization broker already knows which calendar I use and what permissions I've configured. The agent doesn't need permanent access. It requests the capability. The broker handles the trust relationship.

That makes authorization portable across agents.

There are hard problems here

This sounds simple until you start thinking about the edge cases.

• What exactly counts as an action?
• How granular should permissions become?
• How do you prevent approval fatigue?
• How does an agent prove its identity?
• What happens when one authorized action triggers another action?
• How do you prevent a malicious agent from presenting a misleading description of what it's requesting?
• Who generates the human-readable authorization message: the agent or the broker? Probably the broker.
• What happens when an API doesn't support sufficiently granular scopes?
• How should delegated authorization work across multiple agents?

There are also obvious security problems around replay attacks, compromised agents, token leakage, phishing, and confused-deputy scenarios. This would need to be designed as security infrastructure, not just another confirmation dialog.

Approval can't become the new cookie banner

There is also a UX failure mode I really don't want. If every agent action causes Allow? Allow? Allow?, people will stop reading them. We already know how that ends.

The system needs to learn the boundary between:

• Always allowed
• Allowed under specific constraints
• Ask me
• Never allowed

Maybe I don't care when an agent creates a calendar event. But changing an existing event with other attendees requires confirmation. Maybe creating a Git branch is fine. Merging into main isn't. Maybe uploading a YouTube video as private is allowed. Publishing it publicly requires me.

Good authorization shouldn't constantly interrupt the user. It should make the user's boundaries machine-readable.

Why I think this becomes necessary

Agents are currently useful partly because their autonomy is still constrained. As they become capable of operating for hours, coordinating tasks, using more tools, and moving between services, simply giving them increasingly broad credentials feels like the wrong direction.

We need agents to become more capable. But capability and authority don't have to grow together. An agent can be extremely capable while still having very narrow authority.

I think that's an important distinction.

The question shouldn't just be: What can this agent do?

It should also be: What is this agent allowed to do for me?

And ideally, I should be able to answer that once in a way every agent can understand.

What I'd build first

I don't think the first version needs integrations with twenty services. I'd probably start with one.

GitHub would be interesting because the actions are easy to reason about:

READ_REPOSITORY
CREATE_BRANCH
PUSH_COMMIT
OPEN_PULL_REQUEST
MERGE_PULL_REQUEST
DELETE_BRANCH

Connect GitHub to a small broker. Register an agent. Define a few permissions. Let the agent request a capability. Send the user an approval request. Issue a short-lived, single-purpose authorization. Execute the action. Record the entire chain.

Then see where the model breaks.

Because as agents become better at acting for us, I think we're going to need infrastructure that sits between:

I asked my AI to do this.

and

My AI has access to everything.

There should be something in between. I think that missing layer is authorization.