Tool Schema Sensitive Data Field Marking Prompt

This prompt is designed for security engineers and AI platform developers who need to annotate tool schemas with data classification labels before those schemas are consumed by LLM agents. The core job is to systematically identify and mark fields that carry PII, credentials, tokens, regulated data, or other sensitive information in both input arguments and output responses. Without this annotation, agent systems risk logging secrets, leaking customer data into model context, or violating data handling policies during multi-step tool execution. Use this prompt when you are preparing tool contracts for production deployment and need a machine-readable sensitivity map that downstream safety systems can enforce.

The ideal user is someone who understands the tool's data model and the organization's data classification policy, but may not have the time to manually audit every field across dozens of evolving schemas. The prompt requires a complete tool schema as input, including argument definitions, output shapes, and any existing field descriptions. It also requires a data classification taxonomy or policy document that defines sensitivity levels such as PII, CREDENTIAL, TOKEN, PHI, PCI, INTERNAL, and PUBLIC. The output is a marked schema where each field receives a classification label, a confidence score, and a rationale grounded in the provided policy. This is not a one-shot security audit; it is a repeatable annotation step in a CI/CD pipeline for tool schemas.

Do not use this prompt as a substitute for a formal data protection impact assessment or legal review. It does not discover undocumented data flows, detect data exfiltration at runtime, or enforce encryption. It is a schema-level annotation tool that relies on the accuracy of the input schema and the completeness of the classification policy. If the schema omits fields or misrepresents types, the annotations will be incomplete. If the policy is vague, the model will make inconsistent classification decisions. Always pair this prompt with runtime enforcement: use the marked schema to configure redaction middleware, log scrubbing, and agent context filters. For high-risk regulated domains such as healthcare or finance, require human review of the marked schema before it gates production tool access.

This prompt template is designed to be dropped into a security review pipeline that processes tool schemas before they are registered with an agent. It takes a raw tool schema definition and a data handling policy as input, then produces a marked version of the schema with every field classified by sensitivity level. The prompt is structured to enforce consistent labeling across input arguments and output response shapes, which is critical when multiple teams contribute tools to a shared agent ecosystem and no single reviewer can manually audit every field.

textCopy
You are a data classification specialist reviewing a tool schema for sensitive data exposure. Your task is to annotate every field in the tool's input arguments and output response schema with a data classification label based on the provided data handling policy.

## INPUT
Tool Schema:
[TOOL_SCHEMA]

Data Handling Policy:
[DATA_HANDLING_POLICY]

## INSTRUCTIONS
1. Parse the tool schema to identify all input argument fields and all output response fields.
2. For each field, determine whether it contains, transmits, or stores any of the following sensitive data categories based on the policy:
   - PII (Personally Identifiable Information): names, email addresses, phone numbers, physical addresses, government IDs, IP addresses, device IDs.
   - Credentials: API keys, passwords, tokens, secrets, certificates, private keys.
   - Regulated Data: financial account numbers, health records, payment card data, biometric data, data subject to GDPR, HIPAA, PCI-DSS, or equivalent regulations.
   - Internal-Only: internal identifiers, configuration values, operational metadata not intended for external exposure.
   - Public: data explicitly classified as safe for external exposure.
3. For each field, produce an annotation object with:
   - "field_path": the dot-notation path to the field (e.g., "arguments.user.email" or "response.data.payment_token").
   - "classification": one of "PII", "CREDENTIAL", "REGULATED", "INTERNAL", "PUBLIC".
   - "rationale": a one-sentence explanation referencing the specific policy rule that applies.
   - "risk_level": one of "HIGH", "MEDIUM", "LOW" based on the potential impact of exposure.
   - "recommended_action": one of "REDACT", "MASK", "ENCRYPT", "REQUIRE_APPROVAL", "ALLOW".
4. If a field is nested within an object or array, annotate the specific leaf field, not just the parent.
5. If the schema contains fields whose sensitivity depends on runtime values, flag them with classification "CONDITIONAL" and explain the condition.
6. If the output schema echoes input fields, annotate both occurrences independently.

