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

# Production Safety, Guardrails & Security Compliance

> A comprehensive guide on how HyperProbe protects your application performance and secures production data.

As a production-grade debugging system, HyperProbe is designed from the ground up under two absolute rules:

1. **Never crash or slow down the host application.**
2. **Never leak sensitive data outside the container boundary.**

This document provides our deep technical specifications on safety, guardrails, and secure data sanitization to share with your operations and InfoSec teams.

***

## 🛡️ Part 1: Automated Safety Guardrails

The SDK agent runs an asynchronous safety monitor on a separate thread/event loop cycle to track host system overhead in real-time.

### Agent Health States

The safety monitor maps the agent into three operational states:

* 🟢 **GREEN:** Normal operation. All indicators are healthy.
* 🟡 **YELLOW (Java Memory \< 15%):** Alert state. Captures are paced to reduce heap allocation speed.
* 🔴 **RED (Overhead Spike):** Cooldown shield. **All active probes are instantly uninstalled in-memory** for the duration of the cooldown period (default `10` seconds) before automatically attempting a clean resume.

### Configurable Safety Thresholds

You can configure these limits in code or via environment variables to match your environment's latency budget.

| Code Parameter      | Env Variable                  | Default | Description                                                                   |
| :------------------ | :---------------------------- | :------ | :---------------------------------------------------------------------------- |
| `hitsPerSec`        | `HYPERPROBE_HITS_SEC`         | `10`    | Maximum probe execution captures allowed per second globally.                 |
| `bandwidthKbPerSec` | `HYPERPROBE_BANDWIDTH_KB_SEC` | `200`   | Caps the outbound network payload rate to prevent broker floods.              |
| `maxLagMs`          | `HYPERPROBE_MAX_LAG_MS`       | `50`    | Maximum event-loop lag (Node.js) before triggering the RED cooldown shield.   |
| `pauseBudgetMs`     | `HYPERPROBE_PAUSE_BUDGET_MS`  | `20`    | Maximum total cumulative CPU execution budget per second allowed for hooks.   |
| `cooldownSec`       | `HYPERPROBE_COOLDOWN_SEC`     | `10`    | Duration (in seconds) the agent remains completely dormant after hitting RED. |

***

## 🔒 Part 2: Zero-Trust In-Process Data Redaction

Many debugging tools leak database credentials or user credentials because they capture memory dumps. HyperProbe prevents this using an **In-Process Sanitization Engine**.

**All variable filtering, structural serialization limits, and secret redactions occur inside your container's memory boundary.** Raw, unsanitized variables never reach network packets or leave your secure execution context.

### Default Redacted Keys

By default, any variable whose key matches any of the following patterns (case-insensitive) has its value replaced with `[REDACTED]` before serialization:

```text theme={null}
password, secret, token, authorization, cookie, key, signature, ssn, creditCard
```

### Customizing Redactions

Extend default keys or redact known literal values (like system-wide master tokens):

<Tabs>
  <Tab title="Code (Node.js)">
    ```typescript theme={null}
    HyperProbe.start({
      serviceId: '<service-uuid-from-dashboard>',
      environment: process.env.NODE_ENV, // Your environment name (e.g. dev, staging, production). Use whatever variable contains the env value.
      brokerUrl: 'https://logger.app.hyperprobe.co',
      redactKeys: ['password', 'secret', 'token', 'authorization', 'apiKey', 'cvv'],
      redactValues: [process.env.STRIPE_SECRET_KEY] // Redact actual API key values
    });
    ```
  </Tab>

  <Tab title="Environment Variables">
    ```bash theme={null}
    HYPERPROBE_REDACT_KEYS=password,secret,token,authorization,apiKey,cvv
    HYPERPROBE_REDACT_VALUES=sk_live_abc123,internal-token-xyz
    ```
  </Tab>
</Tabs>

***

## 📦 Part 3: Payload Structural Constraints

To guarantee that capturing a deep object (like an Express request wrapper or a heavy database row result) doesn't result in high memory pressure, HyperProbe strictly enforces hard structural limits on serialized payloads:

| Setting Parameter     | Env Variable                       | Default | What it controls                                                             |
| :-------------------- | :--------------------------------- | :------ | :--------------------------------------------------------------------------- |
| `maxObjectDepth`      | `HYPERPROBE_MAX_OBJECT_DEPTH`      | `3`     | Maximum nesting depth for object properties. Excess is marked `[truncated]`. |
| `maxArrayLength`      | `HYPERPROBE_MAX_ARRAY_LENGTH`      | `3`     | Maximum array elements captured. Excess is sliced.                           |
| `maxObjectProperties` | `HYPERPROBE_MAX_OBJECT_PROPERTIES` | `50`    | Maximum key-value pairs captured per object.                                 |
| `maxStringLength`     | `HYPERPROBE_MAX_STRING_LENGTH`     | `1024`  | Maximum character length captured from string properties.                    |
| `stackFrameDepth`     | `HYPERPROBE_STACK_FRAME_DEPTH`     | `3`     | Maximum call stack frames captured per snapshot.                             |

<Note>
  These limits apply structurally to each variable during heap traversal. The overall telemetry event size is dynamically throttled and capped by your configured in-process **Bandwidth Cap (`bandwidthKbPerSec`)** before transmission, protecting your network from spikes.
</Note>