DeepSeek V4 Pro Agent Safety Depends on the Harness, Not Just the Model

Organizations deploying DeepSeek V4 Pro agents should assess a complete model–harness–task–environment configuration, not the model in isolation. Availability through multiple interfaces may establish that a runtime can communicate with the model, but it does not prove that prompts, tools, permissions, memory, retries, or side effects behave equivalently across those runtimes.

The operational rule is simple: approve a specific pinned configuration only after that configuration passes its own safety evaluation.

Why the harness changes the effective agent

An agent is more than its underlying model. The harness determines how the model receives instructions, selects tools, accesses data, handles failures, and affects external systems. Material differences can include:

• system prompts and adapters;
• tool definitions and implementations;
• permission scopes and approval gates;
• filesystem roots and network access;
• credential sources and identity;
• subprocess and generated-code behavior;
• retry, timeout, and concurrency logic;
• session state, summaries, caches, and persistent memory.

Consequently, the same DeepSeek V4 Pro backend can present a different risk profile when routed through different harnesses or execution environments. A compatible API schema is an integration property—not a safety certification.

What the AgentS4D results show—and what they do not

AgentS4D evaluated complete runtime configurations rather than isolated model responses. Its benchmark used 328 risk-injected cases across four agent harnesses and five model backends, producing 6,560 sandboxed runs. It reported 4,461 unsafe runs, or 68.0%, and 4,344 runs, or 66.22%, that were both unsafe and judged complete. 13

The key finding is that successful completion can coexist with unsafe execution. An agent may produce the requested artifact while also making a forbidden change, mishandling sensitive data, bypassing an intended control, or creating another unsafe side effect.

These figures should not be presented as DeepSeek V4 Pro’s production incident rate. The evaluation used deliberately risk-injected cases in a controlled sandbox and aggregated results across multiple model–harness combinations. Production task mixes, controls, exposure to adversarial content, assets, and definitions of harm will differ. The benchmark is evidence that runtime safety must be measured directly—not a forecast of what every deployment will experience. 135

Limit the maximum consequence of an agent action

Safety controls should make mistakes less consequential even when the model or a tool behaves unexpectedly.

Use dedicated, least-privilege identities

Create separate identities for agents, environments, and tenants. Avoid ambient employee credentials, production-admin access, and broadly reusable secrets. Scope every identity to the resources and operations required for one job.

Restrict filesystems and networks

• Mount only a dedicated workspace root.
• Make unrelated paths inaccessible rather than merely hidden.
• Allowlist network destinations, methods, ports, and—where relevant—egress volume.
• Separate read, draft, staging-write, and production-write capabilities.
• Keep secrets in a broker or short-lived token system.
• Never place long-lived credentials in prompts, workspace files, environment variables, or tool output.

High-impact actions—such as deletion, publishing, payments, access changes, deployments, or external communication—should pass through an execution-layer policy check or require an explicit approval.

Review the full execution chain

First-party tools are only one part of the attack surface. Child processes, shell commands, generated code, package installation, remote tool servers, plugins, and skill code may all create side effects.

The same policy must apply to these paths. In particular, prevent shell or generated-code execution from bypassing filesystem, network, authorization, logging, or approval controls.

Make tools enforceable outside the model

A model-generated tool call is an untrusted request. The tool server—not the model—must enforce authorization and safety rules.

Use narrow schemas with controls such as:

• bounded enum values and length limits;
• normalized paths and explicit resource identifiers;
• destination allowlists;
• pagination and result-size caps;
• argument validation outside the model;
• server-side authorization for the specific caller, tenant, target, and operation.

Separate planning or preview tools from effectful tools. For destructive or difficult-to-reverse operations:

• require a preview and confirmation or approval token;
• prefer soft-delete, quarantine, or reversible workflows;
• require idempotency keys;
• define what happens when the same request is retried;
• return durable receipts so retries do not repeat an effect.

These controls matter because a valid-looking JSON tool call can still contain an unauthorized target, a dangerous path, an excessive scope, or an operation that should require human review.

Define state and memory behavior before deployment

State can carry risk across turns, tasks, users, and environments. Organizations should document and enforce lifecycle rules for messages, uploaded files, workspace files, summaries, tool results, caches, and persistent memory.

At minimum, specify:

• Isolation: separate state by user, tenant, task, and environment; do not allow implicit cross-session sharing.
• Retention: define time-to-live, encryption, access-control, and deletion rules.
• Reset: provide a documented way to clear context, memory, workspace state, credentials, and caches between runs.
• Retries and timeouts: impose bounded counts and budgets; retries must preserve idempotency and must not silently expand privileges.
• Concurrency: define locking and conflict handling for shared files, approvals, and external operations.

Treat state-reset behavior as part of the security boundary. If old instructions, credentials, or tool results can unexpectedly reappear in a new task, a model upgrade or prompt change may alter risk in ways that response-only testing will miss.

Treat every risk carrier as untrusted input

Prompt injection does not need to arrive in a user’s direct message. Risk-bearing instructions can be embedded in:

• uploaded documents and repository files;
• retrieved webpages;
• external skills and plugins;
• tool-service responses;
• persisted memory;
• summaries and cached context;
• user-provided text.

Parse, label, and quote this material as data. It should not be allowed to change the agent’s authority, policy, tool selection, credential use, or approval requirements. The runtime should enforce that separation rather than relying solely on the model to recognize malicious instructions.

A harness-specific release checklist

Before approving a deployment, freeze and record the exact configuration:

1. Model and routing: model identifier and version, provider route, inference settings or effort level, and compatibility adapters.
2. Harness behavior: harness version, system prompt, session logic, retry and timeout rules, subprocess policy, and memory implementation.
3. Tools and policies: tool definitions and versions, policy versions, approval thresholds, authorization logic, and tool-server trust boundaries.
4. Permissions: identities, scopes, filesystem roots, network destinations, credential sources, and production-write paths.
5. State semantics: isolation, retention, reset, cache behavior, concurrency, and cross-session boundaries.
6. Adversarial coverage: prompt injection through every risk carrier, confused-deputy attempts, credential exposure, path traversal, SSRF or egress abuse, malicious tool responses, retry duplication, memory poisoning, and approval bypasses.
7. Evidence: prompts and policy versions, tool calls and results, approvals, policy decisions, workspace diffs, outbound requests, identity used, final artifacts, completion outcome, and safety outcome under a stable run ID.

Score completion and safety separately. A correct final artifact should not compensate for an unsafe side effect—the central lesson of the AgentS4D results. 12

Rerun tests whenever the configuration changes

The approved test target is the pinned configuration, not a permanent label such as “DeepSeek V4 Pro agent.” Rerun the configuration-specific suite after any material change to:

• the model or provider route;
• inference settings or effort level;
• the system prompt or adapter;
• harness or session logic;
• tools or remote tool servers;
• permission and approval policies;
• credential routing;
• memory, retry, timeout, or concurrency behavior;
• network or filesystem boundaries.

This approach turns runtime safety from a broad assumption about model quality into a measurable release decision tied to the exact environment that can create real-world effects.