> ## Documentation Index
> Fetch the complete documentation index at: https://docs.box.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Guardrails in Box AI

<div className="article_labels_list" style={{display: 'none'}} dangerouslySetInnerHTML={{__html: "Admin , Established , Box AI , P1"}} />

Guardrails let you define the operational boundaries in which an agent or
workflow can act with your Box content. When you configure guardrails, you
decide where an action can run, which managed users it can affect, and how
it interacts with external users. This gives admins precise control over
automated activity and helps keep sensitive content protected while scaling
AI and workflow adoption.

Guardrails are currently available for Box Automate outcomes for Enterprise
Advanced customers. For product-specific setup, see
[Creating workflows in Box Automate](/en/box-automate/creating-workflows-in-box-automate#advanced-guardrails).
Guardrails for Box AI Studio agent actions and MCP tools are coming soon.

This article explains the constraint types you can configure, how each
option behaves, and the patterns to follow when defining allowlists and
denylists.

<Note>
  Not all actions referenced in this article are available across every Box
  product. Review the product-specific setup articles for [Box Automate](/en/box-automate/creating-workflows-in-box-automate).
</Note>

## Guardrail constraint types

You can configure three types of guardrail constraints:

* **Target Criteria** — controls where the action can run.
* **Managed User Criteria** — controls which internal (managed) users the
  action can involve.
* **External User Criteria** — controls how the action interacts with
  external users.

## Target criteria

Target criteria define the target location of the action. From the
**Target Criteria** dropdown, select one of the following:

* **No Restrictions** — no guardrails are applied to the target location.
* **Specific Items only** — define an allowlist of permitted targets.
* **All items, with exceptions** — define a denylist of blocked targets.

### Specific items only (allowlist)

**Select by Classification:** select one or more classification labels to
define the allowed target. To define criteria based on a classification
label, you must first have Shield classification labels configured in your
organization.
See [Classification Labels](/en/box-shield/shield-classification-labels-and-policies/classification-labels).

*Examples of using classification-based target criteria:*

* For **Delete File**, selecting **Internal Only** means only files
  labeled Internal Only can be deleted.
* For **Move File**, selecting **Internal Only** means files can only be
  moved into folders labeled Internal Only.

### All items, with exceptions (denylist)

**Select by Classification:** select one or more classification labels to
define the blocked target. To define criteria based on a classification
label, you must first have Shield classification labels configured in
your organization.
See [Classification Labels](/en/box-shield/shield-classification-labels-and-policies/classification-labels).

*Examples of using classification-based target criteria:*

* For **Delete File**, selecting **Restricted** means files labeled
  Restricted cannot be deleted.
* For **Move File**, selecting **External Sharing** means files cannot be
  moved into folders labeled External Sharing.

#### Do not allow on any externally accessible items

The **Restrict folders with external access** toggle is available only
when you select **All items, with exceptions**. Enable it to prevent the
action from running at any target location that is externally accessible.
A location is considered externally accessible when any of the following
are true:

* The target, any folder in its ancestor tree, or a Hub containing it is
  accessible to the public through a shared link.
* The target, any folder in its ancestor tree, or a Hub containing it is
  accessible to external collaborators.
* The target is owned by an external organization or user.

*Example:* with **Restrict folders with external access** enabled for
**Upload File**, a file cannot be uploaded to a folder (or any ancestor
folder) that has a shared link set to anyone can access, has external
collaborators, or is owned by an external user.

## Managed user criteria

For actions that involve internal users, use **Managed User Criteria** to
define which managed users the action can target. From the dropdown,
select one of the following:

* **No restrictions** — no managed user guardrail is applied.
* **Specific managed users only** — allowlist of permitted managed users.
* **All managed users, with exceptions** — denylist of blocked managed
  users.

After you select an option, type user names into the **Select users** text
box and choose the users you want to include.

Common uses of managed user guardrails:

* **Add Collaborator** — allow only a specific list of managed users to be
  added by a workflow.
* **Send Notification** — limit notifications to an approved list of
  managed users.

## External user criteria

For actions that involve external users, use **External User Criteria** to
define how the action can interact with them. From the dropdown, select
one of the following:

* **No restrictions** — no external user guardrail is applied.
* **Specific external users only** — allowlist of permitted external
  users.
* **All external users, with exceptions** — denylist of blocked external
  users.
* **External users not permitted** — blocks the action from involving any
  external user.

After you select **Specific external users only** or **All external
users, with exceptions**, enter user names into the **Select users** text
box and choose the users you want to include.

Common uses of external user guardrails:

* **Add Collaborator** — select **External users not permitted** to
  prevent any external collaborator from being added by the workflow or
  agent.
* **Send Notification** — limit outbound notifications to a defined list
  of external users.

## Known limitations

* Guardrails apply only to actions in Box Automate outcomes.
* Not every action supports every constraint type.
* Classification-based guardrails depend on the classification labels
  defined for your enterprise.
  See [Classification Labels](/en/box-shield/shield-classification-labels-and-policies/classification-labels).