Custom Roles and Auditable Access Reviews

AI Rule Engine has always shipped five built-in roles: Read, Write, Run, Debug, and Admin. They cover most teams, and they still do. What they cannot do is describe an access model narrower than the five names we picked, and they cannot produce the thing an auditor actually asks for, which is not a roles page but a dated list of who could see what.

Both are now solved on the Enterprise plan with custom roles and Access Review. Below Enterprise, nothing changes: the five built-in roles work exactly as they always have.

Roles you define, not roles we picked

An organization admin can define up to 25 custom roles. Each one is a Name (up to 50 characters), a Description (up to 255 characters), and a multi-select of the permissions it grants. Roles are matched by name and assigned to people on the environment editor screen, alongside the built-in roles you already use.

Custom roles are additive by design. Assigning one only adds capability to a person; it never removes anything they already have. That is a deliberate constraint, not an omission. A role that could subtract permissions turns access into an ordering problem, where the answer to “can this person do X” depends on which grants were applied in which sequence. Additive-only means a role is always readable on its own: it says what it gives, and that is all it does.

Six permissions are available to any role:

• Read - view rulesets, logs, and run history
• Write - create and modify rulesets, conditions, action sets, schedules, and variables
• Run - execute rulesets
• Debug - see debug-level log detail
• Admin - full control of the environment, including its users
• View PII values - see real context values in a trace instead of redacted placeholders

The first five are the built-in roles, now available as ingredients. The sixth is new, and it is the reason this release exists.

Seeing what fired without seeing whose data it was

By default, trace and log data shows redacted placeholders in place of subject values. The structure of the run is fully visible - which rules were evaluated, which fired, what each condition decided, what each action wrote - but the values belonging to the person the decision was about are masked. Only a role that includes View PII values reveals the real ones.

That single toggle makes a genuinely useful role possible: grant everything except View PII values, and you get an operator who can debug the system completely while the customer’s actual data stays masked the entire time.

Take a support engineer working a ticket about a loan application that was denied. With this role they open the trace and see the whole story: the income-threshold rule evaluated false, the credit-tier rule never fired because its input was missing, and a fallback rule wrote the denial. They can tell you precisely why the decision came out the way it did, and file a bug against the rule that was actually wrong. What they never see is the applicant’s SSN, date of birth, or address - those read as redacted placeholders throughout, in the trace and in the logs.

This is the part worth sitting with. “Give this person access to debug the system” and “give this person access to the customer’s personal data” are two different decisions, made for different reasons, answering to different policies. Until now they were the same checkbox. They are not anymore.

An access review you can actually export

Any member of the organization can look at what a given role grants, which is exactly what you want available before you assign one to someone. The full Access Review table is admin-only: a point-in-time report of every person’s access to every environment, showing their built-in roles, their custom roles, and the resolved effective permissions those combine into.

It is generated fresh each time an admin loads the page. There is no cached report to go stale between the moment access changed and the moment somebody asked about it.

One detail matters more than it first appears. A grant can be flagged implicit, meaning it does not come from that person being on the environment’s user list at all - it comes from them being an organization admin. The table says so directly, and warns that removing them from the environment’s user list would not revoke the access, because the access flows from their org-admin status instead. That is the exact misunderstanding that produces a confident, wrong answer during an audit, and it is now printed next to the grant that causes it.

Admins can export the whole roster as CSV or JSON, dated. When someone asks you to demonstrate that the access roster was reviewed on a given day, that file is the answer - not a screenshot, not a recollection, but the actual resolved state of every grant in the organization at the moment it was pulled.

Open your organization settings, define the roles your team actually needs, and export the first review.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team