Authorization & scope
The founder authorized the test directly with clear rules of engagement: test using our own account(s); a second, founder-provisioned account for cross-tenant access testing; no load or denial-of-service testing; nothing touching other users' real data; all findings reported privately first. We worked strictly inside that scope — a textbook example of a founder handling authorization correctly.
- Full testing of the live production application using our own accounts
- A second, isolated tenant provisioned specifically for cross-tenant access-control testing
- Excluded: any load / DoS testing; any access to other users' real data
- Private disclosure channel to the founder for anything found
Why this system's security model matters
The product is multi-tenant: many customers' private data live in the same system, separated by access-control logic, not by physically separate deployments. It also exposes an MCP server, letting external AI agents read and write a user's data on their behalf. That combination — a shared multi-tenant store plus an agent-reachable API — is exactly where a small AI product most often leaks one customer's data to another. That is where the test focused.
What was tested
Cross-tenant authorization (IDOR / BOLA)
Every API object and endpoint was tested for broken object-level authorization — attempting to read and write the second tenant's objects from the first, in both directions, and across both token transports the platform accepts (authorization header and URL-embedded token). Object identifiers were manipulated and replayed across tenants. Authorization held on every path tested.
Server-Side Request Forgery (SSRF)
URL-ingesting functionality was tested with a full bypass ladder: private-IP ranges, IPv6 loopback, decimal-encoded addresses, and redirect-to-metadata chains aimed at cloud metadata endpoints. No server-side request could be coerced to an internal target.
Injection, stored XSS, and output handling
User-controlled fields that persist and re-render — including content that flows through the AI/MCP layer — were tested for stored cross-site scripting and injection. Output handling was safe throughout.
Database row-level security & OAuth
Tenant isolation was verified at the data layer (row-level security enforcement), and the OAuth authorization flow was reviewed for redirect, state, and token-handling weaknesses. Both were sound.
Business-logic & anti-fraud
Revenue-share / referral logic was probed for manipulation and double-counting. Controls behaved as intended.
Outcome
No exploitable vulnerabilities were identified. Two non-exploitable hardening observations were reported privately as defense-in-depth suggestions. The result reflects a product built with tenant isolation and safe input handling from the ground up — and a clean bill under adversarial, positive-control testing is itself a deliverable a founder can hand to customers and auditors.