Building a PII-safe prompting program

Deploying LLMs to an enterprise workforce creates a data-handling challenge that most security teams haven’t had to address before. When your employees can type anything into a chat interface and have it sent to a third-party API, your data classification policies and your technical controls need to meet each other. A PII-safe prompting program is the structured approach to closing that gap.

What a program means versus a point control

A PII firewall is a technical control. A PII-safe prompting program is the combination of technical controls, policy, employee education, and audit feedback that makes the controls effective over time.

Technical controls alone fail in predictable ways: employees find workarounds, new use cases introduce new data types that the control wasn’t configured to catch, and the control drifts as model providers and data types evolve. A program creates the feedback loops that keep the controls calibrated.

Step 1: Inventory your sensitive data types

Before configuring any guardrail, document which data types your organization considers sensitive and how each should be handled when it appears in an AI prompt. The categories typically include:

• Regulated PII — Social Security Numbers, credit card numbers, health record identifiers. Policy: block. No exceptions.
• Quasi-identifiers — Full names combined with addresses or dates of birth. Policy: substitute with synthetic data.
• Internal business data — Customer account numbers, internal project codenames, unreleased financial figures. Policy: varies by context.
• Professional context — Employee names, organizational structure. Policy: may be acceptable for internal-only deployments routing to self-hosted models, but should be redacted for cloud providers.

Document the decision for each category and get sign-off from legal and compliance before configuring the Gateway. The configuration is the output of a policy decision, not the policy itself.

Step 2: Configure the PII firewall

ManyLayers Gateway’s guardrail pipeline runs on every request before forwarding to a provider. The PII firewall is one of the built-in guardrail types.

guardrails:
  pii_firewall:
    enabled: true
    patterns:
      - type: ssn
        action: block
      - type: credit_card
        action: block
      - type: health_record_id
        action: block
      - type: email
        action: redact
      - type: phone_number
        action: redact
      - type: full_name
        action: substitute
        confidence_threshold: 0.80
      - type: physical_address
        action: substitute
        confidence_threshold: 0.78
    response_scan:
      enabled: true
    audit:
      log_matched_spans: false
      log_policy_decisions: true
      log_team_id: true

The response_scan section enables a second guardrail pass on the model’s completion before it is returned to the client. This catches cases where the model echoes back or extrapolates sensitive data from the prompt.

Setting log_matched_spans: false is critical for compliance: you want to know that a guardrail triggered, but not store the actual sensitive data in your audit log.

Step 3: Configure allow-list exceptions

Production use cases often require named exceptions. A legal team automating contract review may need full names and addresses to flow through — for a self-hosted model only. A healthcare application may have an explicit BAA with a specific cloud provider and can allow clinical terminology under that agreement.

guardrails:
  pii_firewall:
    exceptions:
      - team: legal
        patterns: [full_name, physical_address]
        target_restriction: self-hosted/*
      - team: clinical-ops
        patterns: [health_record_id]
        target_restriction: openai/gpt-4o
        requires_tag: hipaa_compliant_workflow

Exceptions are team-scoped and can restrict which targets the excepted data can reach. An exception for legal that allows names and addresses applies only when the request is routed to a self-hosted target — if the routing strategy falls back to a cloud provider, the firewall re-engages.

Step 4: Build the education layer

Technical controls catch what employees inadvertently include. Education reduces the frequency of the problem at the source.

Run a 30-minute session for every new employee who will use AI tools. Cover: what counts as PII at your organization, what happens when the firewall blocks a request (the error message and how to proceed), and the feedback channel for reporting edge cases. ManyLayers Workspace displays a user-facing message when a guardrail blocks a request — configure this message in Platform Settings → Guardrails → User Messages so employees receive a helpful explanation rather than a raw HTTP error.

Step 5: Establish an audit review cadence

The audit log is your feedback loop. Review it monthly with these questions:

• Which teams generate the most guardrail triggers? High trigger rates may indicate a workflow that needs redesign or an exception that needs to be formalized.
• What pattern types trigger most frequently? Frequent triggers on full_name in a specific team may indicate a document-processing workflow where substitution is acceptable and blocking is causing unnecessary friction.
• Are there teams with zero guardrail triggers? This can indicate that employees have found workarounds (e.g., accessing providers directly) or that the team isn’t using AI tools at all. Both warrant investigation.

Export the audit log to your SIEM for longer-term retention and cross-system correlation. The structured JSON format is straightforward to ingest in Splunk, Elastic, or Datadog.

Step 6: Iterate on thresholds

NLP-based pattern detection (for unstructured PII like names and addresses) uses a confidence threshold. Too high: you miss sensitive data. Too low: you generate false positives that block legitimate prompts and erode trust in the tool.

Start with conservative thresholds (0.85+), review false positives in the audit log after the first month, and adjust downward if the false positive rate is acceptable for your risk tolerance. Document each threshold change and the rationale in your compliance records.

A PII-safe prompting program is not complete at launch — it is a practice. The organizations that get it right treat the audit log as a continuous feedback signal, iterate on configuration, and revisit education when use cases change. The Gateway makes the technical part operationally cheap; the discipline is in sustaining the review cadence.