Last updated: August 11, 2026

Trust & Security

SOC 2 Type II — In Progress

This page is Parse's whole security posture: architecture, controls, sub-processors, retention, and a pre-answered vendor questionnaire. It states the gaps as plainly as the controls — there is no SOC 2 report yet (in progress, Q1 2027), no independent penetration test yet (first test scheduled for Q2 2027, after SOC 2 fieldwork), and Parse runs on a single node with no failover. Everything here is written to be checked rather than believed. Detection reduces risk; it does not replace least-privilege tools or output validation.

Who you are contracting with

The first thing a third-party risk assessment needs, and the thing most vendor pages leave to an email thread.

Contracting party	Kurultai Labs LLC, a North Carolina limited liability company, trading as Parse.
State of formation	North Carolina, United States
Registration	Registered with the North Carolina Secretary of State. The entity ID is supplied with the registered name on request — ask if your vendor register needs it, and say which fields you have to fill.
LEI	None issued. If your register of ICT providers requires an LEI, raise it before contracting — the operating entity is a registered company and can obtain one, which an unincorporated operator could not.
Governing law	the State of North Carolina, United States

Two entities named "Parse" hold active records in the public LEI index and neither is this one. If you are completing a register of ICT providers or a sub-processor questionnaire, use the row above rather than a name match, and contact [email protected] if you need it confirmed in writing.

Need this for your vendor risk assessment?

The full trust package is available as a downloadable document. You can also download the Markdown source.

Our Data Processing Agreement (DPA) covers GDPR Article 28, SCCs, sub-processor adequacy, and breach notification. Processing location: prompt text is processed on US-hosted infrastructure (no EU/UK residency yet); EEA/UK transfers are governed by the SCCs and can be narrowed with mode: "pattern-only" — see the DPA's transfer sections for the full answer.

Security contact also published at /.well-known/security.txt (RFC 9116).

Programmatic security posture: GET /v1/security/headers

Contact Security

1. Architecture Overview

Three-Layer Screening Pipeline

Parse uses a defense-in-depth screening pipeline. Each layer can block or flag independently — no single bypass defeats all three.

┌──────────────────┐ ┌───────────────────────┐ ┌─────────────────────┐ │ Layer 1: Regex │────▶│ Layer 2: LLM │────▶│ Layer 3: Sandbox │ │ Pattern Match │ │ Semantic Analysis │ │ Execution │ │ 108 patterns, │ │ (nonce-tagged │ │ (isolated eval, │ │ 9 categories,│ │ delimiters, multi- │ │ SSRF-guarded URL │ │ normalization) │ │ window sampling) │ │ prefetch, DOM │ └──────────────────┘ └───────────────────────┘ └─────────────────────┘

Layer 1 — Pattern Matching

108 compiled regex patterns across 9 risk categories. Includes text normalization to catch encoded/obfuscated payloads (Unicode, hex, base64, homoglyphs).

Layer 2 — LLM Semantic Analysis

Multi-model semantic risk scoring via OpenRouter. Uses nonce-tagged delimiters to prevent prompt reflection, multi-window sampling for long inputs, and model diversity to reduce blind spots.

Layer 3 — Sandbox Execution

Optional isolated execution for suspicious prompts. HMAC-authenticated communication, SSRF-guarded URL prefetch, and DOM-aware hidden content extraction. Disabled by default; enabled per-tier.

Data Storage: What Parse Stores, Per Endpoint

Storage does not vary by plan. Free, Pro, Team, and Compliance keys are handled identically — the tier changes rate limits, cost caps, and which fields come back in the response, not what Parse writes down.

Endpoint	Is your prompt text stored?	What Parse records
`POST /v1/parse`, `POST /v1/screen-output`, `POST /v1/agent/trust/verify`	No. The screening event table has no column for prompt or output text, and none for a hash of it.	Risk score, verdict, categories, screening mode, latency, blocked flag, enforcement mode, request ID, matched rule IDs, the metadata labels you send (`source_kind`, `trust_level`, `intended_action`), API key ID, timestamp.
`POST /v1/evaluate`	Yes, while the run is in flight. When the evaluation ends, successfully or not, Parse overwrites its copy with the first 100 characters of your prompt plus a SHA-256 of the whole prompt. Those first 100 characters stay readable.	Evaluation results, model name, token counts, cost, and the redacted prompt described to the left.
Audit log (written by every screened call)	No. The prompt's length is recorded as a number; the text is not.	Action, API key ID, risk score, verdict, prompt length, categories, rule IDs, request ID, and the caller's IP address.
Compliance receipts	No.	Verdict, risk score, matched rule IDs, agent ID, policy version, and the receipt hash chain.
API keys	Not applicable	A bcrypt hash plus a lookup prefix. The full key is never written down; it is shown once at generation.

