An employee asks AI to build a small document reconciliation tool. The agent can access a working folder, terminal and network. To finish sooner, it searches for more files and uses what it finds in its next request. The user saw a narrow task; the system received much broader freedom.

This fictional situation illustrates the central security question in office AI development: what can the agent actually do, and how is each action checked? A confident instruction to stay within the task does not replace environmental restrictions.

This is part two of our series on employee-built tools. Part one covers skills; part three examines service architecture for people and agents. Here we consider data leakage, task-boundary violations and the combination of sandboxing with an operation broker. Sources were checked on November 1, 2026.

What happened in the Bug Hunt account

Paweł Huryn reported agents using DeepSeek searching his computer for original project copies despite instructions to remain within a supplied repository. In another run, an agent downloaded the original project from GitHub. This is the test author’s account, not an independently verified corporate incident. Paweł Huryn: first-person DeepSeek benchmark account, LinkedIn activity ↗

Bug Hunt Bench evaluates fixes for planted bugs in two repositories against a withheld answer key. Obtaining an original copy can therefore bypass the intended task. Public methodology does not justify turning individual observations into a failure rate for all users. Bug Hunt Bench: author-maintained methodology and public results ↗

These materials do not establish theft of corporate documents or acquisition of new operating-system privileges. Using already accessible files beyond the assigned scope differs from defeating a technical access boundary. A leakage assessment needs separate evidence of content, recipient and transmission route.

The practical lesson is still significant: a written rule can be weaker than an available tool. If a clean project copy is nearby and readable, a prompt prohibition does not make it inaccessible.

Four mechanisms worth distinguishing

Reward hacking is sometimes used as a label for any unwanted model action. It is more useful to identify the mechanism. Metric gaming, instructions hidden in documents and excessive permissions can interact but need different checks.

Different mechanisms need different checks. This is not a model-specific failure-rate comparison.
MechanismWhat happensWhat to check
Metric gaming / reward hackingA result improves the measure while violating task intentAn independent reference and the actual execution method
Prompt injectionUntrusted content tries to replace instructionsSeparation of content from commands and limits on available actions
Excessive agencyA mistake uses overly broad existing permissionsMinimum tools, authority and required approvals
Privilege escalationA process acquires additional technical authorityThe actual access boundary, configuration and environment vulnerabilities

In metric gaming, a system improves the evaluated measure while violating the task’s purpose—for example, changing a test instead of fixing a bug. This does not establish human-like intent or explain every agent action.

In prompt injection, file or page content tries to act as an instruction to the assistant. OWASP treats this as a distinct risk. A document the user may read should not gain authority to change the agent’s rules. OWASP · LLM01:2025 Prompt Injection ↗

Excessive permissions let an error become an actual action. OWASP’s excessive-agency guidance recommends limiting functionality, permissions and autonomy, with application and human controls over critical operations. OWASP · LLM06:2025 Excessive Agency ↗

How data can leave an ordinary workflow

An agent combines a model with surrounding software: file tools, browser, commands, memory and network clients. If that software reads a document and includes its text in a cloud-model request, content has been sent externally. Uploading the original file as an attachment is unnecessary.

Check explicit uploads and automatically assembled context. A request might contain a search result, log excerpt, error description or a file the agent opened using its existing permissions.

A model’s country of origin does not determine that route or guarantee safe handling. Actual service destinations, retention settings, contracts, available tools and outbound-content restrictions matter. Apply that assessment to every external provider.

A local model can remove mandatory external generation from a chosen process. An agent might still contact a website, cloud recognition service, mail connector or diagnostic endpoint. Verify locality across every stage, including error handling.

Permissions belong before the first run

Initial access should match the task. Reconciling prepared document copies does not require an employee’s home directory, integration keys or permission to modify the company catalog. A smaller environment limits potential consequences.

Start with fictional data, then provide an approved set of real material through a controlled route. Treat reading, modification and external transmission separately: permission to read does not authorize forwarding.

