Parse Trust Package

Version: 1.1
Last Updated: 2026-08-11
Contact: [email protected]

Table of Contents

1. Architecture Overview
2. Security Controls Summary
3. Subprocessors
4. Vulnerability Disclosure Policy
5. Compliance Framework Alignment
6. CAIQ-lite / SIG-lite Answer Set

1. Architecture Overview

1.1 Three-Layer Screening Pipeline

Parse uses a defense-in-depth screening pipeline that evaluates untrusted text through three independent layers before returning a risk verdict. 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          │
 │  (100+ patterns, │     │  (nonce-tagged         │     │  (isolated eval,    │
 │   9 categories,  │     │   delimiters, multi-   │     │   SSRF-guarded URL  │
 │   normalization) │     │   window sampling)     │     │   prefetch, DOM     │
 │                  │     │                        │     │   stripping)        │
 └──────────────────┘     └───────────────────────┘     └─────────────────────┘
         │                          │                            │
         ▼                          ▼                            ▼
    Flags + Score              Flags + Score              Flags + Score
         │                          │                            │
         └──────────┬───────────────┘────────────────────────────┘
                    ▼
         ┌─────────────────────┐
         │  Aggregated Verdict  │
         │  - risk_score (0-10) │
         │  - safe: true|false  │
         │  - suggested_action  │
         │  - categories[]      │
         │  - flags[]           │
         └─────────────────────┘

Layer 1 — Deterministic Pattern Matching
100+ compiled regex patterns across 9 risk categories (prompt injection, jailbreak, data exfiltration, indirect injection, social engineering, code execution, system prompt leak, credential disclosure, unsafe URL). Includes text normalization to catch encoded/obfuscated payloads (Unicode, hex, base64, homoglyphs).

Layer 2 — LLM Semantic Analysis
Semantic risk scoring via OpenRouter multi-model inference. Uses nonce-tagged delimiters to prevent prompt reflection, multi-window sampling for long inputs, and model diversity to reduce single-model blind spots. Configurable per tier; can be disabled by the operator.

Layer 3 — Isolated Sandbox Execution
Optional isolated execution environment (src/lib/sandbox-client.ts) for suspicious prompts that warrant deeper inspection. Features HMAC-authenticated communication, SSRF-guarded URL prefetch, and DOM-aware hidden content extraction. Disabled by default; enabled per-tier.

1.2 Data Flow Diagram

┌──────────┐         ┌───────────┐         ┌──────────────┐
│  Client  │────────▶│  Parse API│────────▶│ Pattern Match│
│ (Agent/  │  POST   │  (Hono    │  Layer 1│  (in-process)│
│  SDK)    │  HTTPS  │  server)  │         └──────┬───────┘
└──────────┘         └─────┬─────┘                │
       ▲                    │                      ▼
       │                    │         ┌──────────────┐
       │                    │         │ LLM Analysis │
       │                    │  Layer 2│ (OpenRouter)  │
       │                    │         └──────┬───────┘
       │                    │                │
       │                    │                ▼
       │                    │         ┌──────────────┐
       │                    │         │ Sandbox Exec │
       │                    │  Layer 3│ (optional)   │
       │                    │         └──────┬───────┘
       │                    │                │
       │             ┌──────▼────────────────▼───────┐
       │             │   Verdict Aggregation + Scoring│
       │             └──────┬────────────────────────┘
       │                    │
       │                    ▼
       │             ┌──────────────┐         ┌───────────┐
       │             │ Screening    │────────▶│ Postgres  │
       │             │ Event Log    │         │ (AuditEvent│
       │             │              │         │  table)    │
       │             └──────────────┘         └───────────┘
       │                                               ▲
       │                    ┌──────────────┐           │
       └────────────────────│ JSON Response│           │
                            │ + Audit Log  │───────────┘
                            └──────────────┘

1.3 Data Storage, Retention, and Where Prompt Text Goes

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.

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] — deletion requests are completed within 30 days.

Where prompt text goes

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

What OpenRouter and the model providers behind it do with text they receive is governed by their policies, not ours. Pattern-only mode keeps the text away from them entirely.

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

Pattern-only screening is a real trade: pattern matching alone under-reports paraphrased and indirect attacks that the semantic layer catches. Every response reports which layers ran, and a pattern-only response carries layers.llm: "skipped_pattern_only".

2. Security Controls Summary

