Permissions
AgentPermissions is the model that constrains what the agent is allowed to do in your app. It's a simple, explicit set of switches and lists — no implicit inference — so you always know exactly what surface area the agent can touch.
The permissions object
interface AgentPermissions {
canNavigate: boolean;
canFillForms: boolean;
canInteractUI: boolean;
canSubmitForms: boolean;
allowedScreens?: string[];
blockedScreens?: string[];
allowedActions?: AgentActionType[];
}
| Field | Meaning |
|---|---|
canNavigate | Whether the agent may emit navigate actions. |
canFillForms | Whether the agent may emit form_fill actions (filling fields, without necessarily submitting). |
canInteractUI | Whether the agent may emit ui_interaction actions (press, scroll, swipe, focus, set value). |
canSubmitForms | Whether a form_fill action is allowed to set submitAfterFill: true. |
allowedScreens | If set, restricts the agent to only this list of screen names — everything else is off-limits. |
blockedScreens | Screen names the agent may never navigate to or act on, even if otherwise allowed. |
allowedActions | If set, restricts which AgentActionType values the agent may use at all. |
Allow/block-list semantics
allowedScreens and blockedScreens work together as a coarse allowlist/denylist over screen names:
- If
allowedScreensis set, only screens in that list are in scope — anything not listed is treated as off-limits, regardless of the boolean flags above. blockedScreensalways wins: a screen listed there is excluded even if it also appears inallowedScreens.- If neither list is set, all screens are in scope, and the four boolean flags are what constrain the agent's behavior.
allowedActions works the same way at the action-type level: if set, it's the exhaustive list of AgentActionType values the agent may use (navigate, form_fill, ui_interaction, scroll_list, confirm, custom); anything not listed is disallowed.
Default behavior
If you don't configure permissions at all, the SDK defaults to fully open: all four booleans are true and no allow/block lists are set. Permissions are opt-in to restrict, not opt-in to enable — so if you want the agent scoped down, you need to configure it explicitly.
Where permissions are configured
Permissions can be set in more than one place, and they layer together:
- SDK config — passed as
AppilotsConfig.permissionswhen initializing the SDK (see SDK: AppilotsProvider). .appilotsrc— the same shape, set once in your project's.appilotsrcfile so it applies without touching app code.- The dashboard — configured per project at app.appilots.com, letting you change the agent's allowed surface without a new app build. See Dashboard: permissions, budget, personalization for how this is managed.
For how permissions are actually applied at runtime — including the SDK's local defense-in-depth checks alongside server-side enforcement — see SDK: permissions.
Related pages
- Agent actions — the action types these permissions gate
- SDK: permissions — applying
AgentPermissionsin your app - Dashboard: permissions, budget, personalization — configuring permissions from the dashboard