## OUTPUT FORMAT
Return a JSON object with this exact structure:
{
  "schema_identifier": "<tool name or endpoint from the input schema>",
  "classification_timestamp": "<ISO 8601 timestamp of when this classification was generated>",
  "policy_version": "<version identifier from the provided data handling policy>",
  "input_arguments_annotations": [
    {
      "field_path": "...",
      "classification": "...",
      "rationale": "...",
      "risk_level": "...",
      "recommended_action": "..."
    }
  ],
  "output_response_annotations": [
    {
      "field_path": "...",
      "classification": "...",
      "rationale": "...",
      "risk_level": "...",
      "recommended_action": "..."
    }
  ],
  "unclassified_fields": ["<list any field paths that could not be classified with available information>"],
  "compliance_gaps": ["<list any policy requirements that cannot be verified from the schema alone>"]
}

## CONSTRAINTS
- Do not invent fields that are not present in the provided schema.
- If the schema uses generic field names like "data" or "payload", do not assume sensitivity; flag them as "CONDITIONAL" and explain what runtime inspection would be required.
- If the data handling policy is incomplete or missing a category, note it in "compliance_gaps" rather than guessing.
- Do not output the original schema fields without annotation; every field must appear in one of the annotation arrays or in "unclassified_fields".

To adapt this template, replace [TOOL_SCHEMA] with the raw JSON or YAML schema definition of the tool you are reviewing. Replace [DATA_HANDLING_POLICY] with your organization's data classification policy document, which should define what constitutes PII, credentials, and regulated data in your context. If your policy is long, consider extracting only the classification taxonomy and rules into a condensed reference to keep the prompt within context limits. The output structure is designed to be machine-readable so you can pipe the annotations directly into a schema registry or approval workflow. For high-risk tools, always route the output to a human reviewer before registering the tool with an agent; the prompt identifies what needs attention but should not be the final arbiter of data handling decisions.

This prompt is designed to run as a pre-deployment gate in a CI/CD pipeline or as a scheduled audit job against a tool registry. The harness should fetch the raw tool schema from a source of truth (an API gateway spec, an MCP server manifest, or a versioned schema repository), inject it into the [TOOL_SCHEMA] placeholder along with the organization's [DATA_CLASSIFICATION_POLICY], and capture the annotated output for review. Because the output directly influences data handling and compliance posture, the harness must treat every run as a high-risk operation requiring explicit validation before the marked schema is accepted.

The implementation should wrap the LLM call in a validation-retry loop. After receiving the marked schema, a validator must parse the JSON output and check for structural integrity: every field in the original schema must appear in the marked output, no field should lose its original type definition, and every annotation must reference a valid classification label from the supplied policy. If the validator detects missing fields, malformed annotations, or classification labels not present in the policy document, the harness should retry the prompt once with the validation errors appended to the [CONSTRAINTS] block. After two consecutive failures, the harness must escalate to a human review queue rather than silently accepting a degraded output. Log every attempt, the raw LLM response, the validator output, and the final disposition for auditability.

For production deployment, use a model with strong JSON mode and low refusal rates on security analysis tasks. The prompt's output schema is strict, so enable structured output mode (e.g., response_format: { type: 'json_object' } on OpenAI or equivalent constrained generation on other providers). If the tool schema is large, consider chunking by endpoint or resource and running the prompt in parallel with a merge step that reconciles overlapping annotations. The merge step must flag conflicts where the same field receives different classifications across chunks and route those to human review. Never silently resolve classification conflicts in automation.

The harness should also enforce a human approval gate for any schema that contains fields marked as CREDENTIAL, TOKEN, PII, or any classification above a configurable risk threshold. The approval step should present a diff between the original and marked schemas, highlight high-risk annotations, and require sign-off from a security engineer before the marked schema is published to the agent's tool registry. This gate prevents misclassified fields from reaching production tool contracts where agents might mishandle sensitive data.

Finally, integrate the marked schema output into the agent's tool execution layer. The agent framework should read the classification annotations at runtime and enforce data handling rules: fields marked CREDENTIAL must never be logged or stored, PII fields must be redacted from observability traces, and REGULATED fields must trigger retention and access control checks. The prompt's output is not just documentation—it is a machine-readable policy contract that the agent runtime must enforce. Wire the marked schema into your tool proxy or middleware so that classification labels become active guardrails, not passive annotations.