Agents

Agent Permissions and Access

Role-based access model for Admin, Support, and Brand users, including action boundaries and governance.

Definition #

Agent Permissions and Access defines who can view, edit, manage, and operate Agents based on role and scope.
In Zirpa, access is typically controlled by role context (Admin, Support, Brand-level users) plus brand ownership boundaries.

Why it matters #

A clear access model prevents accidental changes, data leaks, and operational confusion.
It also ensures the right users can move quickly while governance stays intact.

How it works #

Access is evaluated using two dimensions:

  1. Role level

    • Admin: full operational control across permitted scope.
    • Support: elevated troubleshooting access, often with controlled boundaries.
    • Brand user: limited to assigned brand(s) and day-to-day operations.

  2. Scope boundary

    • Global scope (platform-wide) or brand scope (restricted).
    • Read-only vs write permission per feature area.

When a user opens an Agent page, the system checks role + scope before allowing actions like Edit, Save, Publish, Import, or Delete.

Configuration fields #

Typical access controls to document and standardize:

  • Role type: admin / support / brand
  • Brand scope: all brands vs assigned brands only
  • Edit permission: can modify Agent configuration
  • Operational permission: can run support actions or candidate-side operations
  • Sensitive actions: import/export, reset/retry actions, destructive changes
  • Audit visibility: who can view action logs

Example scenario #

A support user can open an Agent in support mode to diagnose a candidate issue, but cannot change ownership or cross-brand settings without explicit permission.
A brand user can update content and step logic only inside their assigned brand.

Common mistakes #

  • Granting broad write access to users who only need read access
  • Mixing support troubleshooting permissions with permanent admin rights
  • Forgetting to align import/export permissions with governance policy
  • Not documenting which role is allowed to publish production changes

Troubleshooting checklist #

  • Confirm the user role (Admin / Support / Brand)
  • Confirm brand assignment and active brand context
  • Verify whether the blocked action is read, edit, or publish-level
  • Check if support mode restrictions are being applied
  • Review access-denied logs for role/scope mismatch
  • Re-test with a known admin account to isolate permission vs feature bug

Last updated Mar 28, 2026