Retention

Record	Stated retention	How it is enforced today
Screening events	90 days	Automatic. A daily job deletes records past the window.
Audit events, including the caller IP	90 days	Automatic, as above.
Compliance receipts	1 year, fixed so the hash chain stays verifiable	Automatic, as above.
Redacted `/v1/evaluate` records	The 500 most recent, then dropped	Automatic. They are held in the server's memory, so a restart clears them.
Rate-limit counters in Redis	The length of the rate-limit window	Automatic, via Redis key expiry.
API keys	Until revoked, or the expiry set when the key was made (90 days by default for self-service keys)	Automatic on expiry.

Enforcement is automated. A daily purge job deletes screening events, audit events, and compliance receipts past their stated windows. To request early removal, email [email protected] — we complete deletion requests within 30 days.

Where Prompt Text Goes

Screening runs on Parse's own infrastructure. Prompt text leaves it in three cases, all of them listed here.

Recipient	When it receives your prompt	How to prevent it
OpenRouter — routes the semantic analysis layer to a model provider	On `POST /v1/parse` and `POST /v1/screen-output`, the text is sent for scoring. Parse skips the call when you pass `mode: "pattern-only"`, when a pattern already matched at severity 9 or above and settles the verdict, or when the deployment has no OpenRouter key configured.	Pass `"mode": "pattern-only"` on the request.
OpenRouter — runs the prompt against a model	Only when you pass `execute: true`, which asks Parse to run the prompt on purpose and screen what comes back.	Omit `execute`. It is off by default. `mode: "pattern-only"` does not turn it off.
The execution sandbox — an isolated runner, configured per deployment	Only on the same `execute: true` path, which sends the prompt and any `test_input`.	Omit `execute`.
Stripe	Never. Stripe sees subscription and payment metadata. Card details go to Stripe directly and Parse never holds them.	—

What OpenRouter and the model providers behind it do with text they receive is governed by their policies, not ours. If that matters to you, use pattern-only mode and the text never reaches them.

POST /v1/parse
{
  "prompt": "...",
  "mode": "pattern-only"
}

Pattern-only screening stays entirely on Parse infrastructure, and it is a real trade: pattern matching alone under-reports paraphrased and indirect attacks that the semantic layer catches. Parse does not hide the trade — every response reports which layers ran, and a pattern-only response carries layers.llm: "skipped_pattern_only".

How to prove the restriction engaged

The control above is not something you have to take on trust. Every screening response reports which analysis layers actually ran, so a caller can show — per request, after the fact — whether prompt text was forwarded for semantic analysis or never left Parse. Send the same prompt twice:

curl -sX POST https://www.parsethis.ai/v1/parse \
  -H "Authorization: Bearer $PARSE_KEY" -H 'content-type: application/json' \
  -d '{"prompt":"...","mode":"pattern-only"}'
# -> "analysis_method": "pattern_only"
#    "layers": {"pattern":"ran","llm":"skipped_pattern_only"}   <- no model saw it

curl -sX POST https://www.parsethis.ai/v1/parse \
  -H "Authorization: Bearer $PARSE_KEY" -H 'content-type: application/json' \
  -d '{"prompt":"..."}'
# -> "analysis_method": "pattern+llm"
#    "layers": {"pattern":"ran","llm":"ran"}                    <- forwarded

layers.llm is the field to keep. If your transfer assessment relies on prompt text not reaching a model provider, this is the per-request evidence that the restriction held, generated by the same call it describes — not a vendor assertion you have to re-confirm at renewal. Organizations that set defaultMode: "pattern-only" get it on every response without callers having to remember the flag.

2. Security Controls Summary

🔒 Rate Limiting

Redis sliding-window (atomic Lua) with in-memory fallback
Tier-based: Free 10/min → Enterprise 500/min
API keys SHA-256 hashed before use as rate-limit keys
HTTP 429 + Retry-After on breach

👥 RBAC

Roles: org_admin, security_analyst, auditor, developer
Route-level middleware enforcement
Organization-scoped keys; cross-org denied
Configurable per-org policy packs

🔑 SSO

OAuth 2.0 / OpenID Connect
Okta, Microsoft Entra ID, Google Workspace, WorkOS
Available on Team + Compliance tiers

🔐 Encryption

Secrets: AES-256-GCM (API keys: bcrypt at rest; SHA-256 for the request-validation cache)
Transit: TLS 1.2+ (TLS 1.3 negotiated by default), HSTS enforced
Database: TLS connection in production
Redis: TLS connection in production

