Tool Input Deserialization Safety Prompt

This prompt is for security engineers and platform developers who are building the gateway between an AI agent and any tool that accepts serialized object payloads—such as Python pickles, YAML configs, or JSON with embedded type hints. The job-to-be-done is preventing deserialization attacks when an agent supplies or modifies a serialized payload before it reaches a tool's execution environment. You need this when your agent can construct arguments that will be deserialized by a downstream service, worker, or library, and you cannot trust the model to avoid dangerous type constructions on its own. The ideal user is someone who understands that prompt injection is not the only attack surface: a model coerced into producing a malicious serialized object can trigger remote code execution, denial-of-service, or data exfiltration at the deserialization layer, entirely outside the prompt's text boundary.

Do not use this prompt as a replacement for sandboxing, capability-based security, or hardened deserialization libraries at the infrastructure level. It is a defense-in-depth layer, not a primary security boundary. The prompt is appropriate when you control the pre-invocation validation pipeline and can insert a structured safety check between the model's output and the tool's deserializer. It is not appropriate when the agent directly writes files to disk, calls an unvalidated eval() equivalent, or operates in an environment where the deserialization target is outside your observability perimeter. You also should not rely on this prompt alone if the downstream tool uses a deserialization format that is inherently unsafe by design and cannot be made safe through structural checks—in those cases, the correct answer is replacing the format or wrapping the tool in a hardened sandbox, not prompting your way around it.

Before using this prompt, you must have defined a concrete allowlist of safe types, a maximum object depth, a maximum payload size, and a set of known-dangerous patterns for your specific deserialization format. The prompt template expects these as input variables. If you cannot enumerate what 'safe' means for your tool's serialization format, stop and define that contract first. Once you have that contract, this prompt becomes a reusable validation harness that you can wire into your agent's tool-calling middleware. The next section provides the copy-ready template, and the implementation harness section explains how to integrate it with retries, logging, and human escalation when the safety check rejects a payload.

This prompt template is designed to be placed directly in front of a deserialization step where an agent or upstream system provides a serialized payload. It instructs the model to act as a secure deserialization gate, producing a safe object graph while rejecting dangerous types, circular references, and resource-exhaustion attacks. The template uses square-bracket placeholders for all dynamic inputs, making it easy to integrate into a Python, Node.js, or Go application harness.

textCopy
You are a secure deserialization guard. Your only job is to safely deserialize the provided payload into a strict in-memory representation and report what you did.

## Input Payload
[PAYLOAD]

## Deserialization Format
[FORMAT]

## Allowed Types
[ALLOWED_TYPES]

## Constraints
- Maximum object depth: [MAX_DEPTH]
- Maximum total nodes: [MAX_NODES]
- Maximum string length: [MAX_STRING_LENGTH]
- Maximum array length: [MAX_ARRAY_LENGTH]
- Reject all non-whitelisted types immediately.
- Detect and reject circular references.
- Detect and reject exponential expansion attacks (e.g., billion laughs, zip bombs in encoded form).
- Do not execute, evaluate, or instantiate any code, classes, or constructors referenced in the payload.

## Output Schema
Return a strict JSON object with the following structure:
{
  "status": "success" | "rejected",
  "safe_object": <deserialized object graph, only if status is success>,
  "rejection_reason": "<detailed reason if status is rejected, otherwise null>",
  "warnings": ["<list of non-fatal concerns, e.g., depth near limit>"]
}

## Examples of Rejection
- Type not in allowed list: reject with reason "Disallowed type: [type_name]"
- Circular reference detected: reject with reason "Circular reference at path: [path]"
- Depth exceeds [MAX_DEPTH]: reject with reason "Max depth exceeded at path: [path]"
- Node count exceeds [MAX_NODES]: reject with reason "Max node count exceeded"

## Final Instruction
Process the payload exactly once. Do not retry on rejection. Do not attempt to fix or coerce the payload. If you are uncertain about safety, reject.

To adapt this template, replace each square-bracket placeholder with concrete values from your application context. [PAYLOAD] should be the raw serialized string. [FORMAT] should be the explicit format name (e.g., JSON, YAML, XML, Python pickle). [ALLOWED_TYPES] must be an exhaustive, minimal list of permitted types (e.g., str, int, float, bool, list, dict, None). Set numeric limits based on your application's memory and performance budget. If your system uses a custom deserialization library, mention its name and version in the [FORMAT] field to help the model reason about known vulnerabilities. Always run the model's output through a structural validator before trusting the safe_object field in your application code.

The Tool Input Deserialization Safety Prompt is not a standalone utility; it is a pre-invocation security gate that must sit between the agent's tool call and the actual deserialization library. In a production harness, you will typically deploy this prompt inside a thin API middleware or a sidecar that intercepts tool invocation requests. The agent emits a serialized payload (JSON, YAML, XML, or a custom format), and before that payload reaches json.loads(), pickle.loads(), or yaml.safe_load(), the prompt inspects the raw string and the intended target type. The prompt's job is to produce a structured safety verdict: a deserialized object for safe payloads, or a rejection block listing dangerous types, depth violations, circular references, and type-confusion indicators. This verdict must be machine-readable so the harness can act on it without human parsing.

Implement the harness as a deterministic wrapper around the LLM call. First, apply static pre-checks that do not require the model: reject payloads exceeding a maximum byte size (e.g., 1 MB), scan for known dangerous magic bytes if the format supports them, and enforce a maximum nesting depth via a fast streaming parser before the prompt ever runs. If the payload passes static checks, construct the prompt with the raw payload in [INPUT], the expected schema or type in [TARGET_TYPE], and a strict [OUTPUT_SCHEMA] that demands a JSON object with fields status ("safe" or "rejected"), deserialized (the safe object or null), and rejection_reasons (an array of strings). After the model responds, validate the output JSON strictly: confirm status is an allowed enum value, rejection_reasons is present when status is "rejected", and deserialized conforms to [TARGET_TYPE] when status is "safe". If the model output fails structural validation, retry once with the validation error injected into [CONSTRAINTS]. If it fails again, escalate to a human review queue and block the tool invocation. Log every verdict—safe or rejected—with the payload hash, model response, and harness decision for audit and regression testing.

For high-throughput systems, consider model choice and caching carefully. A fast, instruction-tuned model (e.g., GPT-4o-mini, Claude Haiku) is usually sufficient for deserialization safety checks because the task is pattern recognition, not deep reasoning. Cache verdicts by payload hash to avoid redundant LLM calls for repeated payloads. Instrument the harness with a circuit breaker: if the model returns malformed responses for more than 5% of requests in a rolling window, or if latency exceeds a threshold, fail closed and route all tool invocations to a manual approval queue. Never allow a deserialization operation to proceed when the safety harness is degraded. Finally, maintain a regression suite of known attack payloads—gadget chains, billion-laughs XML bombs, circular references, and type-confusion samples—and run them through the harness on every prompt or model change to catch regressions before they reach production.