2.1 Rate Limiting

• Algorithm: Redis sliding-window with in-memory fallback
• Implementation: Atomic Lua script on Redis ZSET for true sliding window; in-memory fixed-window fallback when Redis unavailable
• Tier-based limits:

  Tier	Requests/Minute
  Free	10
  Pro	100
  Team	500
  Compliance	500
  Enterprise	500 (1000 burst)

• Response headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After
• Rate-limited response: HTTP 429 with Retry-After header
• Key hashing: API keys are SHA-256 hashed before use as rate-limit keys (privacy)

2.2 Role-Based Access Control (RBAC)

• Roles: admin, owner, member, viewer
• Enforcement: Route-level middleware (src/auth.ts, src/lib/rbac.ts)
• Organization scoping: API keys are scoped to organizations; cross-org access is denied
• Policy packs: Configurable per-organization screening policy enforcement

2.3 Single Sign-On (SSO)

• Protocol: OAuth 2.0 / OpenID Connect
• Implementation: src/routes/sso.ts, src/lib/sso/sso-provider.ts
• Supported providers: Configurable (Google, Microsoft, Okta, Auth0, custom OIDC)
• Status: Shipped — available on Team and Compliance tiers

2.4 Encryption

2.5 Audit Logging

• Event types logged:
  • auth_failure — Failed authentication attempts
  • rate_limit_exceeded — Rate limit threshold breaches
  • policy_change — Screening policy modifications
  • prompt_screened — Screening events (verdict, categories, score)
  • screening_codeword_bypass_used — Emergency bypass codeword usage
• Storage: Postgres AuditEvent table + structured console logs (JSON)
• SIEM forwarding: Available on Compliance tier; forwards to customer SIEM via HTTP webhook
• Request traceability: Every response includes X-Request-ID for end-to-end correlation

2.6 Additional Security Headers

Parse enforces the following security headers on all responses (see GET /v1/security/headers):

2.7 Input Validation

• Max request body: 1 MB (1,048,576 bytes)
• Max prompt length: 100,000 characters
• Strict content type: application/json required for POST endpoints
• CORS: Restricted to allowlisted origins (configurable via ALLOWED_ORIGINS)

3. Subprocessors

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

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.

New subprocessors are announced 30 days in advance at [email protected].

Which model receives prompt text. When the semantic layer runs, OpenRouter routes the request to deepseek/deepseek-chat. 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

4.1 Reporting a Vulnerability

We welcome responsible disclosure of security vulnerabilities.

• Email: [email protected]
• PGP Key: Available on request
• Response scope: All vulnerabilities affecting Parse's API, web properties, SDK, MCP server, or infrastructure

4.2 Service Level Agreements

4.3 Scope

In scope:

• All *.parsethis.ai domains and subdomains
• The Parse API (/v1/* endpoints)
• The Parse SDK (@parsethis/sdk)
• The Parse MCP server
• Infrastructure misconfigurations affecting customer data

Out of scope:

• Social engineering attacks
• Physical security attacks
• Denial-of-service attacks (please report to [email protected])
• Vulnerabilities in third-party services not operated by Parse

4.4 Safe Harbor

We will not pursue legal action against security researchers who:

1. Respect user privacy and do not access or modify customer data
2. Do not attempt brute-force, DoS, or social engineering attacks
3. Report vulnerabilities promptly through the designated channel
4. Provide reasonable time for remediation before public disclosure

5. Compliance Framework Alignment

5.1 SOC 2 Type II — In Progress

Parse is pursuing SOC 2 Type II certification. The audit is in progress with an expected completion in Q1 2027. This section maps our current controls to the SOC 2 Trust Services Criteria.

5.2 Control Mapping

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 yet (first test scheduled for Q2 2027, after SOC 2 fieldwork).

5.3 Additional Frameworks (Roadmap)

6. CAIQ-lite / SIG-lite Answer Set

Pre-answered responses to the 31 most common vendor security questionnaire questions. These answers can be pasted directly into CAIQ, SIG, or custom vendor security assessment forms.

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 — and the first one is scheduled. No independent penetration test has been performed against Parse yet; the first is scheduled for Q2 2027, immediately after SOC 2 Type II fieldwork completes, so the remediation of findings feeds the same audit cycle. Saying the current state plainly is more useful to your assessment than a scheduled-basis claim you cannot verify — treat this as an open gap until the report exists, 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.