📋 Audit Logging

Events: auth_failure, rate_limit_exceeded, policy_change, prompt_screened, bypass_codeword
Storage: Postgres + structured console logs
SIEM forwarding (Compliance tier)
X-Request-ID on every response

🛡️ Input Validation

Max body: 1 MB
Max prompt: 100,000 chars
Strict application/json for POST
CORS allowlisted origins only

Full Security Headers (from GET /v1/security/headers)

Header	Value
Content-Security-Policy	`default-src 'self'`; marketing pages also allow `'unsafe-inline'` scripts and styles. `'unsafe-eval'` is not used.
X-Frame-Options	`DENY`
X-Content-Type-Options	`nosniff`
X-XSS-Protection	`0` (modern standard)
Referrer-Policy	`strict-origin-when-cross-origin`
Permissions-Policy	`camera=(), microphone=(), geolocation=()`
Strict-Transport-Security	`max-age=31536000; includeSubDomains`

3. Subprocessors

Parse uses few third-party services. One of them receives prompt text.

Subprocessor	Purpose	Location	Sees prompt text?	GDPR adequacy
OpenRouter	Routes the semantic analysis layer (Layer 2) to a model provider, and runs the prompt when `execute: true`	US	Only in full mode	SCCs
Cloudflare	CDN, tunnel, DDoS protection	Global edge	No	SCCs + CISPE
Stripe	Subscription billing	US / Ireland	No	SCCs + PCI-DSS
PostgreSQL (self-hosted)	Screening event storage	US (Mac Mini M4)	Metadata only	N/A (self-hosted)
Redis (self-hosted)	Rate limiting, caching, queues	US (Mac Mini M4)	No	N/A (self-hosted)

Any caller on any tier can keep prompt text away from OpenRouter by passing mode: "pattern-only" per request, which runs Layer 1 only. Organizations can also make this the default for every request by setting defaultMode to pattern-only on their screening policy (PUT /v1/policy), so the control does not have to be repeated per call. Prompt text still reaches Parse in the United States in either case — pattern-only prevents the onward transfer to OpenRouter, not the transfer to Parse. GDPR Art. 28(4) flow-down: Parse imposes the obligations of this DPA on each sub-processor in substance; see the flow-down clause beside the table above. New subprocessors are announced 30 days in advance.

Which model receives prompt text. When the semantic layer runs, OpenRouter routes the request to deepseek/deepseek-v4-flash. OpenRouter can serve a given model from more than one upstream host and Parse does not pin the upstream provider, so the company operating the hardware for a particular request is not fixed — the model is named here because it is the part Parse controls and can state truthfully. What that provider retains or trains on is governed by their policy and OpenRouter's, not by Parse's DPA. Passing mode: "pattern-only", per request or as an organization default, means the semantic layer does not run and no model receives the text at all.

4. Vulnerability Disclosure Policy

Report a Vulnerability

Email: [email protected]

Milestone	SLA
Acknowledgment	48 hours
Initial assessment	5 business days
Critical vulnerability remediation	90 hours (3.75 days)
High vulnerability remediation	15 business days
Medium vulnerability remediation	30 business days
Low vulnerability remediation	90 business days

Safe Harbor: We will not pursue legal action against researchers who respect user privacy, avoid DoS/social engineering, report promptly, and allow reasonable remediation time before disclosure.

5. Compliance Framework Alignment

SOC 2 Type II — In Progress

Parse is actively pursuing SOC 2 Type II certification. Expected completion: Q1 2027.

Certification is in progress and on the roadmap; the controls below are aligned today.

SOC 2 Trust Principle	Criteria	Parse Control	Implemented (self-assessed)
Security (Common Criteria)	CC1: Control Environment	Security governance documented; designated security contact. Parse is operated by one person, so that contact is the operator.	✅ Implemented
	CC2: Communication and Information	Security headers endpoint (`GET /v1/security/headers`), trust page, docs hub, RFC 9116 security.txt	✅ Implemented
	CC3: Risk Assessment	Threat model documented for the prompt injection taxonomy	✅ Implemented
	CC4: Monitoring Activities	Audit logging on security-relevant events; SIEM forwarding on the compliance tier	✅ Implemented
	CC5: Control Activities	RBAC, rate limiting, input validation, policy enforcement	✅ Implemented
	CC6: Logical and Physical Access	Bearer auth, bcrypt-hashed API keys, HSTS, TLS, CORS allowlisting	✅ Implemented
	CC7: System Operations	Structured logging, request tracing (`X-Request-ID`), graceful shutdown, health checks	✅ Implemented
	CC8: Change Management	Versioned deployments, automated CI/CD, dependency audit on every build, type-safe TypeScript codebase	✅ Implemented
	CC9: Risk Mitigation	Rate limiting, sandbox isolation, SSRF guards, three-layer defence pipeline	✅ Implemented
