Skip to content
AttestLayerAttestLayer

Partner & Program Security

Separate the public qualification flow from the paid package workflow—and prove only what each one supports.

Last updated: 17 July 2026

This page covers partners.attestlayer.com and program.attestlayer.com. Public qualification is a contact-and-fit workflow. It is not a production upload, checkout, package-generation, or authenticated-console endpoint.

1. Public qualification controls

  • Transport: public endpoints use HTTPS; HSTS and restrictive browser security headers are configured.
  • Input controls: the endpoint restricts origin, JSON content type, body size, field types and lengths, email and URL shape, calendar dates, and allowed commercial options.
  • Abuse controls: one-way hashed network and email rate-limit keys, a hidden honeypot, and a short-lived first-party proof-of-work challenge bound to the email, request network, and site host.
  • Outbound mail: SendGrid API calls use timeouts. Open and click tracking are disabled by the application.
  • Minimal logs: the qualification event excludes names, company, email addresses, billing contacts, signer details, and free-text notes.
  • No checkout or files: the public form does not accept payment-card data, bank details, source records, Buyer Review Pack files, credentials, or signatures.

2. Qualification and automation are different decisions

Rabie-Abdollah Macbahi, the accountable owner, assesses commercial partner fit. That owner assessment is separate from Buyer Review Pack generation. Versioned processing: the package workflow uses versioned automated processing; it does not include an analyst quality-assurance pass and does not make unsupported records true.

3. Buyer Review Pack package integrity

Where an executed agreement authorizes Buyer Review Pack delivery, the package contains a canonical manifest and an Ed25519 signed receipt binding the manifest SHA-256. A verifier recalculates package-file hashes and requires the receipt key ID to resolve to the applicable issuer key published by the AttestLayer Registry. A key embedded only inside the package cannot establish trust.

  • Re-issuance: an issued package is not modified in place; a re-issuance receives a new receipt identifier and signature.
  • Registry boundary: Registry inclusion is separate and is not currently active for Buyer Review Pack issuance.
  • Meaning: successful verification establishes package integrity and receipt authenticity—not compliance, certification, record completeness, buyer approval, or truth of every supplied claim.

4. Infrastructure and secrets

  • Application platform: Google Cloud Run in northamerica-northeast1 (Montréal) with Google Cloud-managed encryption at rest.
  • Secrets: production secrets are supplied to dedicated services through Google Secret Manager; they are not committed to public source or exposed in browser responses.
  • Access: production release authority is restricted and release evidence is bound to the exact source and artifacts.
  • Locations: email, provider support, security, and network services may process limited information outside the application region. See Privacy and Subprocessors.

5. Claims AttestLayer does not make

  • No SOC 2, ISO, or other certification is claimed.
  • No penetration test, audit opinion, legal advice, compliance approval, or buyer-acceptance guarantee is provided.
  • No customer-managed encryption, dedicated region, white-label, custom logging, or custom retention entitlement exists unless an executed agreement states it and the control is technically enabled.
  • Public pages are not a third-party security assessment or independent audit of the authenticated console.

6. Report an issue

Send suspected vulnerabilities to security@attestlayer.com. Do not include secrets or exploit sensitive data in the first message. The coordinated process is at partners.attestlayer.com/vulnerability-disclosure.