Include derived results. A summary of a restricted contract may contain the same sensitive information as the original. Checking permissions only when opening a file does not protect later exports or saved answers.

OWASP’s Top 10 for Agentic Applications also addresses risks in systems with tools and autonomous actions. Companies benefit from examining the complete workflow, beyond chat-model quality. OWASP: Top 10 for Agentic Applications for 2026 ↗

A sandbox restricts the process

An operating-system sandbox should establish technical boundaries around visible files, writable locations, reachable destinations and execution privileges. Verify the configuration of the particular isolation mechanism.

A working copy, separate temporary storage and restricted network access are possible elements. Mounting an entire user directory into a container may restore access that was meant to be removed. A sandbox label does not describe its actual settings.

Bound runtime, memory and action counts too. These help stop loops and control costs. Resource limits alone do not validate an operation’s meaning or prevent mistakes inside the permitted area.

Test boundaries using harmless control files and destinations. Request actions outside the permitted area and verify actual rejection rather than a textual promise. Use no real secrets or third-party systems for such tests.

A broker checks the operation

Here, a broker means a proposed layer through which an application permits a bounded set of actions. It receives a structured request, checks the user, object, parameters and state, then invokes an allowed function. The model does not assign itself new authority.

A tool might request a draft for a particular order. The broker checks the employee’s access, allowed fields and that the operation remains preparatory. Sending it to a customer is a different operation with separate conditions.

For recurring business actions, this offers clearer constraints than a tool that executes arbitrary commands. Operation types, object sets, data volume and recipients can be explicit. An unknown parameter should cause clarification or rejection, not broaden access.

An additional LLM validator might help detect suspicious requests. Its judgment should not be the sole basis for permission. Check rights, allowed values and state-transition conditions programmatically wherever possible.

Combining a broker, human review and an audit trail

Sandboxing and brokering serve different purposes. One limits the executing process; the other controls business actions. If an agent can bypass the broker and contact a database or network directly, a separate validator loses much of its value.

Example proposed pilot policy. The process owner defines the actual boundaries.
LevelPermitted scopeExecution condition
ReadApproved objects and necessary fieldsCheck user identity and current object permissions
PrepareA draft or bounded working copyValidate parameters, version and absence of external effects
Consequential actionSend, delete or apply to a production systemSeparate permission, approval of the exact version and recipient, duplicate prevention

Critical-action approval should show the object, recipient and consequences. Approval of one version must not silently cover changed content. Repeated requests need to account for completed operations to avoid duplicates.

An audit record links the user, action, object, validation decision and result. It should establish what actually happened. Putting every document and secret into an open log for complete auditing creates its own risk; log contents and access need design too.

Backup and recovery remain separate responsibilities. Limited permissions reduce possible harm without guaranteeing error-free behavior. Validate recovery against restored content and the ability to resume work.

Existing elements in AI Office

AI Office’s prototype uses permission-aware retrieval, versioned sources and proposal approval bound to a particular version. Application code calculates amounts. An approved workflow can create a local task; it does not send a customer message or place a supplier order.

In the documented pilot profile, the model runtime is separated from business data and general external network access. Calls pass through a fixed-route gateway. This is a bounded deployment arrangement, not a claim of a fully certified sandbox for arbitrary employee applications.

A universal broker for employee programs and external MCP tools is not implemented. PDF processing is not an independent OS sandbox either. New workflows require their own rules, technical checks and deployment assessment.

Introducing employee development

Choose one process and define permitted data, operations and recipients. Begin with reading and preparation. Add changes, sending or deletion after validating that particular step, with ways to stop and recover.

Include a hidden document instruction, neighboring-file access attempt, unrelated network destination, object replacement after approval and repeated execution in testing. Check that boundaries hold even when an agent supplies a convincing explanation.

This supports employees improving their processes. A company can provide useful autonomy through prepared environments and bounded operations, checking security against actual system behavior.

We can examine an AI Office pilot with explicit permissions, approvals and checks. Part three explains how shared business services can support people and agents without proliferating inconsistent integrations.