Central Auth: The Boring Platform Project That Keeps My Apps From Turning Into Permission Spaghetti

Central Auth is not the flashiest thing I have built. That is kind of the point.

When you build multiple apps, auth logic starts spreading before you notice it. One app has a role check. Another has a team table. A dashboard has a special admin flag. A background job has its own service token. A billing feature has a one-off entitlement. Then you try to answer a simple question like “who can do what?” and the answer is scattered across five repos.

I did not want every project to invent its own version of that mess. So I built Central Auth as shared plumbing for identity, permissions, entitlements, and auditability across the apps I am building.

You can call this governance if you want. The practical reason is much simpler: I do not want to debug permission spaghetti every time a side project becomes real.

The problem shows up slowly

Auth usually starts clean.

You add login. You add an admin role. You add a customer account. You add a feature flag. Then you add support access, team invites, billing plans, read-only users, internal tools, API tokens, and maybe an automation identity or two.

None of those decisions are wrong by themselves. The problem is that each app makes the decision slightly differently.

That creates annoying questions:

• Does admin mean the same thing in every app?
• Can support impersonate a user?
• Who approved that access?
• Does a background job have too much permission?
• What happens when someone leaves a team?
• Which app is the source of truth?

Once I am asking those questions, auth is no longer just application code. It is platform infrastructure.

What I want Central Auth to handle

Central Auth is meant to give my apps the same basic vocabulary:

• Who is acting?
• What account, workspace, or project are they acting in?
• What resource are they touching?
• What action are they trying to take?
• Is that action allowed?
• Why was it allowed or denied?
• What should be logged for later?

That sounds dry, but it makes everything else easier. Product code should not need to reinvent how users, tenants, roles, plans, support access, and automation identities work.

Permissions need boring names

One thing I have learned: clever permission names are a mistake.

I want names that are obvious in code review:

• project.read
• project.write
• deployment.approve
• billing.view
• user.invite
• admin.impersonate
• environment.modify

Same with resources:

• Organization
• Account
• Workspace
• Project
• Repository
• Environment
• Secret
• Deployment
• Dashboard

If a permission model requires a meeting to understand it, it is already too cute.

The platform has to be easy or teams route around it

A shared auth system can be technically correct and still fail.

If it is painful to integrate, every app will grow its own shortcut. I have seen that pattern enough times to respect it. The secure path has to be the easy path.

For Central Auth, that means I care about developer experience as much as policy design:

• Simple SDKs or middleware.
• Local dev support.
• Test helpers for permission scenarios.
• Clear examples.
• Useful error messages.
• Fast policy checks.
• Audit output that shows up where developers can actually use it.

The goal is not to make every app feel centralized. The goal is to give every app the same paved road for access control.

Audit logs should help engineers, not just compliance

A lot of audit logs are technically present and practically useless.

For Central Auth, I want audit records that help during real debugging:

• Actor
• Action
• Resource
• Decision
• Policy version
• Request source
• Correlation ID
• Human approval reference when relevant
• Before and after values for sensitive changes

If I cannot quickly answer why access was granted or denied, the system is not done.

This matters even more as AI agents and automation workers get access to repos, cloud tools, issue trackers, and internal dashboards. Automation identities need the same auditability as humans. Maybe more.

Break-glass access is real

Pretending emergency access will never happen is how teams end up with ugly backdoors.

I would rather make the emergency path explicit:

• Time-bounded access.
• Reason capture.
• Approval or notification.
• Extra logging.
• Automatic expiration.
• Review afterward.

That gives operators a safe escape hatch without turning the whole permission model into a suggestion.

Why this connects to Yaah and Autobot

Central Auth is not separate from the AI work. It is part of the same platform layer.

Yaah helps me see what AI agents are doing. Autobot runs AI-assisted GitHub issue work through a serverless Bedrock pipeline. Central Auth is the kind of foundation that decides what humans, services, and automation identities are allowed to do.

If an agent can touch repos, trigger workflows, open pull requests, or eventually interact with cloud resources, I need clean answers to permission questions:

• Which automation identity is acting?
• What repo or environment can it modify?
• Which actions require human approval?
• How are tool calls audited?
• When does temporary access expire?
• Who reviewed the resulting change?

I do not want a separate, sloppy permission model just because the actor is an AI workflow.

Where I would start again

I would not try to migrate every permission at once. That sounds productive and usually turns into a swamp.

I would start with high-leverage areas:

• Admin actions.
• User and team management.
• Deployment approvals.
• Secret or credential access.
• Billing or plan changes.
• Support impersonation.
• Automation identities.

Then I would expand once the model proves useful.

The trick is to make Central Auth valuable before it becomes mandatory. If a team can add a permission check quickly, write a test, and see the audit record immediately, adoption gets a lot easier.

The lesson

Central Auth is boring in the best way.

It removes repeated decisions. It gives apps a shared permission vocabulary. It makes access easier to review. It gives automation a safer place to run. And it keeps future projects from inheriting a pile of one-off auth choices made under deadline pressure.

That is the platform work I like: not glamorous, but it compounds.

I share more of my infrastructure automation, platform engineering, and project work at jonprice.io.