Evaluate RBAC

Overview

You pass a subject with roles, an action, a resource, and an explicit role→permission policy; we evaluate it deterministically and fail closed. Permissions come only from the policy map — role names never imply access. Wildcards match only when you set allowWildcard to true. We return the decision, matched roles and permissions, and a plain explanation. Do not use this for attribute-based rules or as a policy store.

A boolean answer tells you nothing when someone asks why access was granted. Here every allow names the role and the exact permission string behind it, and a role that is not in your policy grants nothing, however privileged its name sounds.

When to use it

Scope

Non-goals

• Does not store or version policies
• Does not infer permissions from role names alone
• Does not evaluate attribute-based conditions

Properties

Capabilities

Cost & billing

Flat rate per invocation

File handling

How we handle your data

Input schema

Output schema

API contract

curl -sS -X POST "$BASE/v1/execute" -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{"skillKey":"identity.evaluate_rbac","input":{"subject":{"id":"u1","roles":["admin"]},"action":"delete","resource":"doc","policy":{"rolePermissions":{"admin":["delete:doc"]}}}}'

import { Squillify } from "@squillify/sdk";

const sq = new Squillify({ apiKey: process.env.SQUILLIFY_API_KEY });

const { output } = await sq.execute("identity.evaluate_rbac", {"subject":{"id":"u1","roles":["admin"]},"action":"delete","resource":"doc","policy":{"rolePermissions":{"admin":["delete:doc"]}}});

Errors

Other limits

Limitations

• Does not store or version policies
• Does not infer permissions from role names alone
• Does not evaluate attribute-based conditions
• Attribute-based access (use identity.evaluate_abac)
• Persisting authorization decisions
• Assuming a role name grants access without an explicit policy entry

How to call

POST /v1/execute (requires authentication)

{
  "skillKey": "identity.evaluate_rbac",
  "input": {
    "subject": {
      "id": "u1",
      "roles": [
        "admin"
      ]
    },
    "action": "delete",
    "resource": "doc",
    "policy": {
      "rolePermissions": {
        "admin": [
          "delete:doc"
        ]
      }
    }
  }
}

Examples

{
  "subject": {
    "id": "u1",
    "roles": [
      "admin"
    ]
  },
  "action": "delete",
  "resource": "doc",
  "policy": {
    "rolePermissions": {
      "admin": [
        "delete:doc"
      ]
    }
  }
}

{
  "decision": "allow",
  "matchedPermissions": [
    {
      "action": "delete",
      "resource": "doc",
      "role": "admin"
    }
  ],
  "matchedRoles": [
    "admin"
  ],
  "explanation": "Allowed by 1 matching permission(s)."
}

{
  "subject": {
    "id": "u1",
    "roles": [
      "user"
    ]
  },
  "action": "delete",
  "resource": "doc",
  "policy": {
    "rolePermissions": {
      "admin": [
        "delete:doc"
      ]
    },
    "defaultDecision": "deny"
  }
}

{
  "decision": "deny",
  "matchedPermissions": [],
  "matchedRoles": [],
  "explanation": "No matching permission; default decision 'deny' applied."
}

Recommended use cases

• Explainable permission checks before you enforce access in your app
• Preview whether a role grants a specific action on a resource
• Audit which role and permission string matched an allow decision

Avoid for

• Attribute-based access (use identity.evaluate_abac)
• Persisting authorization decisions
• Assuming a role name grants access without an explicit policy entry

Related skills

Composable with

Safety & privacy

• Runs without calling any external service.
• Your payloads are never stored permanently.
• Telemetry captures metadata only — never your payload contents.
• We never train models on your payloads.
• No human reviews your payloads.

Tags