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

# With the attack check

> Attacks and personal data in one call, failing closed, and the semantic pass.

## One request, both checks

`guard.protect` runs the attack check and detection in one request. On the control plane the semantic attack check and the detector run side by side, so the call takes as long as the slower one. The static signature pass runs first, in microseconds.

Turn the attack check off to run Cloak alone:

<CodeGroup>
  ```ts TypeScript theme={null}
  await fw.guard.protect(input, { attacks: false, cloak: { context } });
  ```

  ```python Python theme={null}
  fw.guard.protect(input, ProtectOptions(attacks=False, cloak=CloakOptions(context=context)))
  ```
</CodeGroup>

Or set what the attack check does when a payload trips it:

```ts theme={null}
await fw.guard.protect(input, {
  attacks: { onMatch: "sanitise" },
  cloak: { context },
});
```

## A blocked request is not scanned for personal data

When the signature pass has already blocked a payload and the request is going to be refused, there is nothing to protect it from, so detection is skipped. `cloak.error` says `skipped_blocked`.

That only happens when the request is being refused. If the action is `sanitise` or `allow`, the payload is still headed for the model, so detection always runs, whatever you set for `skipWhenBlocked`.

## Failing closed

If Cloak could not check a payload, the request is refused:

* `reason: "cloak_unavailable"`
* Severity `high`, and no signature ids

This is independent of `onScanError`. If the attack check failed open, nothing checked for personal data, so the request is still refused. A detector answer whose ranges do not fit your text counts as not answering.

To forward an unchecked payload anyway:

```ts theme={null}
{ cloak: { context, onUnavailable: "allow" } }
```

Do that only if availability matters more than keeping personal data out of the model.

## The semantic pass

The attack classifier treats personal data itself as unsafe. In our testing it refused most ordinary requests that merely contained personal data, such as *"Please send the invoice to [jane@example.com](mailto:jane@example.com)"*. If Cloak is about to remove that data, the refusal defeats the point.

Set `semanticPass` to control what the classifier may do while Cloak is on:

| Value | Behaviour |
| - | - |
| `enforce` | Default. The classifier can block. |
| `report` | The classifier runs, and its verdict is returned in `result.attack.modelCheck`, but it cannot block. |
| `off` | The classifier does not run. `modelCheck.error` is `disabled_by_request`. |

<CodeGroup>
  ```ts TypeScript theme={null}
  // per call
  await fw.guard.protect(input, { cloak: { context, semanticPass: "report" } });

  // for every call that uses Cloak
  new FrostWolfClient({ apiKey, guard: { cloak: { semanticPass: "report" } } });
  ```

  ```python Python theme={null}
  # per call
  fw.guard.protect(
      input,
      ProtectOptions(cloak=CloakOptions(context=context, semantic_pass="report")),
  )

  # for every call that uses Cloak
  FrostWolfClient(api_key=key, guard=GuardOptions(cloak=CloakConfig(semantic_pass="report")))
  ```
</CodeGroup>

The order of precedence is `attacks.semantic` on the call, then `cloak.semanticPass` on the call, then the client default, then `enforce`.

### What it does and does not touch

* It applies **only when Cloak is on for the call.** A plain `scan`, or a `protect` without `cloak`, is never loosened.
* It **never changes what a signature match does.** A literal attack blocks in every mode.
* It applies to `wrap` and `decorate` as well.

<Warning>
  This weakens the semantic check, and it weakens it most for a payload that also carries personal data. An attack with no literal signature that names an email address is no longer refused by the classifier. In a small internal sample, semantic-only attacks were refused 3 of 3 under `enforce` and 2 of 3 under `report` and `off`.

  Use `report` first. It keeps the classifier's verdict visible in telemetry, so you can measure what it would have refused before you rely on it.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.