Security

All traffic between your browser and the application is encrypted with TLS, as is traffic between our services and the third-party APIs we depend on.

Two categories of sensitive data get an additional layer of AES-256 encryption applied by the application before they are written to the database, using a key held in the deployment environment and never in the database itself.

• The raw output of an automated scan run, which can contain detail about your infrastructure that the findings alone do not.
• Any test-account credential you supply so the agent can test authenticated parts of your application.

Everything else, including findings, generated reports and documents, the pentest run activity log, and scan notes you paste in yourself, is stored without that additional application-layer encryption and is protected by the database and hosting controls instead. We would rather list the two things that get it than let you assume it covers everything.

Account passwords are hashed by our authentication library and are never stored in a recoverable form. Payment card details are handled by Stripe and never reach our servers.

• An engagement has to be approved before an autonomous run is accepted at all, and the person starting it must tick an authorization certification that is never pre-ticked.
• Before a run starts, every approved target is resolved and dropped if it points at a loopback, private, link-local, or otherwise reserved address. That vetting is what keeps a run off internal infrastructure.
• Scope is snapshotted onto the run, so editing the engagement while a run is in flight does not change what that run may touch. Within a run the engine admits the approved hosts and their subdomains.
• Pentests execute in a separate worker service, not in the web application that serves your dashboard.
• Every run has a wall-clock budget, and a run can be aborted from the dashboard. An engine task already in flight can overrun the budget by up to its own task timeout.
• Authorization events, meaning who approved which target and when, are written for engagement changes, run starts and aborts, scans, retests, and report generation, and are retained for 24 months after an account closes.
• The run activity log keeps the most recent 500 events. A long run can therefore lose its earliest steps, though the authorization events above are kept in full.

Scan triage and document generation call OpenRouter with a routing instruction that requires a zero-data-retention provider and denies provider-side data collection. The pentest execution engine and the report writer use a different request shape that carries no such field, so on those two paths retention is governed by the setting on the provider account rather than per request. The Privacy Policy sets this out in full.

The application, the testing worker, and the Postgres database run on Render. Production credentials are held in the deployment environment rather than in the codebase or the database, and production access is limited to the named people who operate the service.

If we determine that a security incident has affected your data, we will notify the account email without undue delay and in any event within 72 hours of confirming it, describing what we know, what we are doing, and what you should do.

We do not currently offer an availability commitment or a service level agreement, and we would rather say that plainly than publish a number we have not measured. If you need contractual uptime terms, talk to us before you buy.

If you find a security issue in Pentest Today itself, we want to hear about it. Email scott@manager.ai with enough detail to reproduce it. We aim to acknowledge a report within five business days and will keep you updated while we work on it.

We will not pursue legal action over good-faith research that follows these limits.

• Test only against your own account and your own data.
• Do not access, modify, or retain another customer's data. If you encounter it, stop and tell us.
• Do not run denial-of-service testing, spam, or social engineering against us or our staff.
• Give us a reasonable chance to fix the issue before you publish it.

We do not run a paid bug bounty at this time. We will credit you when a report leads to a fix, if you would like us to.

Security questions, and vulnerability reports, go to scott@manager.ai, addressed to Crucible Fund LLC.