Why deask

I somehow ended up working with authorization.

Not login pages, passwords or "Sign in with Microsoft" buttons. The part which happens afterwards.

The user is authenticated. We know who they are. Cool.

Now, can they do this?

Can they read this document? Can they update this customer? Can this service call that service? Can this application do something on behalf of a user?

That kind of authorization.

It is not exactly the most exciting area of software engineering. At least I never thought it was. Nobody gets into programming dreaming about permission matrices.

And then agents happened.

Software can do things now

My relationship with AI changed a lot over the last year. Not that long ago I was pretty skeptical about AI-generated code. Nowadays agents write most of the code I ship.

But writing code is kinda the boring example already.

Agents send emails, move calendar events, deploy applications, poke at infrastructure, buy things, query internal systems, create tickets, update documents and call pretty much any API we give them access to.

Software always could do all of that, obviously.

The difference is that before, we wrote the software, and we told it exactly when to do those things. Somebody sat down, thought through the flow, wrote an if, got it reviewed and shipped it.

Now we can just say:

Get a monitor for the new employee. Keep it under €800.

And let the software figure out the rest.

Which is very cool.

It also makes authorization suddenly much more interesting.

So, does the old model still fit?

Pretty much every authorization system I have worked with answers one question: can this identity do this action on this resource? User or service, orders:create, allowed or denied. Done.

That works well for two kinds of actors.

A human clicking buttons. The human decides every single action, the system just checks they are allowed to do it.

A service doing a predefined thing. A developer decided every action in advance, back when the code was written.

An agent is neither. It decides what to do at runtime, on my behalf, based on a sentence I typed while drinking coffee.

So take the monitor. What does the agent need? Access to some shop. A company card. Maybe the new employee's address from the HR system.

And what does the shop API actually see? Probably a token which says orders:create.

That's it. Nothing about a monitor. Nothing about the new employee. Definitely nothing about €800.

The same token lets the agent buy a €799 gaming chair and ship it to my house. Or fifteen monitors. Or a €801 monitor, because it was on sale yesterday and that's "close enough".

The instruction I gave was very specific. The permission it turned into is not.

To be fair, I am not sure the old model doesn't fit. Maybe OAuth, scopes and a decent policy engine are totally enough, and in a couple of months I will have to admit it. That's fine. Finding that out is kind of the point.

Why "authority layer"

I went back and forth on the wording quite a bit.

"Access control" didn't feel right. Access is about what you can touch. The agent in the example doesn't really need access to the shop. It needs something closer to a mandate: permission to go and do a specific job, for a specific person, within specific limits.

That's authority. It starts with a human, it gets handed over to someone (or something) else, it has limits, and you can take it back. We already use the word this way for people. Your manager gives you authority to spend some budget. You give a lawyer authority to sign one specific contract. Not "access to your bank account".

"Layer", because I don't think any of this replaces what we already have. OAuth, RBAC, policy engines - they are fine, and I am not about to reinvent them. If something is missing, it probably sits in between: between what a human actually asked for, and the crude permission check which eventually happens at the API.

Will it end up being a layer? No idea, honestly. It is a working title for a working idea.

What's next

In a typical developer fashion I would start by building a platform, and then go look for someone to use it. Not this time. Problem first, code last.

So for a while this place will be mostly notes. This is the first one. Roughly in this order, I want to look at:

• How software gets permission today, for anyone who hasn't spent years reading OAuth specs
• Delegation, and what it means for software to hold authority which started with a human
• What is actually different about agents, and why access is not authority
• Who is actually acting, when a human asks an agent, which asks a sub-agent, which calls an MCP server, which calls an API
• What task-scoped authority could look like
• Then building something tiny, to see if any of it survives contact with real code
• And then checking how much of my "new" problem existing tools already solve

…and whatever else comes up on the way.

Some of it will probably age badly. That's fine too.

Catch you in the next one.