Home/How masking stays on your machines
How masking stays on your machines
Last updated: September 7, 2026
Most “AI DLP” products ask you to send sensitive text to theircloud or vault so they can redact it. NoeticGuard's masking claim is different: raw prompts are never uploaded to us to mask. This page is the proof you can check in the product — for evaluators, not a SOC 2 report. How-tos: docs. Privacy practices: Privacy Policy.
NoeticGuard is a local-first DevSecOps toolkit: @noeticguard/core masks PII with deterministic tokens in your app, backend, CLI, or Chrome extension before text reaches LLM APIs. The NoeticGuard API syncs policy and quota — it does not receive raw prompts to mask.
What you can verify
The sensitive path stays in your runtime. Match these claims to the product:
- Masking is in-process — Detection and tokenization run inside
@noeticguard/corein your backend, CLI, or Browser Shield inject script — not on a NoeticGuard “mask this blob” service. - No cloud mask endpoint — There is no
POST /v1/mask(or equivalent) that accepts raw prompt bodies for redaction. - API is control plane only — Documented surfaces are
GET /v1/config(policy, Brand Guard terms, quota snapshot) andPOST /v1/telemetry(masked counts / usage). See API Gateway docs. - LLM calls stay between you and the model — ChatGPT, Claude, Gemini, and your APIs receive only what your app or browser sends after local masking. We are not in that hop.
The architecture is the product: plaintext never needs to sit on our servers to be masked. Start from SDK quickstart or homepage architecture.
Trust boundaries
- Your runtime — holds plaintext briefly, vault maps (e.g.
[EMAIL_1]), and LLM calls with masked text only. - NoeticGuard API (
api.noeticguard.com) — control plane only (config + telemetry), not a redaction proxy. - Dashboard (
app.noeticguard.com) — authenticated workspace UI (noindex). Auth and workspace data via our application backend and processors below. - LLM providers — receive only post-mask traffic from your stack; NoeticGuard does not sit in that path.
- Managed browser boundary — Zero Leak for Browser Shield assumes Chrome with the extension installed and active. Incognito and unmanaged personal browsers are a coverage gap unless closed with MDM (force-install, Incognito policy). See MDM & Incognito.
Delivery surfaces
- Browser Shield — on-device mask in employee ChatGPT/Claude/Gemini sessions; API for config + telemetry only.
- CLI scan — local repo measure; risk reports may store aggregate counts and redacted teasers, not raw vault values.
- SDK —
maskPii/unmaskPiiin your backend before LLM APIs.
Authentication & keys
- Publishable
ng_pub_…keys for Browser Shield and for backend config/telemetry. - Optional
ng_secret_…keys for trusted servers on Startup+ — never ship to browsers or mobile binaries. - Legacy
tn_*prefixes are rejected. - Revoking a key rotates credentials; workspace quota and audit history are not reset by revoke alone.
What we may process
- Account and workspace metadata (identity, plan, seats, policies).
- API key identifiers/prefixes (not a reason to embed secrets in clients).
- Telemetry aggregates: masked counts, kinds, platform labels you send — not raw prompt bodies for masking.
- Marketing waitlist email and support correspondence.
- Routine hosting/security logs (IP, user-agent) for abuse prevention.
Infrastructure processors (summary)
Depending on surface, we use processors solely to operate the product — for example application hosting, managed PostgreSQL/auth (Supabase), transactional email (Resend), and analytics when enabled. We do not sell personal information. Details and rights: Privacy Policy.
Compliance posture
NoeticGuard is designed so teams can map egress controls toward frameworks such as GDPR, CCPA, KVKK (TCKN detectors in core), HIPAA, or COPPA-oriented KidTech policies. We do not claim certification under those regimes — labels are orientation aids, not audits or attestations. Industry modules on the roadmap are policy packs — not audit attestations.
What's next on trust
SOC 2 Type II, a published pentest summary, and customer case studies are on the roadmap. Until then, evaluate us on this architecture, the docs, and what you can run in your own process.
Responsible disclosure
If you believe you have found a vulnerability in NoeticGuard (marketing site, dashboard, API, or extension), email [email protected]with a clear description and reproduction steps. Please avoid privacy-invasive testing against other customers' data. We do not currently run a public bug bounty.
Contact
Security and enterprise diligence: [email protected]. For integration how-tos, start at /docs or guides.
Canonical URL: https://noeticguard.com/security