access policies are one of those things that touch every team but belong to none of them.

engineering builds the permission checks into the code. product decides which users should see which features. security sets the rules around what's too risky to allow. and when something goes wrong, all three look at each other.

most teams spend a lot of time thinking about user authentication. who can log in, how, with what credentials.

and then the services behind the scenes just... trust each other. because they're on the same network. because they're in the same VPC. because nobody questioned it when the architecture was first drawn up.

A user gives an agent a task. Maybe it needs to read invoices, update a CRM record, check an internal dashboard, or call a few APIs on their behalf. The easy model is to let the agent act with whatever access the user already has.

But I am not sure that makes sense once the user has a lot of authority. If I can delete a workspace, change billing, export customer data, or invite an admin, does an agent helping me with one task need access to all of that too Giving the agent its own identity and narrower permissions sounds safer. But then another question comes up: how narrow can those permissions be before the agent keeps hitting boundaries halfway through the task?

So I am curious how teams building agents are thinking about this today.

Does the agent inherit the user s authority? Does it get its own identity with access only to specific APIs or actions? Or are you handling this another way? And where do you draw the line between the user is allowed to do this and the agent is allowed to do this for the user ?

I was thinking about this because it sounds like such a small product decision, but I don t think it actually is.

Someone signs up with Google. Six months later they are on their iPhone and tap Sign in with Apple. Same person, different identity provider. And if they use Hide My Email, you may not even get the same email address.

So what should the product do?

Creating a new account feels wrong because now their history, billing, settings, or subscription can end up split across two profiles. But automatically linking accounts based on email also feels risky, because now you are assuming that matching email addresses are enough proof that both identities belong to the same person. And then Apple makes it even messier because the emails may not match at all.

it starts clean. admin, editor, viewer. three roles, clear boundaries, everyone knows what they can do.

then the product grows. a customer needs access to one thing but not another. a team member needs editor rights in one context and read-only in another. someone asks for a role that's basically admin but without the billing tab. and suddenly you have eleven roles, three of them named some variation of 'editor-but-not-really,' and nobody is confident the permissions are actually right anymore.

Passkeys are objectively better than passwords.

Phishing-resistant, nothing to forget, nothing to breach, no password database to leak. the case for them is pretty airtight. and yet most products still default to email and password. most users have never set up a passkey. most developers have never shipped one.

Every fast-growing company seems to have the same quiet migration story. They picked an auth tool early because it was fast to set up, free enough that nobody really had to think about it, and honestly, it was probably the right call at the time. Nobody is evaluating whether a login system can survive an enterprise deal when they are 10 people and just trying to ship the product.

Then the growth actually happens. The company gets to 50 employees, maybe starts selling to bigger customers, and the first serious enterprise prospect sends back a procurement checklist with SSO sitting somewhere near the top, non-negotiable. That is usually when you realise SSO lives on a tier that costs more than the entire tool used to cost you, or in some cases is not even available anywhere near the plan you are already three years deep into. So now you have a migration project nobody planned for, timed exactly when the company can least afford the distraction. And auth migrations are not exactly like swapping out an analytics tool. They touch active sessions, integrations built against the old system, login flows, permissions, and every customer already using the product, all while the deal that triggered the panic is still sitting in procurement waiting for an answer.

I don't really think this is a story about any one vendor being careless. It feels more structural than that. Tools built to be generous and fast at the small end tend to hit a hard ceiling right when a company starts needing enterprise features. And tools built enterprise-ready from day one usually come with an onboarding process and cost that a five-person team has absolutely no reason to take on early. There is a weird gap in the middle where very few products seem designed around the assumption that the same company might actually grow from one end to the other while staying on the same stack.

Has your team already hit that wall, or are you still early enough to see it coming before it costs you a deal?

most apps have a session timeout. almost nobody knows why it's set to whatever number it's set to.

ask around and you'll usually get one of three answers. 'that's just the default.' 'someone picked it a while ago and we never changed it.' or 'i think security asked for it but i'm not sure why.'

I talk to founders every week and the pattern repeats. The team needs login, someone says "how hard can a login form be," and two quarters later they are maintaining an identity system nobody wanted to own and the actual roadmap is on fire.

The problem is that auth looks like one feature but it is actually five products stacked on top of each other:

• Every sign-in method your users expect (passkeys alone took our team over 800 engineering hours to get production ready)

• Session management that survives a real security review, which arrives with 40 questions you have not thought about

• Token infrastructure, issuance, rotation, revocation, the part that pages someone at 2am

• Permissions, because plain roles stop working the moment your product grows

• And now identity for AI agents acting on behalf of your users, which no in-house auth from two years ago was designed for

Each of these is somebody's entire company. Your team will build all five as a side quest, and then maintain them forever.

you hit logout. the app says you're out. but somewhere, on another device, on another app using the same login, your session is still alive.

most users assume logout means logout everywhere. it doesn't. it usually means logout from this tab, on this device, right now. everything else keeps running until the token expires.