Box Release Notes

Now released: New MCP Server Platform Activity Report

We have officially launched the new MCP Server Platform Activity report. This upcoming report will deliver broader platform-level metrics and visibility into overall MCP server environment activity, complementing the granular tool execution tracking found in the Tool Calls report. It includes detailed platform data to help administrators track and monitor what content in Box is being used through the MCP Server.

For details on what is tracked in this report, see our documentation here: https://docs.box.com/en/box-admin-tools/reporting-and-insights/mcp-platform-activity-report#mcp-platform-activity-report

Report Renaming: MCP Server Activity Report is now the "MCP Server Tool Calls Report"

To better reflect the specific insights it provides, the Box MCP Server Activity report is now renamed to the Box MCP Server Tool Calls report.

What This Report Covers

The Box MCP Server Tool Calls report provides an overview of tool usage executed through the Box MCP server. It includes detailed event-level data to help administrators track and audit MCP server interactions.

• Report Data Columns:
  • Date: The date (in Pacific Time, PT) of the MCP server activity.
  • Integration ID: The unique identifier of the integration used to access the MCP server.
  • Integration Name: The name of the integration used to access the MCP server.
  • Integration Client ID: The client ID associated with the integration.
  • User Name: The full name of the user who performed the activity.
  • User Email: The Box email address of the user who performed the activity.
• Available Filters:
  • Date Range (Optional): Limit the report to past MCP server activity within a specific time period.
  • Users or Groups (Optional): Filter activities by specific managed users or user groups (defaults to all users and groups).
  • Integrations (Optional): Filter by one or more integration names (defaults to all integrations).

What You Need to Do

No Action Required: Existing reporting configurations and scheduled workflows will automatically reflect the updated report name.

Experience Cloud Toolkit for Salesforce

The Salesforce Developer Toolkit now includes the Experience Cloud Toolkit. Its global methods let you manage Box App Users for Salesforce Experience Cloud users:

• Create or reactivate a Box App User for the current or a specific Salesforce user.
• Deactivate a Box App User.
• Look up an existing Box App User linked to a Salesforce user.

Where to get support

Should you have any issues or need further guidance, please post a request to our developer forum for any help needed.

The latest version of the Box for Salesforce package is now available on Salesforce AppExchange. This release introduces new capabilities for Box Utility, along with improvements across Box for Salesforce features.

What's New

Box Utility – File Uploads

Box Utility now includes a File Uploads tab alongside Box Notes. From the Salesforce Utility Bar, users can upload files directly to the Box folder associated with a Salesforce record.

Users can upload either:

• Salesforce Files that are already attached to the record, or
• New files directly from their computer.

Uploaded files are saved to the same Box folder already linked to the Salesforce record. Learn more: Using Box Utility in Salesforce

Bug Fixes & Improvements

• Fixed an issue where Box Doc Gen generated documents with extra, incorrectly formatted tags for Salesforce fields that had no value.
• Fixed an issue where Box Doc Gen did not merge certain related field data when generating documents from records with multiple levels of related objects.
• Fixed the default minimum window size for Box Utility to ensure consistent display.

For questions or issues:

• Visit the Box Community
• Contact Box Support
• Review the Box for Salesforce documentation

We’ve released a new version of Box for Salesforce, now available for the download at the Salesforce AppExchange.

This release focuses on bug fixes and improvements to enhance the integration, including:

Box for Salesforce

Box Sign

• Improved Box Sign status sync consistency.
• Enhanced the Box Sign webhook to automatically retry when the Box Sign API status is behind the triggering event.
• Fixed an issue causing failed updates to appear as delivered skipping retry.
• Fixed an issue where the Box Sign scheduled sync reprocessed already-completed sign requests due to a truncated signer email value, causing repeated sync failures.
• Fixed an issue where a contact's phone number was not auto-populated when requesting SMS authentication for a sign request.
• Added a Box Sign Sync section to the Box Sign Configuration page in Box Settings, with a link to Using Box Sign Sync in Salesforce to help admins configure it correctly to receive real-time updates from Box Sign.

Box Doc Gen

• Fixed an issue where the Custom Object for Contact Details did not resolve correctly in Box Doc Gen templates.
• Fixed an issue where uploading a template in the Doc Gen Template Manager failed to collaborate the creating user on the new template folder.
• Fixed an issue where Box Doc Gen failed due to fields not present in the Salesforce API version.
• Added support for using lookups in Box Doc Gen name tags.

General

• Fixed an issue where collaborations on linked folders were removed or not added for the users.
• Added support for automatic collaboration in Box UI Elements when a Salesforce record ID is provided as input.
  • Note: Auto-collaboration does not apply when a hardcoded file or folder ID is used.
• Improvements to validation messaging during Box for Salesforce setup.

.. and other minor improvements and enhancements to the integration related to error messaging and usability.

For additional information, please refer to Box Support and Box for Salesforce documentation.

The misconception

If you've ever connected ChatGPT, Claude, or a custom MCP client to your Box account, you've probably thought: "As long as I block downloads, I'm safe. The agent can't take the file out."

The reality is harder. AI agents don't need to download a file to exfiltrate it. If an agent can preview a document, it can read it, comprehend it, and reproduce what's inside. From a data loss prevention perspective, an LLM reading content is functionally the same as downloading it. The moment your existing Integration Restriction stops at the download boundary, you have a gap.

