Enterprises were buying Cortx licenses for different roles and users — with no way to enforce who could access what. Every user had the same permissions. Every admin was flying blind. I built Role-Based Access Control from zero — a permission system that made enterprise governance possible without making it painful.
When an enterprise buys software, they're not buying access for everyone equally. They're buying specific capabilities for specific people in specific roles. An operations lead shouldn't be able to reconfigure AI agents. A viewer shouldn't be able to delete a workflow someone spent a week building.
Cortx had none of this. Every user who was onboarded got the same permissions — full access to every module, every configuration, every piece of enterprise data. There was no concept of a role. No concept of a permission. No concept of an admin.
RBAC in enterprise software is almost always designed for one person: the IT administrator. The result is a system that works for that person and nobody else. Cortx's admin users were more varied than that — and I designed for both.
Security-first mindset. Comfortable with complex permission models. Needs granular control, audit trails, and the ability to connect Cortx to the organisation's existing identity infrastructure — CyberArk, LDAP, Azure AD. Will configure the system once and expect it to enforce itself reliably.
A product manager, team lead, or operations director given admin rights for their team — but with no interest in becoming an IT specialist. They need to onboard their team, assign the right access levels, and get out of the way. They don't want to think about inheritance hierarchies or identity provider configurations.
Most enterprise tools are built for one type of user and quietly ignore the other. I defined Agent Playground to serve two distinct users on the same underlying framework — different entry points, not different products.
They know what they want the agent to do but have never thought about models, tools, or knowledge sources as separate configurable layers. They needed progressive disclosure — the most important controls first, advanced configuration available but not imposed.
They know what they're doing. They don't need guidance through every layer — they want direct access to configuration, fast. An advanced mode that bypasses the guided flow and lets them work directly on the assembly environment.
Before any design or engineering work started, I defined the complete permission architecture — what could be controlled, at what level of granularity, and how roles mapped to access. Click each role below to explore what it can do.
Full access to all modules, all settings, and all users. Can change billing, transfer ownership, and configure identity providers. The single highest-trust role in the system — one per workspace.
Certain features within each module are premium — available only to enterprises on higher license tiers. Before RBAC, these features were visible to every user regardless of their license. I defined the license-permission bridge that connected what was commercially agreed to what was actually accessible in the product.
Every enterprise already has an identity system. Before RBAC, Cortx existed completely outside of it — a separate island of users and credentials with no relationship to the organisation's existing IT infrastructure. I defined and shipped integration with three of the most common enterprise identity platforms.
CyberArk is the privileged access management platform used by enterprises with the strictest security requirements. Integration with CyberArk meant that Cortx could participate in the enterprise's broader privileged access workflows — session recording, credential vaulting, and just-in-time access provisioning. For security-heavy industries, CyberArk integration was a procurement requirement, not a nice-to-have.
RBAC has real depth — multiple role types, module-level granularity, custom role creation, audit logging, license-tier integration, and identity provider connectivity. The challenge wasn't building the depth. It was making that depth invisible to the people who didn't need it.
Click each decision to reveal the reasoning behind it.
I chose to handle role-based access at the module level and license-based access at the feature level — as two distinct, complementary layers rather than one unified permission system. The alternative was a single system controlling everything at the feature level — maximum flexibility, maximum complexity.
When a user doesn't have access to a premium feature, they see it — with a lock icon and an upgrade prompt — rather than not seeing it at all. The alternative was hiding premium features entirely from users on lower tiers.
When defining how external identity providers interact with Cortx's internal role system, I had to decide which system wins when there's a conflict. The options were: identity provider controls everything, Cortx controls everything, or a clean split between the two.
There was pressure to defer audit logs — ship the core role and permission system first, add logging in a follow-up sprint. The argument was reasonable: logging is complex to implement and the core RBAC value doesn't depend on it.
Good product decisions aren't just about what you ship. They're about what you choose not to — and being clear-eyed about why.
RBAC didn't produce a metric I can point to. What it produced was a category of enterprise deal that wasn't possible before it existed — and a set of capabilities that fundamentally changed what Cortx could promise to enterprise clients.