The Permission Portability Problem: Rethinking Auth for AI Agents

or why oauth doesn't cut it

When Anthropic's computer use demo dropped, I wanted to try it, but my first thought was "not on my computer". So, I hacked a way for me to launch an EC2 instance, run Anthropic's container on the instance, then stream the results to my browser. It worked pretty well but I very quickly ran out of interesting use cases to test on a brand new EC2 instance in the cloud.

The Permission Problem

This highlighted what I call the permission portability problem. For an agent to do anything interesting, it has to be able to take actions on my behalf. This is not a problem if I'm running an agent locally on my mac. I'm already logged into everything. The agent can just do things and they'll "just work" in the same way things "just work" if another human being hijacked my laptop.

On the other hand, an agent running on a brand new EC2 instance in the cloud cannot take any actions on my behalf because it has no access to any of my permissions. Further, there is no ergonomic and secure way for me to assign permissions to the agent running on that instance. I could copy my secrets into the instance, but I'm too paranoid to do that.

Why Current Auth Models Don't Work

OAuth today doesn't quite cut it because a lot of OAuth today is handled during build time. Think about how you build a GitHub app - you set up OAuth during development and deployment. But agents need something more dynamic. They need to be able to act on behalf of different users, with different permissions, at runtime.

Learning From AWS IAM

Interestingly, AWS has already solved a version of the permission portability problem with IAM. When an EC2 instance needs to access S3:

1. The instance is assigned an instance profile (which is just a special type of IAM role)

2. The instance can request temporary credentials from the metadata service

3. These credentials are automatically rotated

4. You can audit all actions through CloudTrail

5. You can revoke access by changing the role permissions

This is way better than copying long-term credentials onto instances. It's also better than build-time OAuth because the permissions are dynamic - you can change the role's permissions and it immediately affects what the instance can do.

What We Actually Need

But we need more than what IAM provides. Think about how an agent working on development tasks might need access to GitHub for code, AWS for deployment, Slack for notifications, and JIRA for ticket updates. We need true permission portability across platforms.

When an agent is acting against any third party service, that service needs to:

1. Recognize the identity of the agent

2. Determine if the agent is authorized to take the intended action

3. Maintain an audit trail of the actions taken by the agent identity

4. Allow the delegator to revoke permissions from the agent

Building "IAM for Agents"

What we need is "IAM for agents" - a cross-platform service that provides the same kind of dynamic, secure permission delegation that IAM provides within AWS, but for everything. This system would need:

1. Agent identities that work anywhere - whether running locally or in the cloud

2. Runtime permission delegation instead of build-time configuration

3. Fine-grained permission control across different platforms

4. Clear audit trails for all agent actions

5. Instant, global permission revocation

The Path Forward

The technical patterns for this already exist - AWS and others have shown how to build these systems. The hard part is getting the ecosystem to adopt a standard model for agent authentication and authorization. Until then, the permission portability problem will continue to limit what we can do with AI agents, forcing us to choose between running them in limited local environments or dealing with insecure workarounds in the cloud.

This isn't just a technical problem. It requires rethinking how identity, permissions and trust work in a world where software can increasingly act autonomously on our behalf. The platforms we use every day need to evolve their auth models to support this new paradigm.