Enterprises adopting AI coding agents face a question that keeps CISOs up at night: how do you let an AI read your codebase without it reading your employees' Social Security numbers?

Most AI app builders don't have a good answer. The agent reads every file in the project — config, fixtures, seed data, migrations — and ships all of it to the LLM provider as context. If your project handles employee data, patient records, or financial information, that data just left your building.

We built SaaSClaw to solve this. Here's how we approach PII protection across the surfaces that matter.

The Problem: Where PII Leaks in AI App Builders

Before we talk about solutions, let's map the attack surface. In a typical AI coding agent, there are five places sensitive data can escape:

1. The Prompt

Users type requests that contain real data. "Build me a dashboard showing John Smith's salary ($85,000) and his SSN (123-45-6789)." That text goes straight to the LLM provider's API endpoint. Their servers process it, may log it, and in some cases, use it for model training.

2. File Reads

The agent reads project files to understand context. A Django app might have fixtures/employees.json with real test data. A Next.js project might have seed_data.ts with actual names, addresses, and salaries. The agent slurps these up and includes them in LLM context. This is the most common and least visible leak vector — users don't type the PII, but it's in their files.

3. Tool Results

When the agent runs shell commands, reads databases, or queries APIs, the results come back as tool output that gets added to the conversation history. Database queries returning employee records are especially dangerous — the full result set becomes LLM context.

4. LLM Provider Infrastructure

Even if you sanitize perfectly, you're still trusting the LLM provider's infrastructure. OpenAI had a data exposure bug in March 2023 that leaked 1.2% of users' conversations. Samsung banned ChatGPT after engineers pasted proprietary code. Every cloud LLM provider is a third-party risk surface.

5. Stored Conversations

Agent sessions store the full conversation history — user prompts, tool calls, file contents, LLM responses. If an attacker gains access to the session database, they get everything the agent ever saw.

Our Approach: Defense in Depth

We don't rely on a single mechanism. We layer protections so that if one layer fails, others catch it.

Layer 1: Content-Level PII Sanitization

The first line of defense runs on every message before it reaches any LLM. Our PII Guard scans all content — prompts, file contents, tool results — and redacts sensitive patterns.

What it detects:

  • Government IDs — SSNs, passport numbers, driver's licenses
  • Financial data — Credit card numbers, bank routing numbers, account numbers
  • Contact information — Phone numbers, email addresses, mailing addresses
  • Employment data — Salary/compensation figures (with context detection)
  • Personal identifiers — Dates of birth (with context detection)
  • Infrastructure secrets — Database connection strings, AWS access keys, IP addresses

How it works: Detected values are replaced with synthetic placeholders — {{SSN}}, {{SALARY}}, {{EMAIL}}, etc. The agent still sees the structure and can reason about the code. It just never sees the real values.

Context-aware detection: Some patterns require surrounding keywords to avoid false positives. A bare 9-digit number that could be a routing number isn't flagged — it needs to appear near "routing," "account," "salary," or similar context. In an HR app, this is critical — you want to catch real PII without redacting port numbers and product IDs.

It runs on every LLM round, not just the first prompt. When the agent reads a file containing employee data and includes it in the next LLM call, PII Guard sanitizes it before it goes out. This catches the most dangerous vector — file-based PII that users never explicitly type.

Layer 2: LLM Gateway Enforcement

Content sanitization is great, but it's a software layer. Software has bugs. Regexes miss edge cases. New PII formats emerge.

For projects that handle sensitive data, we offer LLM Gateway Mode — an infrastructure-level guarantee that data never leaves the server. When enabled:

  • All LLM requests are routed to a self-hosted endpoint (vLLM, Ollama, LM Studio)
  • Cloud providers (OpenAI, Anthropic, Z.ai, Google) are blocked at the application level
  • The agent runs against a model on your own hardware
  • PII Guard still runs as a safety net

This is the configuration for HR, payroll, healthcare, and financial applications. Even if PII Guard misses something, the data stays on your infrastructure because the LLM call never goes to a third party.

The gateway is per-project — not a global setting. Staff can enable it on individual projects based on data sensitivity. A marketing landing page runs on GPT-5. An employee benefits portal runs on your local LLM. Same platform, different risk profiles.

Layer 3: Access Control

PII protection isn't just a technical problem — it's a governance problem. We built access controls that match how enterprises actually manage data risk:

Staff-only security settings. The gateway requirement toggle is only visible to staff users. A developer can't disable it. This mirrors how enterprises manage data classification — the data owner sets the policy, the implementer follows it.

Project approval workflow. On enterprise instances, users can't create projects without staff approval. The submission form includes a data sensitivity field (None/Low/Medium/High) that gives reviewers immediate visibility into what kind of data the project will handle. When a submission is marked High (PII/PHI), staff can pre-configure gateway enforcement at approval time — the project is born with local LLM inference, no window where a user could build with a cloud provider first.

Traceability. Every project links back to its submission record. If someone asks "who approved this project to handle employee data and was gateway mode enabled?", the answer is one click away.

Layer 4: Audit Logging

Every PII redaction is logged — pattern type, count, source (which agent round, which message). Staff can query these logs to see exactly what was caught:

WARNING PII redacted 5 pattern(s) before LLM call in round 3
WARNING PII redacted 3 pattern(s) from PiBridge message

