PII Guard

Detect and mask personal data before it goes anywhere else.

PII Guard detects standard personally identifiable information in raw text and replaces it with generic placeholders — [SSN], [EMAIL], [PHONE] — so sensitive data is anonymized before further processing, storage, or transmission.

Use it at the boundary: after data arrives from an external system, and before it reaches somewhere you'd rather it didn't — a log, a less-trusted service, or a model.

How it works

• Input resolution — $input (the previous skill's output). $secret is available but not typically needed here.

• Processing — accepts raw text or JSON-stringified free-form content, identifies standard PII patterns, and returns the text with placeholders inserted:

Detected	Replaced with
Email address	[EMAIL]
SSN	[SSN]
Phone number	[PHONE]

• Execution — blocking. Completes before the workflow proceeds.

• Response — success returns maskedData with the redacted text; failure returns an error message and status code.

Worked example: masking PII from a database query

A workflow queries a customer record — through an API call or a database query — and gets back a text string containing a name, an SSN, and an email address. Before that string reaches a log file or an LLM for analysis, the PII should be gone.

The problem. Data retrieved from external systems arrives with sensitive fields you don't want exposed or stored unmasked further downstream.

The approach. Put a PII Guard immediately after the step that produces the text. It has one field to configure: Text to Scan for PII (input in the schema), which you point at the previous skill's output — $input.data.customerDetailsString.

Specifying the text input for PII Guard

In:

Hello, this is Michael. My SSN is 123-45-6789 and my email is [email protected]. Please call me at [phone] or [phone].

Out:

Hello, this is Michael. My SSN is [SSN] and my email is [EMAIL]. Please call me at [PHONE] or [PHONE].

PII Guard masks the standard patterns it knows — email, SSN, phone. It is not a general-purpose classifier: a customer name, an account number, or a bank-specific identifier passes through untouched. When you need domain-specific extraction, pair it with Entity Recognition and its custom regex rules.

Configuration reference

Field	Type	Required	Description
input	any	✅	Free-form text to scan and mask.
name	string	—	Name for this skill instance.
description	string	—	Description of what it's doing.

Output

The output port (piiMaskedResult) always conforms to:

Field	Type	Always	Description
maskedData	any	✅	The redacted input, PII replaced by placeholders.
error	string | null	—	Error message if processing failed; null on success.
statusCode	number	✅	200 success · 400 invalid input · 500 internal error.

Failure — invalid input:

{
  "maskedData": null,
  "error": "Invalid input: expected non-empty string.",
  "statusCode": 400
}

Errors

Message	Status	Cause
Invalid input	400	Null or undefined input.
Masking failed due to exception	500	Internal error during processing.

Security

• No $secret usage is required.

• Make sure your logging and debugging tools don't log the unmasked input. The skill masks in memory before passing data on — but that only protects what happens after it.

• Masking is in-memory. No unmasked data is persisted by the skill itself.

PII Guard's in-memory processing flow

Testing in isolation

• Path — /skill-runtime/workflows/nodes/PIIGuard/execute

• Method — POST

• Body:

{
  "config": { "input": "I am John. Email: [email protected]. SSN: 123-45-6789" },
  "input": {}
}

---

To add this skill to an agent, see Adding a Skill to the Agent. For platform-level PII handling, see PII Tokenization.