Policies & ABAC

Nembl includes an IAM-style policy engine that provides fine-grained access control beyond what roles alone can achieve. Policies use an Allow/Deny model with support for attribute-based access control (ABAC) through tag-based conditions.

Policy Model

Each policy is a JSON document with the following structure:

{
  "effect": "Allow" | "Deny",
  "resource": "services:*",
  "actions": ["create", "update", "delete"],
  "conditions": {
    "tags": {
      "department": "engineering",
      "environment": "production"
    }
  }
}

Field	Description
effect	`Allow` grants permission; `Deny` blocks it
resource	The resource type the policy applies to (e.g., `services`, `workflows`, `requests`, `secrets`)
actions	List of actions to allow or deny (e.g., `create`, `read`, `update`, `delete`, `publish`, `execute`)
conditions	Optional tag-based conditions that must match for the policy to apply

Resource Types

Policies can target the following resource types:

Resource Type	Available Actions
`services`	create, read, update, delete, publish
`workflows`	create, read, update, delete, publish, execute
`requests`	create, read, update, assign, close
`organizations`	create, read, update, delete
`teams`	create, read, update, delete, manage_members
`users`	invite, read, update, disable
`policies`	create, read, update, delete
`secrets`	create, read, update, delete
`agents`	create, read, update, delete, configure
`connections`	create, read, update, delete

Use wildcards to match all resources (*) or all actions (*).

Creating a Policy

Navigate to Settings > IAM > Policies.
Click Create Policy.
Select the effect (Allow or Deny).
Choose the resource type from the dropdown.
Select the actions this policy governs.
Optionally add tag conditions (see ABAC below).
Assign the policy to a user, group, or role.
Click Save.

Policy Evaluation Rules

Nembl uses a two-tier evaluation model that distinguishes between inherited policies (from roles, groups, and teams) and direct user policies.

Evaluation Order

Gather all applicable policies -- from the user's roles, groups, team memberships, and direct assignments.
Check for explicit Deny -- if any inherited policy denies the action, it is denied by default.
Check for direct Allow override -- if a policy assigned directly to the user allows the action, it overrides an inherited Deny.
Check for explicit Allow -- if any policy allows the action and no Deny applies, the action is allowed.
Default Deny -- if no policy matches, the action is denied (implicit deny).

Key Rule: Direct Allow Overrides Inherited Deny

This is the most important evaluation rule. If a group policy denies workflows:publish but the user has a direct policy that allows workflows:publish, the direct Allow wins. This allows admins to create broad group-level restrictions while granting targeted exceptions to specific users.

Inherited Deny (from group)    +    Direct Allow (on user)    =    Allowed
Inherited Deny (from group)    +    No direct policy          =    Denied
Direct Deny (on user)          +    Any Allow                 =    Denied

A direct Deny on the user always wins -- it cannot be overridden.

Attribute-Based Access Control (ABAC)

ABAC extends the policy model with tag-based conditions. Instead of writing a separate policy for every resource, you tag resources and write policies that match tags.

Tagging Resources

Resources in Nembl can be tagged with key-value pairs:

Open any service, workflow, or other resource.
Navigate to the Tags section.
Add tags as key-value pairs (e.g., environment: production, department: engineering, sensitivity: high).

Writing Tag-Based Policies

A policy with tag conditions only applies when the target resource has matching tags:

{
  "effect": "Deny",
  "resource": "workflows",
  "actions": ["delete", "update"],
  "conditions": {
    "tags": {
      "environment": "production"
    }
  }
}

This policy denies deleting or updating any workflow tagged environment: production. It has no effect on workflows without that tag.

Common ABAC Patterns

Pattern	Tags	Policy
Protect production resources	`environment: production`	Deny `update`, `delete` for non-admin groups
Restrict sensitive data access	`sensitivity: high`	Deny `read` except for the "Security" group
Department-scoped services	`department: engineering`	Allow `read` only for the "Engineering" group
Limit AI agent actions	`agent-restricted: true`	Deny `execute` for agent roles on flagged workflows

Multiple Tag Conditions

When a policy specifies multiple tags, all tags must match (AND logic):

{
  "effect": "Deny",
  "resource": "secrets",
  "actions": ["read"],
  "conditions": {
    "tags": {
      "environment": "production",
      "sensitivity": "high"
    }
  }
}

This denies reading secrets that are tagged as both production and high sensitivity.

Best Practices

Start with roles, add policies for exceptions. Roles handle the common case; policies handle edge cases.
Use Deny sparingly. Broad Deny policies can be hard to debug. Prefer narrow, targeted denies.
Tag consistently. Establish a tagging convention (e.g., always use environment, department, sensitivity) and enforce it across your organization.
Test with Effective Permissions. After creating policies, check a user's effective permissions to verify the result matches your intent.
Document your policies. Use the policy description field to explain why a policy exists, not just what it does.

Groups & Teams Responsibilities