> ## Documentation Index > Fetch the complete documentation index at: https://evalgate.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Security, data ownership, and privacy > How EvalGate handles customer evaluation data, provider credentials, and operational processing. # Security, data ownership, and privacy This page describes EvalGate's intended customer-data boundary and the controls that must be confirmed for a particular deployment and contract. It is product documentation, not a Data Processing Agreement or legal advice. Contact your EvalGate representative for the current DPA, subprocessor list, and hosting region schedule. ## Customer data remains yours Your organization retains ownership of the data you submit to EvalGate and the artifacts produced from it, including prompts, traces, spans, tool arguments, model outputs, test cases, datasets, evaluation results, reports, exports, and repository-derived material (collectively, **Customer Data**). EvalGate receives a limited, non-exclusive right to host, process, transmit, and display Customer Data only as necessary to provide, secure, maintain, and support the service you configure or otherwise instruct EvalGate to provide. EvalGate does not sell Customer Data, license it to other customers, or use it to train general-purpose models. Customer Data is scoped to the organization that owns it through EvalGate's organization-level authorization controls. You remain responsible for ensuring that your inputs are lawful to process and that your users have the required rights. ## Processing boundary EvalGate processes Customer Data to authenticate requests, run deterministic or model-backed evaluations, retain governed evidence, generate reports, enforce budgets and policies, and provide support requested by your organization. Operational metadata may be processed for security, billing, reliability, abuse prevention, and generalized service improvement when it does not contain Customer Data. Raw prompts, traces, outputs, and tool arguments must not be sent to product analytics or error-reporting systems; verify the configured telemetry policy before enabling an external collector. Operational identifiers are pseudonymized with a keyed HMAC when sent to telemetry or error-reporting sinks. Configure `EVALGATE_TELEMETRY_PSEUDONYMIZATION_KEY` in production to keep pseudonyms stable across restarts; without it, identifiers are intentionally not recoverable or correlatable across processes. Organization-scoped authorization, API-key scopes, audit evidence, and provider egress policy are part of the platform contract. Customers should still test tenant isolation and export/deletion behavior as part of their release review. ## Retention, deletion, and legal hold Retention is deployment- and organization-policy dependent. Configure explicit retention for traces, evaluations, datasets, reports, logs, queue payloads, backups, and temporary files; do not assume that an unspecified value means immediate deletion. Legal holds and governed evidence can preserve records until the hold is released. WORM or immutable backup copies can also outlive an application deletion request according to the applicable retention policy. Before making a deletion or residency commitment, review the deployed organization retention policy, export the required evidence, and confirm backup expiry and restore behavior with the deployment operator. ## Provider and BYOK disclosures EvalGate uses a bring-your-own-key model for model-backed workflows. Provider credentials are encrypted at rest and are not returned in plaintext after creation. When a model-backed workflow runs, the required prompt, output context, and request metadata are sent to the provider or gateway selected by your organization. Provider retention, training, residency, subprocessors, and zero-data-retention terms are controlled by that provider and are not overridden by EvalGate. A BYOK credential is not an EvalGate API key. Review the provider's current terms, region, model policy, and retention setting before sending sensitive data; use deterministic or internally hosted execution when provider egress is not acceptable. See [Model providers and BYOK](/docs/platform/model-providers-byok). ## Sharing and exports Treat reports, exports, and share links as potentially sensitive: they may contain evaluation inputs, outputs, traces, tool arguments, and scoring evidence. Organization administrators should keep public sharing disabled unless it is explicitly required, use expiration and revocation where available, and audit every external recipient. Prefer authenticated, organization-scoped access for customer artifacts. New organizations persist public sharing as disabled. An administrator can opt in from Organization Settings. The policy governs evaluation shares, signed reports, report cards, and customer-authored public benchmarks. Turning it off rejects new publication and blocks anonymous reads of existing links; clients receive the stable `PUBLIC_SHARING_DISABLED` code when publication is denied. Authenticated dashboard-share tokens remain organization-scoped and are not anonymous public links. ## Security launch checklist Before onboarding production Customer Data, the operator should verify: * organization isolation for API, web, background-job, cache, export, and MCP paths; * retention, deletion, export, legal-hold, and backup-expiry behavior against the deployed database; * redaction and provider-egress policy before enabling model-backed workflows; * public sharing defaults, expiration, revocation, and audit events; * provider credentials, model regions, and upstream retention/training terms; * the current DPA, subprocessor list, hosting/backup regions, and incident response contacts. The DPA, subprocessor schedule, and region commitments require legal and infrastructure review before publication. Do not infer those commitments from this page or from a development deployment.