you're moving fast, you've shipped login, it works, users are in. and then an enterprise prospect shows up and the first thing they ask is 'do you support SSO?' and suddenly the thing you built in a weekend is blocking a six-figure deal.

but SSO is usually just the first question. after that comes the security questionnaire. then someone asks about audit logs. then their IT team wants to know how they'll provision and deprovision users at scale. then legal asks about data residency.

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 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.

Every product has that one auth decision that made complete sense at the time, but became a pain to change later.

Maybe you set sessions to 30 days because users hated logging in again.

every app that uses OAuth shows you a consent screen.

here are the permissions this app is requesting. the list is there, the allow button is there, and almost nobody reads it before clicking.

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.

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.

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.'

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.