Handing any company access to your business accounts is a real decision, so this page lays out exactly what we do with your credentials, your access and your data, in enough detail that you can go and check it rather than take our word for it.
We will never ask you for the password to your Google account, your mailbox or anything else, and there is no box anywhere in the product to type one into. Access happens on the provider's own screen, where they show you exactly what is being asked for, and you can pull it back any time without telling us first.
For mail, Corp requests gmail.modify rather than full mail
access. The difference is material: gmail.modify cannot
permanently delete a message. Corp reads and drafts, so the broader scope is
never needed and never requested.
For reviews, Corp requests business.manage, which is what is
required to read a review and publish a reply to it. Nothing wider.
The mail tool cannot send. There is no mail sending library in the package, no send API call, no automated click of a send control, and no configuration value that could enable one. A test asserts the capability does not exist.
This is a stronger guarantee than sending being switched off. A tool that could send and merely chose not to is one configuration mistake away from a customer receiving something nobody read.
The single exception is a reply to a Google review, and only where the owner turned that on themselves, set the star threshold and set the delay. Anything below the threshold, or anything carrying a compliance flag, waits for a person regardless.
Secrets live in environment configuration, never in source code and never in a message. The code repository has a commit hook that refuses any commit containing a credentials file, by name and by content, so a secret cannot reach the repository by accident. A credential that leaks is revoked and regenerated, not tolerated.
Corp runs on your own machine, in its own directory, with its own configuration and its own browser session. Your reviews, mail, applicant records and spending data are read where they already live.
They are not uploaded to us. There is no central copy of your data, which means there is no central copy of it to breach, and nothing shared with another business that could leak across.
Files submitted to a tool on this website are processed to produce your result and deleted within 24 hours. Nothing is retained to build a profile from.
A job that finds nothing when it should have found something raises an alarm rather than logging normally. Every scheduled job reports to a dead man switch that fires if it stops checking in.
That failure path is tested by deliberately breaking it, not assumed to work. A system that reports success while doing nothing is the failure that actually costs people money, and it is the one we watch for hardest.
In transit, everything. Every connection to Corp runs over TLS. The site and your portal are served with HTTP Strict Transport Security set to a year, so a browser refuses to connect over plain HTTP even if somebody tries to force it. Plain HTTP requests are redirected, not served.
Every connection out is encrypted too. Mail goes over SMTP with implicit TLS, mailbox reads over IMAP with TLS, and every API call over HTTPS. There is no unencrypted path in or out.
Credentials are never in the code. They live in a permission restricted configuration file that is excluded from version control by name and by content, and a commit hook refuses any commit that would carry one. They are never written to a log, never printed, and never sent in a message.
Access tokens are generated, not chosen. Each client's portal token is cryptographically random rather than derived from anything about them, so it cannot be guessed from a business name or an email address. Tokens are per client, and one is useless against another.
Your data is not pooled. Every request for your information is filtered by who you are down at the database rather than up in the page. That is the difference between a real boundary and a cosmetic one: a check in the interface can be walked around by editing a web address, and a check in the database cannot. There is no account number in any request for anybody to change.
Your account key is generated at random rather than worked out from your business name or your email address, so it cannot be guessed from anything somebody could look up about you. Keys are per client and one is worthless against another.
Anything of yours that we do store is locked with a key that belongs to your account alone, so even sitting still it is not readable alongside another client's. Nothing is cached across accounts and nothing is shared between them.
Two people at Corp can open a client account to help with a problem, and that is the only exception in the whole system. Every time it happens it is recorded, with who looked, whose account and when. A band across the top of the screen says whose account is being viewed for as long as it is open. There is no way for us to sign in as you, no password bypass, and nothing reachable from there writes to your records.
We test that boundary by attacking it. A request that tries to reach another account quietly gets its own account back instead, and the endpoint that lists clients refuses anybody who is not staff.
If you find a security issue, write to hello@corpsystems.net and a person reads it the same day. You will get an answer about what was wrong and what was done.