Access lets you in. Permission decides what you can actually do.
As more users join Anjin - and as we expand from individual workflows to collaborative environments - the question of who gets to do what is becoming central to the way we design the platform.
We’re not just building user features.
We’re building systems of responsibility.
And that means taking a hard look at how permission is structured - not just at the admin level, but at every layer where agents can be deployed, observed, or triggered.
Why This Matters (and Sneaks Up on You)
In the early days, it was simple.
You built agents. You ran agents. You got results.
But then the platform started growing:
- Teams wanted shared workspaces
- Admins wanted visibility into usage
- Developers wanted to trigger agents programmatically
- Internal staff needed elevated views for support and monitoring
Suddenly, the line between “access” and “permission” became very real.
We didn’t want to wait until something broke. So we got ahead of it.
The Core Principle: Role ≠ Power
In most platforms, roles are static:
- Admin = full access
- Editor = limited access
- Viewer = read-only
But agents introduce nuance:
- Should everyone in a workspace be able to edit agent config?
- Who can assign or revoke tokens?
- What if a billing admin wants reporting access - but shouldn’t trigger flows?
That’s why we’re leaning into permission granularity. Roles are helpful - but not enough.
How We're Structuring It
We’re rolling out permission logic that’s:
- Context-aware: Some permissions are global; others are agent-specific or tied to domain ownership
- Plan-sensitive: What you can do depends on your tier (but never in a confusing or punitive way)
- API-aligned: Roles extend to integrations - so third-party apps can only do what they’re explicitly scoped to
- Audit-ready: Every permissioned action is traceable, so nothing happens without a record
Behind the scenes, we use Supabase RLS and Edge Functions to enforce all of this - so no one can bypass logic via the frontend or API.
This isn’t just about trust. It’s about certainty.
A Few Examples We're Handling Now
Here’s where permission shows up (often in subtle ways):
- Credit allocation: Who can spend vs who can top up?
- Agent visibility: Who can see what others are building - or not?
- Execution controls: Who can run an agent, and who can only view its results?
- Swap history: Who can reset domain usage or view past swaps across a team?
These aren’t edge cases. They’re everyday product moments.
And handling them well makes the whole experience feel more robust.
What We're Still Exploring
We’re also thinking about:
- Temporary permission escalation – time-boxed elevated roles for debugging or collaboration
- Granular webhooks – only send certain events to certain tools
- Delegated agent management – allowing a non-technical user to “own” an agent without breaking its config
- Role visibility toggles – so internal ops teams can support without overreaching
This all ties back to a bigger theme:
Safety by design, not by default.
Final Thought: Governance is a Product Feature
Permission design is one of those things you don’t notice -until it breaks.
Until someone triggers something they shouldn’t.
Or until a helpful team member deletes a shared agent by mistake.
At Anjin, we’re not just giving access.
We’re building a platform that understands how power should work - and makes that transparent, traceable, and trustworthy.
That’s what permission means here.
And it’s only getting sharper.
Have feedback on how you’d like to manage access in a shared AI workspace?
Join the community, or revisit the rest of the series:
- Inside Anjin #08: Measuring What Matters
- Inside Anjin #07: What Happens When Agents Talk to Each Other
- Inside Anjin #06: The Modularity Mindset
