Security

Security is part of the product, not a bolt-on. The guide only boots where you allow it, every request is authorized, sensitive values are tokenized before they reach the model, each workspace is isolated from every other, and connector credentials stay sealed. This page ties those layers together so you can position Puntego confidently with your own security team.

​

The trust model at a glance

​

Where the guide can run

Puntego refuses to boot on origins you have not verified, so the guide never appears on a site you do not control. You add each production hostname in Dashboard → Settings → Domains and prove ownership with a DNS TXT record. The runtime checks the request origin when it loads, so an unverified host simply does not mount the guide. A strict Content Security Policy is a first-class install path, not an exception. Provide a nonce on the boot script and the runtime propagates it to every follow-on script and injected style, so the guide fits cleanly inside a tight policy.

​

How requests are authorized

Authorization is scoped and short-lived by design. The boot handshake mints a visitor token with a roughly 15-minute lifetime, and every chat turn must present it as a bearer token. The worker enforces both visitor and workspace rate limits and returns a clear retry signal when a caller exceeds them, so a single visitor can never overwhelm a workspace. The boot endpoint and chat endpoint serve different roles, and their responses reflect that: boot answers an origin and workspace eligibility check, while chat answers an authorization check. See Authentication for how the visitor token is issued and used, and Rate limits for the per-visitor and per-workspace limits.

​

Sensitive data is tokenized before model calls

Before any text reaches the model or the guardrail checks, Puntego scans it and replaces well-defined sensitive values — email addresses, phone numbers, Luhn-valid credit card numbers, US dashed Social Security numbers, IBANs, and URLs with embedded credentials — with stable, content-addressed placeholder tokens. The model reasons about the same value across a turn without ever seeing the real data, and the original values never leave your app boundary. Telemetry is held to the same standard: personally identifiable information is scrubbed from events before they leave the app, so you get the observability you need to run the guide in production without capturing raw sensitive payloads.

​

Each workspace stands alone

Workspace isolation runs through the whole system. Telemetry, model traces, and analytics belong to a single workspace and are never visible to another. The dashboard renders only the redacted summaries the worker surfaces, so operator views never become a second copy of raw visitor data. One workspace’s configuration, traffic, and history stay that workspace’s own.

​

Connector credentials stay sealed

When you connect a system for Verified Actions, its credentials go straight into an encrypted credential vault. They are encrypted at rest, kept server-side, and never exposed to the browser, prompts, logs, or any model-visible context. When you review a connection in the dashboard, only the last four characters are ever shown back — enough to recognize the right credential, never enough to reconstruct it. Verified Actions add their own guardrails on top: every action starts disabled, reads that touch personal data require a visitor identity, and writes require visitor confirmation, idempotency, and audit logging.

​

Consent follows your configuration

You set the consent posture for your workspace from Dashboard → Privacy, and the guide applies it consistently for every visitor — always_opt_in, the default always_opt_out notice-plus-opt-out, or disclosure_only. A Global Privacy Control opt-out is always honored, independent of region, and consent is never silently overridden: a missing or undetected visitor country does not force a stricter mode than the one you chose.

​

Operational controls

You keep a direct hand on the runtime. A workspace-level killswitch makes boot return a service-unavailable response and the boot script silently no-op, so nothing renders on the page. When a production allowlist is configured, only the workspaces on it can boot and chat in production, giving you a deliberate, staged rollout. See Configuration for these controls and Boot errors for the responses they produce.

​

Next steps