Box AI Security: What the New Agent Controls Cover, and What They Do Not

Box announced new agent security and governance controls on July 22, 2026: prompt injection detection that checks every input against known injection patterns before it reaches a model, MCP guardrails that scope what external AI agents are allowed to do with Box content, and agent-session audit trails rolling out to Enterprise Advanced customers. Prompt injection detection is generally available today in log mode, with alert and block modes targeted for later in 2026.

I want to walk through what these controls actually secure inside Box's platform, and where the boundary sits once content leaves Box for an LLM API that Box itself does not control.

TL;DR

• Box's Admin Console already logs more than 300 distinct actions through its Security Logs report, tracking who changed what setting and when.
• The July 2026 additions add prompt injection detection at the content layer and MCP guardrails that scope external agent permissions against Box content.
• Agent-session audit trails are rolling out to Enterprise Advanced customers, with contextual records of each agent's interaction with Box content.
• None of these controls evaluate an outbound HTTP request an integrated application makes from Box-stored data to an external LLM API; that call happens outside Box's own platform boundary.

What the Admin Console already tracked

Box's Security Logs report has long covered platform-level activity: which admin changed which setting, when, and from where, across more than 300 tracked actions. That gives a security team a reliable record of configuration changes and access-control activity inside Box itself. It is a platform administration log, built for the question "what changed in our Box tenant," not for the question "what did an AI agent do with a specific file on a specific user's behalf."

The July 2026 agent controls

The new capabilities extend Box's platform boundary to cover AI agents operating on Box content. Prompt injection detection validates input content before it reaches a model, checking for known injection patterns and letting admins log, alert on, or block matches once alert and block modes ship. MCP guardrails let admins scope what an external AI agent connecting through the Model Context Protocol is permitted to do with Box content, rather than granting a connected agent unscoped access to a user's files.

Agent-session audit trails add the contextual record: what an agent session touched, when, and under what permission grant, visible to admins investigating unusual activity, with threshold-based alerting for behavior that deviates from expected patterns. That is meaningful visibility into agent behavior inside Box's own platform boundary, for agents that connect to Box through Box's own integration surface.

Where the boundary ends

None of these controls follow a request past the point where an application pulls content out of Box and sends it to an LLM API. A common enterprise pattern looks like this: an internal application retrieves a document from Box using a service account, constructs a prompt containing that document's content, and calls OpenAI, Anthropic, or an internal model endpoint directly. Box's prompt injection detection covers content flowing through Box's own AI features and connected agents. It does not extend to that separate, direct HTTP call the application makes on its own, because that call never touches Box's platform at all.

This is the same shape as the DLP blind spot described in the shadow AI research: the data left a well-governed system (Box) and became an HTTP POST to a model provider's API, a data channel most existing controls, Box's included, were not built to inspect. The post-authentication gap applies here too. Box authenticates the service account pulling the document. It does not, and architecturally cannot, evaluate whether the specific end user behind that pull is permitted to send that document's contents to that particular LLM.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline on the HTTP path between an application and any LLM API it calls, evaluating the identity context the application supplies, the role behind it, and the data classification of the prompt, before the request reaches the model. When an application pulls a Box document and constructs a prompt around it, DeepInspect is the enforcement point that decides whether that specific request, from that specific authenticated user, should reach the model at all, and it produces a signed, tamper-evident audit record of that decision.

Box's own agent controls keep securing what happens to content and connected agents inside Box's platform boundary. DeepInspect covers the outbound leg once an application takes that content somewhere Box was never built to watch.

Book a demo today.