How ReadyReq protects your agency's data — and where it doesn't yet.

Getting in: access codes, not passwords (yet)

Each person gets their own access code from an admin on the Team page. A code opens that one person's seat in one agency's workspace. There are no passwords, no single sign-on and no two-step sign-in yet. Real sign-in is planned, and codes will keep working beside it.

New codes end in 8 random characters from a cryptographic random generator — 852,891,037,441 possibilities for each name, about 39 bits — after a short prefix taken from the person's name. Codes made before September 26, 2026 have a shorter, weaker random part (4 characters, not from a cryptographic generator). The app can't replace a code yet; send us a security request and we'll replace yours by hand.

Codes are stored as plain text in our database, so an admin can show a rep her code again. Anyone with access to that database could read them; only the people who run ReadyReq have that access.

The sign-in screen pauses briefly after a wrong code, but not every part of the app does, and there is no lockout after repeated wrong codes yet. Keep your code to yourself. If one leaks, ask us to replace it (the request form below) and we change that code while the person keeps their seat, leads, invoices and connected inbox. Don't remove and re-add someone to get a new code: removing a person stops their code at once, but it also deletes their connected inbox and LinkedIn records and leaves their leads without an owner. Removing is for someone who is leaving.

Agencies are kept apart

Every agency record carries the workspace it belongs to, and everything our server reads or writes for a code is limited to that code's workspace. Inside a workspace, a rep works her own leads and an admin sees the whole team's; invoices and the client book are shared across the workspace. These rules run on our server, not in your browser, and our automated tests include checks that one agency can't read or change another's records.

Our own admin inbox, where website requests land, sits behind a separate key that only we hold.

Encryption

• In transit. This website and the app are served over HTTPS by our host, and our server reaches the database and every company that processes data for us over HTTPS.
• At rest. Our database provider, Neon, states that it encrypts stored data. That's its commitment, not something our code does.
• Connection tokens. The refresh tokens that let a rep's inbox send, and your agency's Manatal API token, are sealed by our own code with AES-256-GCM before they're stored, using a key kept outside the database. A token saved before sealing was switched on stays as it was until the rep reconnects or an admin saves the Manatal token again.
• Access codes are not encrypted or hashed; see above.

Fixed on September 26, 2026

• Your agency's Manatal API token now goes through the same sealing as inbox tokens; it used to be stored as plain text.
• Removing a person now deletes their inbox connection and their LinkedIn upload too. Both used to stay behind.
• New access codes come from a cryptographic random generator, and their random part is 8 characters instead of 4.
• Daily usage counters, which hold access codes and IP addresses, are now deleted after 60 days. They used to be kept indefinitely.

Daily caps

Caps limit what a leaked code or a misbehaving script can cost. They reset at midnight UTC.

AI requests

300 per access code per day.

Emails sent

20 per connected inbox per day.

Email-address checks

40 per access code per day, up to 10 addresses each.

Website chat

30 questions per connection per day.

Website requests

5 invite requests, and 5 privacy or security requests, per connection per day.

What we don't do

• We don't scrape. ReadyReq never logs into or automates LinkedIn, and our server never fetches pages from LinkedIn, Indeed, Glassdoor, ZipRecruiter, Facebook, Instagram or X (Twitter). Links to them open in your own browser. The AI's web search runs on Anthropic's side and can see public search results, LinkedIn's included, the way any search engine does.
• We don't read your inbox. When a rep connects Gmail, ReadyReq asks Google for exactly two permissions: send email as you (gmail.send) and see your email address (userinfo.email). When she connects Outlook, it asks Microsoft to send mail as you (Mail.Send), read your basic profile (User.Read), sign you in (openid), see your email address (email) and keep that permission until you disconnect (offline_access). That is send-only: none of these permissions lets ReadyReq read, search, move or delete anything in an inbox.
• We don't send without you. Nothing goes to a prospect until a rep presses Send.
• We don't hunt for individual candidates. ReadyReq finds client companies. Its talent features work from companies' public news and your agency's own records; it doesn't look up individual people for you to recruit.
• We don't track you. No cookies, no analytics, no advertising scripts.
• We don't sell your data or train AI models on it.

Report a security problem

If you find a security problem in ReadyReq, please tell us before telling anyone else, and give us a reasonable time to fix it. While you look, don't access or change other people's data, don't slow the service down for others, and don't try to trick our users or us. We don't run a paid bug bounty during the pilot.

What's next

Real sign-in, with codes working alongside it. If ReadyReq ever asks an inbox for more than sending — for example, to notice replies — that will be switched off until each rep agrees, and this page and our privacy page will change in the same release.