Skip to content
saylek

Security

How we keep the pool trustworthy.

Saylek pools GPU capacity across Circles of people you trust, so trust is the product. This page describes the security properties the system has today, during the beta, and how to reach us if you find a problem. It is an honest summary of the running system, not a certification claim.

Signed receipts

Every request produces a cryptographically signed receipt recording which machine served it. Both the requester and the serving host keep a copy, and either side can verify it offline, so a served request can be checked independently, not just taken on faith.

Email-blind identity

Within a Circle, members are identified by a display name, not their email address. Sharing capacity with people you trust does not expose your email to the pool.

Sign-in

Sign-in is passwordless: a one-time magic link sent to your email, so there is no reusable password to phish, guess, or leak.

Beta, and how access actually works

Anyone can create an account: it takes an email address and a bot check, with no invitation and no allowlist in front of it. Nothing here is protected by a network perimeter or an address allowlist, so every public endpoint should be read as internet-facing and each one stands on its own authentication. The site is excluded from search-engine indexing while we harden the surface ahead of public launch.

Disclosure policy

Mail security@saylek.com with what you found and how to reproduce it. That address reaches a person. Please do not use the support form for a security report: it forwards what you submit onward, which makes it the wrong place for one.

The machine-readable pointer to this clause is at /.well-known/security.txt.

In scope

  • saylek.com and its subdomains.
  • The Saylek daemon and CLI, and the update and release path that delivers them.
  • The registry that routes a request from one member to another.
  • Receipts: anything that lets a signed record be forged, replayed, or misattributed.

Out of scope

  • Another member's own machine. Members run this on hardware they own, and it is not ours to authorise testing against.
  • The content a model produces. Wrong or offensive output is a model property, not a vulnerability.
  • That a Host can read a request it is serving. That is disclosed on the terms as how the system works, not as a defect.
  • Volumetric denial of service, spam, and social engineering of members or staff.

Safe harbour

If you research in good faith, stay inside the scope above, and give us a chance to fix what you find before you publish it, we will not pursue or support legal action against you for it, and we will treat your report as authorised access. In return we ask that you do not access, alter, or keep data that is not yours, do not degrade the service for other members, and stop at the point where you have proved the issue rather than pressing further.

What happens next

We will acknowledge your report, tell you what we think it is, and keep you posted while we fix it. We are a small team in beta and we have not set a formal response time, so we are not going to quote you one. If you want credit when the fix ships, say so and we will name you.

For anything that is not a security report, use Contact instead.

This page describes the system as it runs in beta. No outside party has audited it, and nothing here is a certification. Where a claim is not yet true, this page says so rather than rounding it up.