Zero Data Egress

Zero data egress describes Agent Mask’s runtime behavior: the text and documents you submit for masking are processed inside the deployment environment where Agent Mask runs.

That deployment can be:

the Agent Mask Snowflake Native App running inside your Snowflake account, or
the self-hosted Docker container running inside infrastructure you control.

In both cases, Agent Mask does not send input text, extracted document text, entity ledgers, model output, or masking payloads to Agent Mask servers.

Shared runtime behavior

All AI detection models, OCR engines, and supporting libraries are packaged into the application image and loaded from local disk. Nothing is downloaded at runtime.
Agent Mask only processes payloads you explicitly submit to the masking API or SQL function.
Agent Mask does not crawl your databases, object stores, ticketing systems, file systems, queues, or private applications.
Error responses are sanitized by default to avoid returning stack traces or raw exception messages.
Self-hosted license keys are verified offline inside the container. There is no activation server, phone-home, or runtime telemetry.

Snowflake Native App boundary

For Snowflake deployments, app_public.mask() runs inside the Snowflake Native App deployment boundary. Agent Mask does not route masking payloads to external services.

The network boundary is controlled by the Snowflake Native App deployment model and the application’s declared network access:

The Agent Mask container service does not require internet connectivity from the Snowflake compute pool.
External access endpoints for a Snowflake Native App must be declared in the application manifest. Agent Mask declares no external access endpoints for masking.
The app runs in Snowflake-managed compute pool isolation.
Snowflake platform controls govern encryption in transit and at rest for the surrounding Snowflake environment.

Use your normal Snowflake account controls for roles, grants, stages, query history, result retention, and downstream access to masked outputs.

Self-hosted container boundary

For self-hosted deployments, the container does not need outbound internet access at runtime for masking, model loading, or license verification.

Your deployment controls enforce the network boundary:

Expose port 8000 only to trusted callers, such as an internal load balancer, private subnet, service mesh, or localhost during evaluation.
Deny outbound internet by default when your environment requires a hard egress boundary. Masking, model loading, and license verification do not require external network calls.
Set API_KEY when the endpoint is reachable beyond a local developer machine.
Terminate TLS at your ingress, reverse proxy, service mesh, or load balancer.
Restrict /config, /license, and /metrics to trusted operators.

See Self-hosted security for the full container data flow, retention model, hardening checklist, and security review guidance.

Why this matters for PII/PHI workflows

Running PII detection on an external service typically means sensitive data leaves your security perimeter: it may be transmitted over the internet, processed on vendor infrastructure, and handled under that vendor’s logging, support, retention, and subprocessing practices. Many compliance programs review that path as a business associate, sub-processor, vendor-risk, or audit concern.

Agent Mask is designed for teams that want PII redaction and de-identification workflows without adding that external processing path. The enforcement mechanism differs by deployment: Snowflake deployment controls apply for the Native App path, while your own network and runtime controls apply for self-hosted. The product behavior is the same: no Agent Mask phone-home for masking payloads.

Deployment provenance

For Snowflake Marketplace deployments, application code, model weights, and library dependencies are packaged inside the application and installed through Snowflake’s Native App distribution path. Review the Marketplace listing, release notes, and your Snowflake account controls as part of your procurement and security review.

For self-hosted Docker deployments, Docker Hub is the distribution channel. Use a versioned tag, record the immutable image digest, and deploy that digest through your normal container approval process. If your security review requires an SBOM, vulnerability report, image signature, or provenance attestation, contact us with the image tag and digest you plan to run.