bRRAIn marketplace

Marketplace Certification Criteria — v1.0

Every listing on marketplace.brrain.io is certification-gated per design decision DEC-2026-04-27-005 and DEC-2026-04-27-011. This page is the canonical reference for what vendors must declare, what MHJ reviewers verify, and the concrete v1.0 thresholds applied during automated scans.

1. Scope

Certification covers every endpoint a listing exposes that the customer's bRRAIn instance reaches at runtime. App backends may run anywhere — vendor-hosted SaaS, vendor's own AWS/GCP/Azure deployment, or on-prem — but every endpoint must pass review prior to listing approval. Customer-side per-org policy at runtime (Zone 6 MCP gate) does not bypass listing-time review.

2. Endpoint Posture Requirements

2.1 Transport (TLS)

• Minimum: TLS 1.2 (floor — required at v1.0).
• Preferred: TLS 1.3.
• Cert chain: publicly-trusted CA. Self-signed certs rejected.
• Cert validity: automated scan rejects endpoints whose certificate expires within 14 days. Vendors must auto-renew (Let's Encrypt + Caddy is acceptable).

2.2 Authentication

• Auth model: one of bearer, mtls, oauth, or none (per the listing schema). none only allowed for read-only public endpoints.
• Auth scopes: the vendor must declare every OAuth scope or token claim the endpoint requires. Reviewer verifies that the scopes are minimal — rejecting endpoints that demand broader scopes than the app actually uses.
• Token lifetime: bearer tokens issued by the customer's bRRAIn must be honored; vendor cannot require its own auth flow that bypasses bRRAIn identity.

2.3 Data Flows

• Data received: vendor declares every category of customer data the endpoint receives in requests (e.g. "prompt text", "vault filenames", "user identity claims"). Surfaced verbatim in the catalog so customers can audit.
• Data stored: vendor declares data retained after processing. Empty list means stateless. Reviewer verifies declaration matches reality via vendor-provided architecture review.
• Egress destinations: vendor declares every third-party service the endpoint forwards data to. Empty means no egress beyond the customer's bRRAIn instance. Reviewer verifies declared egress destinations against actual outbound DNS/connection logs (vendor-supplied or sampled by reviewer).

2.4 Performance

• Latency SLA: vendor publishes a credible response-time commitment (e.g. "p99 < 500ms"). Free-form per-vendor; reviewer probes the endpoint to confirm the published SLA is achievable under load.
• Reachability gate (automated): the scanner rejects endpoints whose response time exceeds 5 seconds during a single GET probe (this is a liveness gate, not the published SLA — generous so transient slowness doesn't fail an otherwise-fine endpoint).
• Status page: public status page recommended (soft gap at v1.0 if missing). Required for Co-Located and Sovereign On-Prem tier listings.

2.5 Security Posture

• Incident notification URL: required at v1.0. Where bRRAIn emails security incidents that affect this listing's customers.
• Vulnerability disclosure: required at v1.0. Public link to the vendor's vuln disclosure / bug bounty policy. Empty placeholder is rejected.
• SOC 2 / ISO 27001: claims optional at v1.0. If claimed, reviewer requires the audit report (or attestation letter) before approval.

2.6 Business Continuity

• Escrow + exit data export: vendor declares whether they offer source-code escrow, customer-data export at termination, or both. Optional at v1.0; surfaces verbatim in the catalog. Required for Sovereign On-Prem tier.
• Advance notice on shutdown: vendor commits to a minimum days-of-notice before deprecating the endpoint. Reviewer recommends 90 days.

3. Listing-Level Requirements

• Description: non-empty; reviewer-readable; not promotional spam.
• Screenshots: SVG only (Vector-First Design Standard — no raster). Each screenshot must show the actual rendered app, not stock art or marketing renders.
• Pricing: declared model + amount + period must round-trip the validator. Free, flat, per-seat, and usage are the v1.0 models.
• Signing: publisher key (ed25519 base64url-no-pad, 32 bytes) required at first signed-manifest publish. Lands in Epic 7 vendor portal flow.
• Support contact: email or https URL. Verified by sending the cert decision to that address.

4. Review Workflow + SLAs

1. Vendor submits via POST /api/cert/listings/{slug}/submit with claims for every endpoint. Listing transitions pending → under-review.
2. Automated scanner runs against every endpoint (Story 3.4): records TLS version, cert expiry, response time, reachability. Vendor sees the pre-submission report; reviewer sees it alongside the manual checklist.
3. MHJ reviewer audits each per-endpoint ReviewRecord within 5 business days of submission (target turnaround). Reviewer issues accepted, needs-changes, or rejected per endpoint.
4. Reviewer issues listing-level approve or reject. Approve auto-accepts any still-pending endpoint reviews; reject requires non-empty notes.
5. Vendor notified at the support contact email/URL. Approved listings appear publicly within minutes.
6. Vendor may withdraw at any point during under-review (POST .../withdraw) to fix issues without waiting for a reject verdict.

5. Rejection Criteria

5.1 Instant-fail (no resubmission window)

• Vendor misrepresented data flows (declared "no egress" but reviewer found egress to an undeclared third party).
• Endpoint serves unsigned or compromised code (e.g. supply-chain incident at the vendor).
• Vendor refused to provide architecture review or audit reports when reviewer requested them.

5.2 Remediable (vendor fixes + resubmits)

• TLS < 1.2 or expiring cert.
• Latency SLA not credible against reviewer probe.
• Auth scopes broader than the app needs.
• Missing or stale incident-notification URL or vulnerability-disclosure link.
• Screenshots violate Vector-First standard.
• Description is promotional copy rather than functional description.

6. Re-Cert Triggers

An approved listing must resubmit for review when any of the following changes:

• Endpoint URL or backend deployment moves (different region, new vendor cloud, etc.).
• Auth model or scope changes (e.g. new required scope).
• Data flows change (new data category received, new egress destination).
• Major version bump on the published manifest (semver MAJOR; minor + patch versions roll without re-cert).
• Ownership change (vendor acquired, sold, or rebranded).

7. Automated Tooling Thresholds (Story 3.4)

The pre-submission scanner exposed at POST /api/cert/scan applies these v1.0 gates:

• TLS minimum: 1.2 (1.3 preferred — surfaced as a hint, not a fail).
• Cert validity buffer: 14 days (fail if expires within).
• Response time: p99 < 5 seconds during a single probe (gate fail above).
• Rate limit: 1 scan per hour per vendor per endpoint (prevents accidental DDoS during pre-submission iteration).
• Reachability: HTTP GET must return any 1xx/2xx/3xx/4xx (5xx is a fail; 4xx is a soft warn since some endpoints reasonably require auth to return 2xx).

8. Carryovers (post-1.0)

• SOC 2 / ISO 27001 attestation upload + reviewer storage flow.
• Architecture review submission portal.
• Continuous post-approval monitoring (current cert is point-in-time; ongoing scans land post-1.0).
• Penetration-testing requirement for Sovereign On-Prem tier listings.
• Vendor self-service rate-limit dashboard.

Last updated: 2026-05-02. Operationalised at Epic 3 close. Maintained by MHJ. See also: marketplace home · source.