Skip to main content

AI Policy Authoring

The AI Policy Author turns a natural-language description of an access rule into a concrete policy definition — RBAC roles and permissions, ABAC policy rules, or Zanzibar namespace schemas. The generated output is shown for review before you apply it, so the AI is a drafting aid, not an automatic approver.

Use this when you want to go from "here is what should be allowed" in plain English to a working policy quickly. The more specific your description, the better the draft.

Prerequisites​

  • An AI provider configured on the server (AI_PROVIDER, AI_API_KEY).
  • Access to /orgs/{orgId}/portal/access-management/policy-author.

How It Works​

  1. Describe your policy in natural language.
  2. The AI generates the corresponding RBAC, ABAC, or Zanzibar configuration.
  3. Review and edit the draft.
  4. Apply to create the roles, permissions, policies, or tuples in your organization.

URL: /orgs/{orgId}/portal/access-management/policy-author

Examples​

RBAC Generation​

Input:

"Create roles for a project management app. Project managers should be able to create, edit, and delete projects and assign team members. Team members can view projects and update tasks. Viewers can only see project details."

Generated Output:

roles:
  - name: Project Manager
    slug: project-manager
    permissions:
      - projects:create
      - projects:edit
      - projects:delete
      - projects:assign-members
      - tasks:read
      - tasks:write

  - name: Team Member
    slug: team-member
    permissions:
      - projects:read
      - tasks:read
      - tasks:write

  - name: Viewer
    slug: viewer
    permissions:
      - projects:read
      - tasks:read

ABAC Generation​

Input:

"Only allow users with MFA enabled to access financial reports. Restrict access to business hours on weekdays. Block access from countries outside the US and EU."

Generated Output:

policies:
  - name: Financial Reports - MFA Required
    subject: user.mfa_enabled = false
    resource: type = "financial-report"
    decision: DENY

  - name: Financial Reports - Business Hours
    resource: type = "financial-report"
    environment:
      - env.time < 09:00 OR env.time > 18:00
      - env.day_of_week in ["saturday", "sunday"]
    decision: DENY

  - name: Financial Reports - Geo Restriction
    resource: type = "financial-report"
    environment: env.country not in ["US", "DE", "FR", "GB", "NL", "IE", ...]
    decision: DENY

Note how all three policies use DENY — under the deny-overrides combining algorithm, any match blocks access, which is the right shape for a restriction rule.

Zanzibar Namespace Generation​

Input:

"Design a document sharing system. Documents belong to folders. Folders belong to workspaces. Workspace admins can do everything. Folder editors can edit documents in their folder. Document viewers can only read."

Generated Output:

namespaces:
  workspace:
    relations:
      admin: [user]
      member: [user]
    permissions:
      can_manage: [admin]
      can_view: [admin, member]

  folder:
    relations:
      parent: [workspace]
      editor: [user, workspace#admin]
      viewer: [user, workspace#member]
    permissions:
      can_edit: [editor, parent.can_manage]
      can_view: [can_edit, viewer, parent.can_view]

  document:
    relations:
      parent: [folder]
      editor: [user, parent.editor]
      viewer: [user, parent.viewer]
    permissions:
      can_edit: [editor, parent.can_edit]
      can_view: [can_edit, viewer, parent.can_view]
      can_delete: [parent.can_manage]

Using the Policy Author​

Step 1: Write a Description​

Be specific about:

  • Who should have access (roles, groups, user attributes).
  • What they should access (resources, actions).
  • When/Where access is allowed (conditions, constraints).

Step 2: Review the Draft​

The generator returns a policy scoped to your chosen model (RBAC, ABAC, or Zanzibar), with consistent naming and a complete set of permissions for the case you described.

Step 3: Edit if Needed​

Adjust names, tighten conditions, remove unnecessary rules, or add missing ones before applying.

Step 4: Apply​

Click Apply Policy to create the roles, permissions, ABAC rules, or Zanzibar tuples in your organization.

Tips for Better Results​

TipExample
Be specific about actions"can create, edit, and delete" instead of "can manage"
Name your actors"Project managers should..." instead of "some users should..."
Mention edge cases"External contractors can view but not download"
State conditions explicitly"only during business hours" or "only from corporate IPs"
Reference existing resources"for the documents and folders in our file system"