> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Actions: PASS / MASK / BLOCK

> Every Guardian decision in Starfort resolves to PASS, MASK, or BLOCK — what each action means and how the overall action is chosen (Starfort v1.4 docs)

Every time a Guardian evaluates content it returns an **action**. **PII** policies use `PASS` / `MASK` / `BLOCK`; **Topic** verdicts are 2-state — `PASS` or `BLOCK`.

<CardGroup cols={3}>
  <Card title="PASS" icon="check">
    No rule matched (or only `PASSING` rules did). Content continues onward — what's delivered is the processed content Guardian verified and rebuilt.
  </Card>

  <Card title="MASK" icon="eye-slash">
    *(PII only)* Sensitive spans are replaced with mask tokens. The Guardian returns the masked content.
  </Card>

  <Card title="BLOCK" icon="ban">
    A blocking rule or unsafe topic matched. The request is stopped and nothing is sent onward.
  </Card>
</CardGroup>

## The overall action is the highest severity

A response has a root `action` and a per-item breakdown. The root action is the **most severe** action across everything detected, combining PII and Topic results: `BLOCK` > `MASK` > `PASS`. So a single blocking match makes the whole request `BLOCK`, even if other parts would only be masked.

## What leaves is the processed content

Starting with v1.4, the content that actually goes out to an external AI service is never the caller's original — it's the **processed content** (`processed_content`): what Guardian rebuilt after parsing and normalizing the input (with OCR or decoding where needed) and actually verifying its contents. The original may hold content Guardian never got to see, so only the processed content leaves — closing the path where "what we didn't see" flows out untouched.

| Verdict   | Egress content                                                                                                                                                                       |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **PASS**  | The processed content — even when nothing needed masking and it reads the same as the original, what's delivered is Guardian's rebuilt version. The original never goes out directly |
| **MASK**  | The masked processed content (unchanged from before)                                                                                                                                 |
| **BLOCK** | Nothing — no egress happens at all                                                                                                                                                   |

This rule applies identically to all three callers (API, Desktop Agent, Proxy Server). The API response carries the processed content in each input's `processed_content` regardless of verdict — it isn't left empty on PASS. Inputs that **no processed content could be built from** — unsupported files, parse or decode failures — have nothing eligible to send, so nothing is delivered (`null`): an original Guardian couldn't verify never leaves.

## What it looks like (real responses)

**MASK** — PII matched and was replaced; `processed_content` holds the masked text. Mask tokens follow the format `[<MASK_WORD>_<n>]`, numbered per category (1-based, in document order, and **value-stable** — the same original value gets the same number, so two different names become `[PERSON_NAME_1]` and `[PERSON_NAME_2]`). The original behind each token is exposed as `matched_text`, which is what `unmaskOutput` uses to restore it:

```json theme={"dark"}
{
  "action": "MASK",
  "input_results": [{
    "index": 0, "type": "text", "action": "MASK",
    "processed_content": "My number is [PHONE_NUMBER_1] and my email is [EMAIL_1].",
    "results": [{
      "policy_name": "PII Masking Policy", "policy_type": "PII", "action": "MASK",
      "detected_items": [
        { "rule_type": "regex", "rule_name": "phone_number", "mask_word": "PHONE_NUMBER_1", "matched_text": "010-2543-2513" },
        { "rule_type": "regex", "rule_name": "email", "mask_word": "EMAIL_1", "matched_text": "jane@acme.co.kr" }
      ]
    }]
  }]
}
```

**BLOCK** — an unsafe Topic matched; `processed_content` is `null`:

```json theme={"dark"}
{
  "action": "BLOCK",
  "input_results": [{
    "index": 0, "type": "text", "action": "BLOCK", "processed_content": null,
    "results": [{
      "policy_name": "Topic Policy", "policy_type": "TOPIC", "action": "BLOCK",
      "detected_items": [{ "rule_id": "WPN", "rule_name": "Weapons", "action": "BLOCK", "confidence": 0.91 }]
    }]
  }]
}
```

<Note>
  For the full field reference (PII vs. Topic `detected_items`), see [Response format](/en/v1.4/api/response-format).
</Note>

## Where you see actions

* **API Developers** read `action` from the [Guard API response](/en/v1.4/api/response-format).
* **Account Admins** see every action as a trace in [Opticon monitoring](/en/v1.4/admin/monitoring-opticon), tagged `PASS` / `MASK` / `BLOCK`.
* **Desktop Agent users** experience MASK/BLOCK transparently as they use AI tools.