Why this matters now

Enterprise workflows are moving from thousands of human users to a world where every user brings a handful of AI agents along with them. IDC projects that by 2028, roughly 70% of AI-driven enterprises will operate multi-tool, multi-agent architectures. That is a scale shift that human-era governance assumptions were not built for.

The structural problem is this: the controls that kept content safe from human misuse were designed around a click, a download, and an audit log. Agents don't click. They call APIs, they read text representations, and they answer questions on behalf of a user in seconds. Governing what an agent can read is now as important as governing what it can download, and it has to be enforced at the same layer, not bolted on later.

Architecture walkthrough

Architecture walkthrough

Classification-Based Access Policy extends the Integration Restriction security control in Box Shield with a new Read action, evaluated at request time against the classification on every file. Here is what happens end-to-end, stage by stage, with the security checkpoint named at each step.

A. Box user initiates access through a connected integration

A Box user initiated an action through a connected third-party integration. The integration sends the file requests to Box and identifies itself with an external serviceId. Box evaluates the integration’s serviceId to determine whether the requested action is allowed, blocked, or monitored.

B. Box Platform: SIS holds the rules

Shield's rule store (SIS) is the source of truth for every access policy an admin has configured. When an admin creates a Classification-Based Access Policy, the Download and Read toggles, the scope (block-all-except or allow-only), and the integration lists are persisted here. SIS also carries the enforcement mode for each action independently: enforce or monitor.

C. Box Platform: the enforcement engine decides

Every file access request from the connected integration lands in the enforcement engine. It pulls the file's current classification, looks up the restriction policy that applies to that classification in SIS, and evaluates the caller's serviceId against the Download and Read scopes independently. The policy evaluates the connected integration’s serviceId rather than the Box user alone. When a user accesses content directly, there is no restricted integration serviceId to block. When the user acts through a connected integration, the integration can be stopped by the Read restriction. Download and Read are two separately toggle actions on the same control, so an admin can block all integrations from previewing Confidential content while allowing a specific list to download, or any other combination.

D. Observability: every decision is logged

Every allow, block, and would-have-blocked (monitor mode) decision is emitted to the Event Stream API with the application ID, application name, action type (download or read), enforcement mode, file ID, user, and timestamp. Admins get full visibility into restriction activity across both action categories, without needing to instrument anything themselves.

E. Governed output: what the caller actually sees

When Read restriction fires, the integration receives a response with the classified content removed. It does not get a partial answer. It does not get the text representation.The caller can see the file exists (metadata is still returned today), but cannot ingest the content.

Architecture diagram

An enterprise scenario

Imagine a mid-market financial services firm. The compliance team classifies every deal document as Confidential the moment it lands in the M&A folder. A deal analyst uses ChatGPT as a connected integration to access their Box account and summarize public research faster.

Without Classification-Based Access Policy, the analyst opens the ChatGPT plug-in and asks it to summarize a document from the M&A folder. ChatGPT calls the preview endpoint, receives the text representation, and returns a clean two-paragraph summary of the target's non-public financials. The file was never downloaded. The content is now in the model's context.

With Classification-Based Access Policy enforced, the same request lands in the enforcement engine, is matched against the Confidential access policy, and is blocked at the read layer. ChatGPT replies that it cannot access the file. It proposes two workarounds: open in Box preview, or fetch the raw file. Both hit the same enforcement engine and both fail. The analyst still has their agent for public research. The M&A content stays inside the compliance boundary.

Questions your enterprise should ask

Questions your enterprise should ask

1. Can you tell, right now, which third-party integrations have ever previewed a Confidential file in your Box tenant?
2. If a user connects a new AI agent tomorrow, is your default posture "allow" or "deny" for reading classified content?
3. Do your integration policies distinguish between Download and Read as separate actions, or do you treat them as one?
4. Can you audit every read decision (blocked, allowed, or monitored) with the integration identity attached?

For most organizations, the honest answer to at least two of these is "not yet." Classification-Based Access Policy answers each of them directly. Read is a first-class action. Read restriction defaults to off, so no existing policy changes silently. Every decision is logged with the integration identity. And the same classifications you already trust drive the enforcement.

What you can build once this is governed

What you can build once this is governed

Because Read is now governed at the classification layer, you can safely:

• Roll out the Box MCP server to more teams, with confidence that Confidential and Internal content stays inside your rules.
• Approve new AI agents as they emerge without rewriting policy per app. Add the integration to the right Shield list, and the classification-based rules apply automatically.
• Adopt in monitor mode first. Run Read restriction in monitor for a classification to see who would have been blocked, then flip to enforce when you are ready.
• Extend the same identity-plus-classification pattern into your Event Stream consumers, so your SIEM sees agent activity the same way it sees user activity.

Bottom line

Bottom line

Classification-Based Access Policy is not a wrapper around the existing download control. It is a rebuild of the Integration Restriction enforcement path that treats Read as a first-class, independently governed action, tied to the classifications your business already trusts. One control, two independent toggles, every decision logged, and no path around it via preview, search, or text representation. That is what governing AI agents at enterprise scale looks like.