- Model / LLM providers
- Anthropic, OpenAI, and others are sub-processors, named in the engagement architecture doc.
- Provider settings for regulated work
- Provider data-retention and no-training settings are enabled for regulated workloads.
- Vector stores
- Partitioned per tenant, no cross-tenant retrieval surface.
- Observability / logs
- PII redacted at the logging layer before traces are written.
Security
Security we can show our work on.
How we secure engagements, and what we honestly hold versus what we follow but don't hold. We'd rather under-claim a certification than burn the trust we were hired for. Report a security issue to security@paiteq.com.
Last updated: · General: info@paiteq.com · Security: security@paiteq.com
001 / COMPLIANCE POSTURE
What we hold, and what we follow but don't hold.
The honest core of this page. We ship HIPAA-ready and GDPR-ready patterns, and we follow SOC-2-ready practices, but "ready" is not "certified". We are not ourselves SOC 2 Type II or ISO 27001 certified as a vendor; if your procurement requires a vendor SOC 2 report, flag it early and we'll route accordingly.
- HIPAA-READY Pattern shippedBAA + PrivateLink VPC
Claude on AWS Bedrock with a signed BAA and PrivateLink VPC, audit-logged, with field-level PHI masking before any model call. We've shipped this pattern for healthcare-adjacent workloads.
- GDPR-READY Pattern shippedEU residency + DPA
EU-region residency on hosted models (Anthropic EU, OpenAI EU data residency, Azure West Europe). DPA available, subject-access-request workflow documented in the ops runbook at handover.
- SOC-2-READY Practices, not certifiedPractices, not certified
We follow SOC-2-ready practices, audit logs, least-privilege IAM, key rotation, encryption in transit and at rest, but we are not ourselves SOC 2 Type II certified as a vendor.
002 / APPLICATION SECURITY
The build pipeline is the security boundary.
Security for an AI system is mostly upstream of the model: how code ships, how prompts get reviewed, where secrets live, and who can reach what. We treat the SDLC as the place to enforce it.
-
01 Eval gates on every deploy
No model change ships without passing the eval suite: task success, hallucination rate, and latency thresholds are gate conditions, not dashboards you check after the fact. A red eval blocks the deploy.
-
02 Secure SDLC, prompts are code
Prompts and eval sets live in your repo, reviewed in pull requests like any other code. Changes are versioned, peer-reviewed, and traceable. There is no out-of-band prompt console editing production behaviour.
-
03 Secrets management
Secrets live in your secrets manager (AWS Secrets Manager, GCP Secret Manager, Vault), not a Paiteq-controlled vault. Keys are rotated on a schedule and scoped per environment. We never commit credentials to the repo.
-
04 Dependency posture
Pinned dependencies, automated vulnerability scanning on the supply chain, and a boring-infrastructure default, the novelty budget is spent on the model layer, not the platform underneath it.
-
05 Least-privilege IAM
Every service identity gets the narrowest permission set that lets it do its job. Read-only by default during the audit phase; write access scoped per workload only when the pilot needs it.
003 / DATA HANDLING IN ENGAGEMENTS
Your data stays in your perimeter.
In most engagements Paiteq is the data processor and the client is the controller. We deploy into your boundary rather than pulling your data into ours, and your data is never used to train models.
- Encryption in transit and at rest
TLS for everything in transit; encryption at rest on every store that holds engagement data. No plaintext PHI/PII at rest, no unencrypted backups.
- Access control
Role-scoped access, audit-logged. Only the engineers on your build can reach your data, and every access is recorded.
- Data stays in your cloud
Where required, client data stays in the client's cloud account / VPC. We deploy into your perimeter rather than pulling your data into ours.
- On-prem / VPC deployment option
For self-hosted open-weight models we run vLLM inside your VPC or on-prem, so regulated data never leaves your boundary to reach a model.
- Client data is not used to train models
Plainly: your data is not used to train any model. For regulated work we use provider data-retention and no-training settings on every model call.
004 / SUB-PROCESSORS + MODEL POSTURE
Model providers are sub-processors. Named, settings-locked.
Model and LLM providers (Anthropic, OpenAI, and others) act as sub-processors. They are named in the engagement architecture doc, and for regulated work we run them under provider data-retention and no-training settings.
005 / VULNERABILITY DISCLOSURE
Found something? Tell us.
We welcome good-faith security research. If you believe you've found a vulnerability in a Paiteq property or an engagement we operate, report it and we'll acknowledge and triage.
REPORT TO security@paiteq.com
- Email security@paiteq.com with steps to reproduce. PGP available on request.
- Act in good faith: don't access or modify data that isn't yours, and don't degrade service for others.
- We acknowledge receipt and triage. We'll keep you updated through remediation and credit researchers who want it.
- We don't run a paid bounty programme, but we take reports seriously and respond.
006 / Procurement questions?
Talk to engineering.
Security and procurement gates are easier to clear when an engineer answers them. Flag vendor SOC 2 needs early and we'll route accordingly.