Availability	A1: Availability	Single node, no failover. Database backed up every six hours with a verified restore on every run; ~30 days of snapshots retained. Health check endpoints and published availability history. Recovery is a manual operator task with no committed RTO.	⚠️ Partial
Processing Integrity	PI1: Processing Integrity	Deterministic scoring, seeded semantic sampling with a verdict cache, nonce-tagged LLM delimiters	✅ Implemented
Confidentiality	C1: Confidentiality	TLS in transit, bcrypt/AES-256 for secrets, no prompt storage on the screening endpoints	✅ Implemented
Privacy	P1–P8: Privacy	Documented retention enforced by a daily purge job, data governance module, approval matrix	✅ Implemented

No auditor has examined these controls. The column records whether Parse has implemented the control, self-assessed, and is not an audit result — SOC 2 Type II is in progress with an expected completion of Q1 2027, and there is no independent penetration test.

Additional Frameworks (Roadmap)

Framework	Status	Target
ISO 27001	Planned	Q3 2027
HIPAA	Planned	On customer request
FedRAMP	Planned	Q4 2027
GDPR	Aligned	Ongoing — retention + erasure

6. Pre-Answered Vendor Security Questionnaire

The 31 most common vendor security questionnaire questions, pre-answered for your assessment. Expand each category below.

General Security (Q1–Q5)

1.Does your organization have an information security policy?

Partly, and it is worth being exact about which parts. Parse maintains a documented incident response runbook and a published vulnerability disclosure policy with remediation SLAs by severity. There is no separate, formally reviewed information security policy document. Access control and data protection are implemented and documented on this page rather than in a policy artefact.

2.Does your organization have a designated security officer or CISO?

There is a designated security contact, reachable at [email protected] and published in /.well-known/security.txt. Parse is operated by one person, so that contact is the operator rather than a separate officer with an independent reporting line.

3.Does your organization conduct security awareness training?

Not applicable in the form this question assumes. Parse is operated by one person; there are no other personnel to train. If that changes, this answer changes with it.

4.Are background checks performed on personnel?

Not applicable. There are no personnel other than the operator, and therefore no one to screen for production access.

5.Does your organization have an incident response plan?

Yes. Documented incident response plan with defined roles, escalation procedures, and communication protocols. Incidents logged and reviewed post-resolution.

Access Control (Q6–Q10)

6.Is access to systems and data based on role (RBAC)?

Yes. RBAC with defined roles (org_admin, security_analyst, auditor, developer). Access is enforced at route level by middleware, and org-scoped routes additionally refuse a caller outside the organization that owns the record.

7.Are access rights reviewed periodically?

Not applicable in the form this question assumes. There are no employee accounts with production access, so there are no access rights to review periodically and no departures to revoke. Customer-facing access is per API key: keys are revocable immediately by their owner (DELETE /v1/keys/self) and self-service keys expire after 90 idle days.

8.Are MFA and SSO supported?

Yes. OAuth 2.0 / OIDC-based SSO (Team + Compliance tiers). MFA enforced for administrative access.

9.Are API keys encrypted at rest?

Yes. bcrypt-hashed with salt at rest, plus a non-reversible lookup prefix. The Redis validation cache holds a SHA-256 of the key so the bcrypt comparison does not run on every request. The full key is never written down; it is shown once at generation.

10.Is least-privilege access enforced?

Yes. API keys scoped to organizations and roles. Cross-org access denied at middleware level.

Data Protection (Q11–Q15)

11.Is data encrypted in transit?

Yes. TLS 1.2+ (TLS 1.3 negotiated by default). HSTS enforced with max-age=31536000; includeSubDomains.

12.Is data encrypted at rest?

Secrets are encrypted at rest using AES-256-GCM, and API keys are bcrypt at rest; SHA-256 for the request-validation cache. The database connection itself uses TLS, which protects data in transit to it rather than on disk — Parse does not claim full-disk or column-level encryption for the Postgres volume.

13.Do you store customer prompt data?

The screening endpoints (/v1/parse, /v1/screen-output, /v1/agent/trust/verify) do not: the screening event table has no column for prompt text or a hash of it, on every tier. /v1/evaluate does, for the length of the run — on completion the stored copy is overwritten with the first 100 characters plus a SHA-256 of the full prompt, and those characters remain readable. See Data Storage for the per-endpoint breakdown.

