1. Our approach
Security is part of Percipio's architecture, not a dashboard setting. We apply least-privilege access, minimize retained content, separate authentication from domain logic, and preserve an immutable history of accepted state transitions.
2. Architecture and tenant isolation
- Every API key belongs to one organization.
- End users are uniquely scoped within an organization.
- Repositories require organization context for user-state and event access.
- Canonical state, immutable versions, events, conversations, and snapshots maintain explicit ownership relationships in PostgreSQL.
- Deterministic merge logic—not the extraction model—owns IDs, revisions, timestamps, confidence updates, and accepted events.
3. Access and authentication
- Developer passwords are hashed with Argon2id.
- API keys, session tokens, verification tokens, and reset tokens are stored as hashes.
- API-key plaintext is displayed once and cannot be recovered by Percipio.
- Dashboard sessions use secure, HTTP-only, same-site cookies in production.
- State-changing dashboard requests require session-bound CSRF tokens.
- Email verification is required before API-key creation.
- API keys can be revoked from the developer console.
4. Data protection and minimization
- Production traffic is served over HTTPS.
- Secrets are supplied through the deployment environment, not committed to source.
- Request logs contain metadata such as route, status, latency, and request ID—not conversation, state, request, or response bodies.
- Raw conversation messages and extraction payloads are purged after 90 days by default.
- API request metadata is purged after 30 days by default.
- End-user export and deletion APIs are organization-scoped and produce metadata-only audit records.
- OpenAI extraction requests are configured with provider-side storage disabled.
5. AI processing controls
The model proposes typed candidate mutations; it cannot write state directly. Structured output is validated before deterministic merge logic applies confidence thresholds, deduplication, status transitions, and version creation.
- Only user-authored messages may establish facts.
- Assistant and system messages cannot independently become user state.
- Prompts prohibit unsupported inference, diagnosis, and protected-attribute extraction.
- Candidate evidence IDs are checked against submitted user-message IDs.
- Destructive state changes require a higher confidence threshold.
- Every successful transition creates an immutable state version, including no-ops.
6. Operational security
Percipio uses structured logs with secret and content redaction, database-backed readiness checks, automatic database migrations, bounded provider timeouts and retries, graceful process shutdown, a scheduled retention process, API rate limits, and metadata-only usage accounting.
We review reported vulnerabilities, investigate suspected incidents, contain confirmed exposure, preserve relevant evidence, and notify affected customers when required by law or contract.
7. Customer responsibilities
Customers are responsible for:
- Keeping API keys server-side and out of client applications and source control.
- Using unique idempotency keys and stable external user IDs.
- Restricting access to developer accounts and promptly revoking exposed credentials.
- Collecting and submitting only information they are authorized to process.
- Notifying Percipio promptly if they suspect unauthorized access or misuse.
8. Report a vulnerability
Send suspected vulnerabilities to security@percipio.tech. Include the affected endpoint, impact, reproduction steps, and any relevant request IDs. Do not include API keys, passwords, conversation content, or unrelated personal information.
Please avoid privacy violations, service disruption, social engineering, denial of service, automated high-volume testing, and access to data that is not yours. Stop testing and contact us if you encounter customer data.
9. Contact
Security reports: security@percipio.tech
Privacy requests: privacy@percipio.tech