For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
Logo
DeveloperAcademyCommunityStatus
ReferenceGuides
ReferenceGuides
  • Agent Studio
    • Overview
    • Quickstart Guides
    • Core Concepts
    • Conversation Process
    • Actions
    • Connectors
    • System Triggers
    • Agent Architect
    • Cookbooks
    • Development and Testing
      • Logs
      • End-User Access Control
        • Launch Permissions
      • Plugin Management
      • Common Errors
      • Plugin Go-Live Checklist
    • AI Agent Marketplace
    • Developer Tools
  • Agentic AI
    • LLM Fundamentals
    • The Agentic Reasoning Engine
    • Memory Constructs
    • Conversational Context
    • Guardrails
    • Grounding and Hallucinations
    • Continuous Learning
    • LLMs & SLMs
    • Steerability Tools
    • Multilingual Support
  • Core Platform
    • User Identity
    • Moveworks Agent (On-Prem)
    • Approvals Engine
    • Entity Catalog
    • Moveworks Data Objects
    • Security Information and Event Management (SIEM) Logs Overview
DeveloperAcademyCommunityStatus
On this page
  • Strategy 1: Access Control by System Authentication
  • Strategy 2: Access Control by Design
  • Strategy 3: Access Control In Moveworks (aka. Launch Rules)
Agent StudioDevelopment and Testing

End-User Access Control

||View as Markdown|
Was this page helpful?
Edit this page
Previous

Launch Permissions

Your launch configuration determines how your plugin is deployed to your AI Agent
Next
Built with

When building plugins, consider these three access control strategies:

Strategy 1: Access Control by System Authentication

This strategy uses the access control policies defined by your external system to enforce access control. There are three tiers of system-based authentication integrations.

Option 1: Using JWT User Claims

The user’s information is passed in your JWT claims. Your business system then executes any APIs as if they were executed by that user. This preserves the audit trail & permissions of the target user.

See instructions for JWT Auth here.

Option 2: Using OAuth 2.0 Authorization Code Authentication

This is similar to Option 1 (JWT User Claims), but involves a user step to grant permission before the bot can take action.

See instructions for OAuth 2.0 Authorization Code here.

Option 3: Using RPA Tools

When the proper integration APIs are not available with your tools, browser-based RPA is a good fallback. Since RPA logs into applications on behalf of users the keystrokes & button clicks they execute follow that user’s permissions.

Strategy 2: Access Control by Design

A common scenario is ensuring users only see their records. In this design approach, you rely on data attributes on the record to determine if the user should have access to it.

Record TypeExample SystemUser
TicketITSM (e.g. ServiceNow)“Caller” / “Watcher”
AccountCRM (e.g. Salesforce)“Owner”
Job ApplicationATS (e.g. Greenhouse)“Hiring Manager”
PTO BalanceHCM (e.g. Workday)“Employee”

In this scenario, you

  1. Pass the user’s information into your API based on your HTTP action’s data bank
  2. Query the record of interest that the user wants to see or modify. You may filter records by the user’s account.
  3. Check the data attributes of that record (Find the watcher/caller/hiring manager)
  4. Throw an error if the user shouldn’t have privileges

This requires you to “mirror” the access control logic of your downstream system in your process/experience APIs.

Strategy 3: Access Control In Moveworks (aka. Launch Rules)

After publishing a use case, you can tailor its availability to specific audiences using “rules”. This is especially useful when users lack licenses, allowing you to define a default access control policy.

You can pull user attributes from any system to craft these rules. See our user identity documentation for more details.