14.What is your data retention policy?

Stated retention: screening events 90 days, audit events 90 days, compliance receipts 1 year, API keys until revocation or expiry. A daily purge job deletes records past each window. Rate-limit counters and the in-memory /v1/evaluate records expire automatically. See Retention.

15.Do you support customer data deletion requests?

Yes. Via [email protected] or [email protected]. Completed within 30 days.

15b.Does prompt text leave your infrastructure?

Yes, for the semantic analysis layer: prompt text is sent to OpenRouter for model scoring unless the caller passes mode: "pattern-only", a pattern already matched at severity 9 or above, or the deployment has no OpenRouter key. Prompt text also reaches OpenRouter and the execution sandbox when the caller opts in with execute: true, which is off by default. See Where Prompt Text Goes.

Network Security (Q16–Q20)

16.Is there a firewall or network segmentation?

Partly, and not by cloud security groups — Parse does not run on a hyperscaler. What is verified: Postgres and Redis bind to loopback only and are not routable from outside the host, and the API is published through an outbound-established Cloudflare tunnel rather than an inbound port mapping, so reaching Parse does not require an open listener on the host. What Parse does not claim: that the host has no other reachable services. It is a general-purpose machine, network exposure depends on the upstream network rather than on Parse, and no host-level firewall policy is asserted here.

17.Is rate limiting implemented?

Yes. Redis sliding-window with in-memory fallback. Tier-based limits. HTTP 429 with Retry-After.

18.Are security headers enforced?

Yes. CSP, X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy, Permissions-Policy, HSTS on all responses.

19.Is CORS configured securely?

Yes. Restricted to allowlisted origins via ALLOWED_ORIGINS env var. Unrecognized origins receive no ACAO header.

20.Is input validation enforced?

Yes. Max body: 1 MB. Max prompt: 100K chars. Strict application/json required for POST.

Vulnerability Management (Q21–Q24)

21.Are regular vulnerability scans performed?

Yes. Automated dependency scanning in CI/CD. Critical CVEs tracked with automated remediation.

22.Is there a vulnerability disclosure program?

Yes. Reports accepted at [email protected]. 48h acknowledgment SLA, 90h remediation SLA for critical.

23.Are penetration tests performed?

No. No independent penetration test has been performed against Parse. Saying so plainly is more useful to your assessment than a scheduled-basis claim you cannot verify — treat this as an open gap and weigh it against the compensating controls listed on this page. Automated dependency scanning does run on every CI build (npm audit, failing at high severity), and the vulnerability disclosure programme in section 4 is live.

24.Is there a patch management process?

Yes. Prioritized by severity. Critical patches within 90 hours. Dependency updates automated.

Logging & Monitoring (Q25–Q28)

25.Are security-relevant events logged?

Yes. Audit events: auth failures, rate limit breaches, policy changes, screening events, bypass codeword usage. Stored in Postgres + structured logs.

26.Is SIEM integration available?

Yes. SIEM forwarding via HTTP webhook on Compliance tier. Real-time event forwarding.

27.Are logs retained and protected?

Yes, in access-controlled, encrypted storage. Stated retention is 90 days for screening logs and 1 year for compliance receipts, enforced by a daily purge job — see Retention.

28.Is request traceability supported?

Yes. X-Request-ID on every API response for end-to-end correlation.

Business Continuity (Q29–Q30)

29.Is there a BCP/DR plan?

Backups yes; failover no. Parse runs on a single node — there is no multi-instance failover, and a hardware failure is an outage rather than a transparent recovery. What does exist: the production database is dumped every six hours to external storage, and every run performs a real restore into a scratch database and compares a row census against the source, because a backup nobody has restored is a hope rather than a backup. Retention is configured for the 120 most recent snapshots (about 30 days at six-hourly), and the result is checked daily. Retained history is capped by however long the schedule has been running, which is shorter than the policy on a new deployment. That gives a recovery point objective of about six hours. No recovery time objective is committed: restoring is a manual operator task. A documented incident response runbook covers the procedure.

30.What is your uptime commitment?

Parse targets 99.9% and does not commit to it contractually except on the Compliance and Enterprise tiers, where a formal SLA is available. Treat the figure as an operating target rather than a guarantee. Measured availability is published on the status page; liveness is monitored at /health.

Questions?

For security assessments, NDA requests, or custom questionnaire completion, contact us:

[email protected]

General support: [email protected] · Programmatic posture: GET /v1/security/headers