What we do with the keys you give us
Affiliate Guardian reads the reporting behind your affiliate income. That access is a responsibility, so here is exactly how it is held. This page ships from day one and stays current as the product grows.
- 01
Your data is walled off at the database, not just the app
Every tenant is isolated with Postgres row-level security from the very first migration. A tenant id sits on every row, and the isolation is enforced by the database itself, so a bug in application code cannot leak one publisher's data to another.
- 02
Credentials are envelope-encrypted, and we never hand them back
Each tenant gets its own data encryption key, wrapped by a managed key service. Network credentials are never written to logs and are never returned by any part of the product, including the API and the MCP server. Secret scanning and push protection run on the code that touches them.
- 03
We ask for read-only network access wherever a network offers it
The job is to watch your reports, not to change your account. Where a network supports read-only scopes, that is what we request.
- 04
We never touch your bank
Recovery is verified against network reporting, which is the ground truth for what a network actually pays. Bank access would add lag and zero attribution, so we do not ask for it and we never will.
- 05
Shared benchmarks stay anonymous by construction
When leak signatures and program health feed cross-publisher benchmarks, they pass a k-anonymity floor first. The schema is built for this from the first row so that aggregation can never expose an individual account.
What we have not done yet
We are not SOC 2 certified. That audit is deferred until a specific customer needs it, and we would rather tell you that than imply a badge we have not earned. If your team requires it to move forward, talk to us and we will start the process.