Sentinel

Safe harbor

The authorization baseline for good-faith research on Sentinel, the activities that are always prohibited, and what voids protection.

Last updated 18 Sep 2026 · 18 days ago

Safe harbor is a program's promise to treat good-faith research as authorized activity rather than as an attack. This page is the baseline for every program in the directory.

What the baseline says

When you test an in-scope asset in good faith and within the program's policy, the program agrees to:

  • Treat your testing as authorized access under applicable computer misuse and anti-circumvention law, and as authorized under its own terms of service.
  • Not pursue civil or criminal action against you for that testing, and not ask a third party to do so.
  • If a third party brings action against you for research the program authorized, make it known that your activity was authorized.
  • Work with you on timing, under the 90 day default in the disclosure policy.

Safe harbor covers researching and reporting. It does not license what you do with the findings afterwards, and it does not waive obligations you owe your employer.

What good faith means

Good faith is judged by behavior, not by intent claimed afterwards. It means you:

  • Stay inside the published scope, and stop when an asset turns out not to be listed.
  • Access only the minimum data needed to prove the bug exists, then stop.
  • Avoid degrading service for real users, and back off the moment you notice you are.
  • Report promptly, usually within 72 hours of confirming a finding.
  • Keep the finding confidential until the disclosure timeline allows publication.
  • Delete data you retrieved, and say in the report what you retrieved and when you deleted it.

Always prohibited

These are out of bounds on every program, regardless of scope:

  • Denial of service. Volumetric attacks, application-layer floods, resource exhaustion, or any test whose success is measured in downtime. This includes load-testing to "confirm" a suspected DoS.
  • Social engineering. Phishing, pretexting, or vishing aimed at staff, contractors, support agents, or other users. Support chat is not an attack surface.
  • Physical intrusion. Offices, data centres, tailgating, badge cloning, dumpster diving.
  • Accessing data beyond proof. One record from your own test tenant proves an access-control bug. Enumerating a thousand does not prove it harder, it makes you a breach.
  • Persistence. Web shells, scheduled jobs, added credentials, backdoored dependencies, or any change that outlives your session.
  • Destruction or modification of data you do not own, including deletions "to test" a delete endpoint.
  • Third-party services. Vendor, CDN, payment processor and partner assets are not in scope even when the product depends on them.
  • Trading the finding. Selling, leaking, or offering the vulnerability to anyone other than the program and Sentinel.

If you access sensitive data by accident

It happens, usually one response body further than you expected. Do this, in order:

  1. Stop immediately. Do not repeat the request, and do not page through more records to measure the extent.
  2. Do not download, copy, or forward the data. If it is already on disk, keep it local.
  3. Report within 24 hours, and mark the report Contains sensitive data so it routes to a restricted triage queue.
  4. Describe, do not attach. Say "the response contained full names, emails and partial card numbers for about 12 accounts". Do not paste records.
  5. Delete your copies once the program confirms it has what it needs, and state the deletion date in the thread.

Reporting an accidental access this way does not void safe harbor. Concealing it does.

What voids safe harbor

  • Testing an asset you knew, or should have known, was out of scope.
  • Continuing after a program asks you to stop, or after your access was revoked.
  • Exfiltrating, retaining, or publishing user data.
  • Extortion, or any message that conditions the report on payment.
  • Publishing before the disclosure window closes without written agreement.
  • Using the access for anything other than proving the bug, including competitive research.
  • Misrepresenting findings, staging a bug you introduced, or submitting another researcher's work as your own.
  • Any of the always-prohibited activities above.

Sentinel may remove safe harbor for a specific report, and may suspend an account, when one of these applies. The decision is written into the report thread, and you may contest it through mediation.

Each program's policy governs

This baseline is a floor. A program may grant more, for example by extending safe harbor to a staging environment. It may also be stricter, for example by forbidding automated scanning or narrowing which data may be touched. Where the program policy and this page conflict, the program policy applies. Where the policy is silent, this page applies.

Read the program's text before testing. See getting started for the order of operations and report quality for documenting cleanup.