> ## Documentation Index > Fetch the complete documentation index at: https://docs.puntego.com/llms.txt > Use this file to discover all available pages before exploring further. # Security > See how Puntego protects every request: verified domains, authorized sessions, PII redaction, workspace isolation, a sealed credential vault, and strict CSP. 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 The guide mounts only on hostnames you have added and verified for your workspace. Every chat turn carries a short-lived visitor token minted at boot. Sensitive values are tokenized before any model or guardrail call. Connector secrets live in an encrypted vault and are never shown in full. ## 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. Add and verify every hostname the guide is allowed to boot on. Run Puntego under a strict Content Security Policy with nonce propagation. ## 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](/authentication) for how the visitor token is issued and used, and [Rate limits](/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. See exactly what is redacted, how the round-trip works, and what is intentionally not auto-detected. ## 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](/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. Set the consent mode, voice, and rollout behavior for your workspace. ## 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](/configuration) for these controls and [Boot errors](/errors) for the responses they produce. Puntego serves the United States and Mexico. The controls above apply uniformly across both. ## Next steps Add and verify every hostname before you launch. Review tokenization, telemetry scrubbing, and consent enforcement. See how visitor tokens authorize each chat turn. Approve narrow, policy-checked tools with sealed credentials.