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.