The actual sensitive values are never logged — only the types and counts. This gives you a compliance audit trail without creating another data exposure risk in your log files.

For enterprise compliance (SOC 2, HIPAA, GDPR), this audit trail demonstrates that PII controls are active and operating. It's evidence you can show to auditors.

Layer 5: Infrastructure Isolation

Beyond the LLM path, we isolate project data at the infrastructure level:

  • Each agent session runs in a sandboxed workspace directory
  • Projects are isolated via git worktrees — the agent can only see the files in its assigned worktree
  • No cross-project data access — an agent working on Project A cannot read Project B's files
  • Deployed applications run in isolated environments with their own nginx configs and ports

What This Means in Practice

Here's how these layers work together in a real scenario:

Scenario: An HR manager at a payroll company uses SaaSClaw to build an employee onboarding portal. The project will handle SSNs, addresses, salary information, and benefit enrollment data.

Step 1 — Submission: The HR manager submits a project request, marking data sensitivity as "High (PII/PHI)." The submission form captures the project scope and compliance requirements.

Step 2 — Review: Staff reviews the submission, sees the High sensitivity flag, checks the "Require LLM Gateway" box, and approves. The project is created with gateway enforcement already active.

Step 3 — Building: The HR manager describes what they want to build. "Create an onboarding flow with sections for personal info, tax documents, and benefits selection." The agent reads the project files (which may include sample data) and sends context to the LLM. PII Guard scans everything — if sample SSNs are in a fixture file, they're redacted before transmission. But since gateway mode is active, the LLM call goes to the company's own vLLM server anyway.

Step 4 — Deployment: The app is deployed to a preview environment with its own isolated nginx config. The production deployment goes through the same pipeline.

Step 5 — Auditing: Compliance reviews the PII redaction logs and sees that 12 SSN patterns and 4 salary figures were redacted across the build session. The project's submission record shows it was approved with gateway enforcement. The audit trail is complete.

Layer 6: Pi Extension (Full Agent Coverage)

The first five layers cover the engine's direct LLM calls and the infrastructure around them. But there's one more surface: the Pi subprocess itself.

Pi is our external agent process — it reads files, runs commands, and makes its own internal LLM calls. The engine's PII Guard sanitizes the user message before it reaches Pi, but once Pi is running, its internal operations — reading fixture files, querying databases, including file contents in LLM context — were previously invisible to PII Guard.

We closed this gap with a Pi extension. Pi supports a plugin system that can intercept lifecycle events. We built pii-guard.ts — a Pi extension that hooks into two events:

  • context event — Fires before every LLM call inside Pi. The extension scans all messages in the conversation (including tool results from file reads) and redacts PII patterns before they reach the LLM.
  • tool_result event — Fires when a tool call returns data. The extension sanitizes the output so that when the result is included in the next LLM call, PII is already redacted.

This means Pi's internal file reads are now covered. When the agent reads employees.json containing real SSNs and salaries, Pi's extension catches them before they become LLM context. The LLM sees {{SSN}} and {{SALARY}} — placeholders that preserve structure without exposing real data.

The extension uses the same patterns as the engine's PII Guard, so detection is consistent across all three LLM paths (Runner, PiBridge, and Pi internal). It also logs all redactions to an audit file at /var/log/saasclaw/pii-guard.log, maintaining the same audit trail standards.

Installation is a single file copy — place pii-guard.ts in ~/.pi/agent/extensions/ and Pi auto-discovers it globally. No configuration, no flags, no per-project setup. Once installed, every Pi session on the server has PII protection.

What We Don't Cover (Yet)

Transparency matters. Here's where our current protections have gaps:

  • Images and screenshots. PII Guard is text-only. A screenshot of a W-2 form or a photo of a driver's license would pass through undetected. We'll add image-based PII detection in a future update.

  • Deployed application runtime data. We protect the build process. Data that users enter into the apps you build — forms, databases, session storage — is the application's own responsibility. We encourage all SaaSClaw users to implement appropriate data handling in their apps.

  • Semantic PII. Regex patterns catch structured formats. They don't catch "my mother's maiden name is Williamson" or "I was born at Mercy Hospital in Chicago on March 15, 1982." Named entity recognition would help here, and it's on our roadmap.

The Bigger Picture

PII protection in AI coding agents isn't a feature — it's a category of risk that the industry is only starting to address. Most AI app builders treat it as a user responsibility: "don't put sensitive data in your prompts."

That's not good enough for enterprise. When an HR company builds a payroll tool, the codebase will contain PII. When a hospital builds a patient portal, the fixtures will contain medical records. The question isn't whether users will accidentally expose sensitive data — it's whether the platform catches it when they do.

We built SaaSClaw's PII protection because we need it ourselves. Our own company operates in the HR/payroll space. The same features we're describing here are the features we'll use to build our own products. If they're not good enough for us, they're not good enough for you.

The combination of content-level sanitization, infrastructure-level gateway enforcement, governance controls, audit logging, and full agent-internal PII coverage via Pi extension isn't perfect. But it's a real, layered defense that addresses the actual attack surfaces of AI-assisted development. And it's available today, not as a roadmap item, but as a working system you can deploy and audit.

If you're evaluating AI coding tools for enterprise use, ask them what happens when an agent reads a file containing SSNs. Ask them if you can require local LLM inference for sensitive projects. Ask them for the audit logs.

The answers matter more than the feature lists.