Skip to main content
When deploying AI within your MoEngage workspace, understanding what the agent is allowed to do and how your data is protected is critical. This guide outlines the permission scopes and enterprise security guardrails governing Custom Agents. For an introduction to core concepts, refer to Custom Agents: Overview.

​
Agent Permissions: What is an Agent Permitted to Do?

A Custom Agent’s capabilities are bounded by the tools you assign to it during configuration.

​
How Capabilities are Derived:

  • Tool Assignment: An agent can only perform actions for which it has an explicit tool. If an agent is assigned Read campaign analytics but not Create campaign drafts, it is fundamentally impossible for that agent to alter or create any campaigns, regardless of what the user types in the chat prompt. For steps to assign tools, refer to Assign Tools.
  • Read vs. Write Boundaries: Read-only tools allow the agent to fetch and analyze data. Write tools allow the agent to modify data.
  • Hard System Limits: Even with full write permissions assigned, Custom Agents do not possess auto-send or publish capabilities. They are restricted to creating drafts and editing, pausing, resuming, or stopping existing campaigns — never launching or publishing a new one. Final deployment requires human intervention through the standard MoEngage builder.

​
Data Privacy, Security, and Governance

Because Custom Agents process real workspace data including campaign metadata, analytics, and custom segments, MoEngage enforces strict data governance protocols to meet enterprise security standards.

​
Data Handling and Model Training

You retain complete ownership and control of your proprietary data.
  • Zero Model Training: MoEngage does not use your workspace data, user segments, campaign content, or session transcripts to train Merlin AI or any foundational Large Language Models (LLMs).
  • Data Isolation: All data processed during an agent session is strictly isolated within your specific MoEngage workspace. Agents cannot cross-reference data from other organizations or environments.
  • Shared Memory Scope: Custom Agents write to a memory store shared across your workspace, so a fact one agent records is readable by every other agent in the same workspace. That store never crosses into another workspace or organization, and reading it grants no access beyond what the running user’s permissions already allow. Its contents cannot be viewed or cleared from the dashboard or through an API, and deleting an agent leaves the facts that agent contributed in place. For details, refer to Agent Memory.

​
Overlap with Role-Based Access Control (RBAC)

Custom Agents respect your organization’s existing governance structure.
  • When a user interacts with a Custom Agent, the agent operates within the intersection of its assigned tools and the user’s underlying MoEngage RBAC permissions.
  • If a user does not have the native MoEngage permission to view financial analytics or modify specific campaigns, the agent cannot bypass those restrictions to fetch or alter that data on the user’s behalf.
  • Beyond RBAC, MoEngage restricts editing, publishing, pausing, and deleting an agent to its creator. Any other workspace member with access to a public agent can run or duplicate it, but cannot change or remove it. For the full list of creator-only actions, refer to Manage Custom Agents.
  • MoEngage restricts schedule configuration and edits to the agent’s creator, because every scheduled run executes using the creator’s permissions rather than the permissions of whoever views the dashboard when the scheduled run fires. For steps to configure a schedule, refer to Set a Trigger.
  • A scheduled run authenticates as its creator. If the creator’s stored credentials for a required tool are missing, that tool reports a credential error instead of running.
  • When an agent delegates part of a task to a sub-agent, the sub-agent executes with the permissions and credentials of the user who starts the run rather than those of the sub-agent’s creator. A sub-agent keeps its own tool assignments, so a coordinator restricted to read-only tools can delegate to a sub-agent that holds write tools. That tool list is not an escalation path: MoEngage authorizes each MoEngage data or campaign action against the running user’s live permissions at the moment of the call, so a delegated write fails if that user cannot perform it themselves. Delegation gives a coordinator’s creator no access that they do not already hold. MoEngage also blocks a builder from adding another user’s private agent to a roster, so delegation never reaches an agent the builder cannot see. For details, refer to Build Multi-Agent Workflows.
  • A connector authenticates the user who starts a session rather than the user who built the agent, so an agent reaches an external application only with the access that user granted from their own account. For details, refer to Connect External Apps to Custom Agents.

​
Compliance Guardrails

Every action taken by an agent is fully logged and auditable.
  • Traceability: Every tool execution, including the exact parameters used and the time of execution, is recorded in the underlying audit log. The transcript displayed in the dashboard may not show every recorded tool call.
  • Immutability: Individual transcript events cannot be edited by users. Deleting an agent archives its session history rather than erasing it — MoEngage retains the record for auditing, but the history becomes inaccessible through the standard gallery interface. For details on reviewing a transcript, refer to Anatomy of a Session Transcript.