Research Scope

1. Scope Statement

PCL reviews security material that can be handled lawfully, safely, and usefully. This scope document defines report categories PCL may accept, activities PCL rejects, and conditions that require escalation.

This document is not a testing authorization. Testing authorization must come from the system owner or a party legally able to grant it.

2. In Scope for Review

PCL may review the following categories when the reporter has a lawful basis for the observation.

2.1. Ordinary Authorized-Use Findings

Findings discovered while using a product or service as an ordinary authorized user, without bypassing controls or accessing another person’s data.

Examples:

• broken authorization within the reporter’s own account boundary;
• insecure direct object references demonstrated only against reporter-controlled objects;
• improper exposure of reporter-owned data;
• missing tenant isolation demonstrated in an authorized test tenant;
• unsafe default behavior visible without additional probing.

2.2. Passive Exposure Findings

Findings based on passive observation of public material or lawfully obtained records.

Examples:

• exposed public configuration metadata;
• security-relevant headers or DNS records;
• public code repository exposure;
• leaked secrets discovered in public sources;
• public package or dependency metadata;
• published binaries or client-side code analysis.

2.3. Crash, Log, and Trace Analysis

Findings derived from crash reports, logs, diagnostic traces, build artifacts, or error messages that the reporter is authorized to possess.

Examples:

• local application crashes;
• memory-safety indicators from reporter-controlled environments;
• stack traces exposing sensitive paths or implementation details;
• deterministic failure modes in authorized test builds.

2.4. Coordinated or Authorized Research

Findings discovered under written authorization from a vendor, customer, open-source maintainer, bug bounty program, assessment contract, or formal disclosure policy.

The authorization must cover the target, time, methods, and evidence involved.

2.5. Design and Systemic Risk Analysis

Analysis of patterns, designs, configurations, or ecosystem practices that create security risk without requiring active exploitation of live third-party systems.

Examples:

• unsafe authentication patterns;
• insecure update or distribution models;
• weak cryptographic protocol use;
• supply-chain metadata inconsistencies;
• aggregate analysis of public vulnerability records.

3. Out of Scope for Review

PCL generally rejects or refuses to handle material that depends on:

• unauthorized access;
• unauthorized scanning, fuzzing, brute forcing, or probing;
• denial-of-service testing;
• exploit development;
• payload execution;
• privilege escalation against live third-party systems;
• persistence;
• malware;
• credential theft or credential reuse;
• social engineering;
• physical intrusion;
• bypassing controls to access third-party data;
• bulk collection of production data;
• public disclosure used as leverage;
• reports submitted primarily for publicity or pressure.

4. Conditional Scope

Some categories may be handled only under elevated review.

4.1. Critical Infrastructure and Safety-Impacting Systems

Reports affecting safety-critical, medical, industrial control, public-sector, transportation, energy, water, telecom, emergency services, or critical infrastructure systems require senior review before coordination or publication.

4.2. Multi-Party Vulnerabilities

Vulnerabilities affecting multiple vendors, open-source ecosystems, shared libraries, standards, or protocols may require coordination with a CERT, CNA, maintainer group, or other coordination body.

4.3. AI and Model-System Findings

Reports involving AI systems require clear security impact. PCL may consider data exposure, authorization bypass, model extraction, insecure tool invocation, supply-chain compromise, sensitive prompt leakage, or cross-tenant isolation issues. Generic jailbreaks, hallucinations, undesirable outputs, or policy bypass demonstrations without a concrete security impact are usually out of scope.

4.4. Vulnerability Notification at Scale

Large-scale notification based on internet measurement, public datasets, or passive scans requires separate review. Notification can create operational and privacy risk even when the underlying data is public.

5. Evidence Boundary

The evidence boundary is reached when the reporter can demonstrate:

• the issue exists;
• the affected component is identified;
• the security consequence is plausible and specific;
• further proof would require additional access, exploitation, disruption, or sensitive-data exposure.

At that point, stop and report.

6. Examples of Acceptable vs Unacceptable Proof

Claim	Acceptable proof	Unacceptable proof
Object authorization flaw	Demonstration using two reporter-controlled accounts	Accessing another user’s private object
Exposed secret in public repo	Commit URL, redacted secret type, timestamp	Using the secret against production
Crash in local parser	Reproducer against local test file without exploit payload	Weaponized exploit chain or live target crash
Sensitive error disclosure	Redacted screenshot and response metadata	Enumerating many errors to collect hostnames
Misconfigured storage bucket	Public listing metadata and owner notification	Bulk downloading contents

7. Scope Escalation

Escalate before proceeding when:

• authorization is unclear;
• sensitive data appears;
• testing could impair availability;
• affected systems include third-party tenants;
• exploit development would be needed;
• the issue affects safety or critical services;
• the reporter wants public disclosure before coordination;
• the vendor is unresponsive and user risk remains material.

8. Boundary with PCL-Owned Systems

PCL may define a separate vulnerability disclosure scope for systems it owns or controls. Unless such a scope is explicitly published and current, no PCL system should be treated as authorized for active testing.

The presence of this website, a security.txt file, or a contact address does not authorize scanning, exploitation, account abuse, or service degradation.