Rules of Engagement

1. Control Status

This document is binding for any person acting as, presenting as, or using resources provided for a PunchCard Labs activity. It applies regardless of title, seniority, contributor status, or prior involvement in a case.

The rules are intentionally conservative. PCL exists to reduce risk created by independent security research, not to increase it. Where this document conflicts with convenience, speed, curiosity, or perceived technical importance, this document controls.

1.1. Authority Model

PCL may set rules for PCL-affiliated activity. PCL cannot authorize testing of third-party systems unless the responsible owner has granted that authority in a valid written instrument, contract, bounty scope, vulnerability disclosure policy, or direct written approval.

A PCL process decision is not legal advice, not indemnification, not vendor authorization, and not permission to exceed the authority granted by a system owner.

1.2. Core Rule

Do not create new risk to prove existing risk.

A finding is not improved by unnecessary exploitation, unnecessary data access, operational disruption, or escalation beyond the minimum evidence needed for defensive review.

2. Definitions

Affiliated activity means research, triage, drafting, coordination, evidence review, infrastructure operation, or public communication conducted under PCL identity, using PCL resources, or reasonably likely to be interpreted as PCL activity.

Authorization means explicit permission from the system owner or responsible party to perform the relevant activity against the relevant target, during the relevant time, using the relevant methods.

Ordinary authorized use means interaction available to the researcher as a normal user without bypassing access controls, abusing trust boundaries, evading rate limits, defeating controls, or touching data outside the researcher’s own account or authorized test context.

Exploit development means creating, modifying, chaining, packaging, or automating code or instructions whose practical purpose is unauthorized access, code execution, privilege escalation, lateral movement, persistence, credential compromise, data exfiltration, or service disruption.

Evidence means the minimum technical material necessary to validate the existence, affected surface, severity, and remediation status of a reported issue.

Sensitive data includes credentials, secrets, tokens, keys, private source code, personal data, customer data, medical or financial records, communications content, proprietary operational details, live exploit material, and any non-public information not necessary for defensive triage.

Data Review Board (DRB) means the internal review function responsible for deciding whether evidence may be retained, shared, escalated, or published.

3. Operating Principles

PCL-affiliated researchers must apply the following principles before, during, and after all research activity.

1. Authorization first. Technical feasibility does not imply permission.
2. Minimization by default. Collect the least evidence that can support a defensible claim.
3. No weaponization. Demonstrate impact without exploit-ready payloads, persistence, automation, or adversary-ready reproduction chains.
4. Stop at sensitive data. If sensitive data is encountered, stop the activity, preserve only what is necessary to report the exposure, and notify the responsible review channel.
5. Coordination before publication. Public benefit comes from accurate remediation information, not surprise disclosure.
6. Professional neutrality. Communications must be factual, restrained, and free of threats, pressure tactics, shaming, or public spectacle.
7. Traceable decisions. Significant scope, evidence, disclosure, or publication decisions must be documented.

4. Authorization and Scope

4.1. Required Authorization

Researchers may interact only with systems they are explicitly authorized to test or systems they can lawfully use as ordinary users within the exact access context granted to them.

Authorization must be evaluated against all of the following:

• system or asset identity;
• target environment;
• permitted methods;
• time window;
• rate limits;
• account type;
• data boundaries;
• disclosure channel;
• third-party service dependencies;
• terms of service or program rules.

If any element is unclear, the activity is not approved until clarified.

4.2. No Assumption of Permission

The following do not create authorization:

• absence of a robots.txt disallow rule;
• lack of a warning banner;
• public internet exposure;
• a vendor’s security.txt file;
• a bug bounty program that does not list the target;
• a broad marketing claim about security;
• prior acceptance of unrelated reports;
• public exploitability;
• a belief that the issue is severe;
• PCL internal interest in the target.

4.3. Third-Party Services

Managed services, SaaS platforms, cloud infrastructure, CDNs, identity providers, payment processors, email providers, analytics providers, and customer-owned tenant environments are out of bounds unless their responsible party has granted applicable authorization.

A customer’s permission to test its own tenant does not automatically authorize testing the provider’s platform, shared control plane, other tenants, or underlying infrastructure.

4.4. Ambiguity Rule

When scope is ambiguous, stop. Seek clarification before further testing, reproduction, vendor contact, or public discussion.

Ambiguity is not a tactical opportunity. It is a control condition.

5. Prohibited Activities

The following activities are prohibited when acting within, adjacent to, or in connection with PCL.

5.1. Exploit Development and Weaponization

Researchers must not create, modify, test, publish, or distribute:

• weaponized proof-of-concepts;
• exploit frameworks or exploit modules;
• payloads intended for code execution, privilege escalation, persistence, credential access, or lateral movement;
• automated scanners tailored to exploit a live issue;
• bypass chains that materially increase offensive utility;
• scripts that access, export, transform, or enumerate unauthorized data;
• instructions that convert a public advisory into an operational attack guide.

Minimal non-weaponized reproduction context may be allowed only when it is necessary for defensive validation and approved for the specific case.

5.2. Availability Impact

Researchers must not perform activity likely to impair availability, integrity, or normal operation, including:

• denial-of-service testing;
• resource exhaustion;
• destructive fuzzing against production;
• queue flooding;
• aggressive crawling;
• brute force or password spraying;
• high-volume registration, login, or API traffic;
• triggering crash loops;
• altering production configuration;
• disrupting support, monitoring, billing, or incident response systems.

5.3. Access Control Bypass

Researchers must not bypass, defeat, evade, or weaken access controls except inside a specifically authorized test environment where the activity is expressly permitted.

Prohibited conduct includes session theft, token reuse, insecure direct object reference exploitation against real accounts, privilege escalation, MFA bypass, authorization-header manipulation beyond a controlled test account boundary, and any attempt to access another person’s data.

5.4. Data Access and Exfiltration

Researchers must not access, copy, retain, transmit, or disclose sensitive data beyond the minimum necessary to identify the exposure and support defensive review.

If sensitive data appears during ordinary observation, do not expand the view, enumerate additional records, download bulk data, search for more examples, or prove scale by collecting more data. Record the exposure at the lowest safe resolution, redact where possible, and stop.

5.5. Social, Physical, and Human-Targeting Activity

PCL-affiliated activity excludes:

• phishing;
• vishing;
• smishing;
• pretexting;
• employee impersonation;
• physical intrusion;
• tailgating;
• badge testing;
• device drops;
• coercion;
• intimidation;
• harassment;
• public pressure campaigns designed to force response.

5.6. Persistence, Concealment, and Evasion

Researchers must not establish persistence, hide activity, evade detection, modify logs, impair monitoring, alter evidence, deploy implants, or perform actions intended to simulate an adversary inside a live third-party system without explicit written authorization.

5.7. Unauthorized Representation

Researchers must not use PCL identity, branding, email, infrastructure, letterhead, signatures, titles, or implied affiliation unless the use has been approved for that specific context.

Independent personal research must not imply PCL endorsement, authorization, review, backing, or responsibility.

6. Evidence Collection Standard

6.1. Evidence Sufficiency

Evidence should establish:

• the affected system or component;
• the relevant version, configuration, endpoint, or build when known;
• the observed behavior;
• why the behavior creates security impact;
• the authorization basis for the observation;
• whether sensitive data was encountered;
• what was done after the issue was identified.

Evidence is sufficient when a qualified reviewer can understand the claim without needing the researcher to perform additional unauthorized activity.

6.2. Preferred Evidence Forms

Preferred evidence includes:

1. vendor-confirmed statements;
2. redacted logs;
3. crash traces or stack summaries;
4. screenshots with sensitive content removed;
5. configuration excerpts with secrets removed;
6. request and response metadata without credentials or live tokens;
7. synthetic reproduction examples;
8. hashes, counts, timestamps, and file names where content is unnecessary;
9. public documentation references;
10. source excerpts only where publication is lawful, authorized, and necessary.

6.3. Evidence That Requires DRB Approval

DRB approval is required before retaining, transmitting, or publishing evidence containing:

• credentials, tokens, keys, cookies, or session identifiers;
• personal data or customer data;
• proprietary non-public source code;
• production database content;
• internal hostnames, IP ranges, architecture diagrams, or control-plane details;
• vendor-sensitive remediation timelines;
• exploit-like reproduction steps;
• material that could reasonably increase exploitation risk.

6.4. Evidence Storage

Sensitive evidence must be segregated from public repository content. The public web repository must contain only material intended for publication.

Do not commit raw case evidence, drafts containing secrets, unredacted screenshots, vendor correspondence, private keys, raw scan output, ticket exports, or internal review notes to the public site repository.

7. Intake, Triage, and Internal Handling

7.1. Initial Classification

Every report handled under PCL must be classified for:

• authorization basis;
• affected party;
• sensitive-data exposure;
• operational risk;
• likely severity;
• coordination complexity;
• publication eligibility;
• required review authority.

7.2. Stop Conditions

Research or handling must stop and escalate when:

• sensitive data is encountered;
• exploitation would be needed to proceed;
• the target appears out of scope;
• authorization is unclear;
• a third party could be harmed;
• public disclosure pressure is being considered;
• a vendor requests a legal or coordination hold;
• law enforcement, regulator, or CERT coordination may be appropriate;
• the issue affects safety-critical, medical, operational technology, public-sector, or critical-infrastructure systems.

7.3. Case Notes

Case notes should record decisions, not performative narrative. At minimum, record:

• date and time;
• decision maker;
• action taken;
• reason;
• evidence reference;
• next review point;
• open risks or assumptions.

8. Vendor and Maintainer Contact

8.1. Approval before Contact

Researchers may not contact vendors, maintainers, project owners, customers, regulators, press, or third-party coordinators as PCL representatives unless authorized for the specific disclosure.

8.2. Communication Style

External communications must be:

• factual;
• concise;
• reproducible enough for defense;
• free of threats, ultimatums, insults, mockery, hype, or public-pressure language;
• clear about what is known, what is suspected, and what remains unvalidated.

8.3. Avoiding Legal Escalation

Do not use language that implies extortion, coercion, ransom, unauthorized access, continued testing, or conditional silence. Do not suggest that remediation, bounty payment, employment, credit, or acknowledgment is required to prevent disclosure.

9. Public Disclosure and Publication

9.1. Disclosure Prerequisites

A PCL public advisory, report, dataset, or example must not be published until the following are reviewed:

• authorization basis;
• vendor or maintainer awareness;
• sensitive-data removal;
• exploitability of published details;
• remediation or mitigation status;
• affected-version accuracy;
• severity rationale;
• coordination timeline;
• legal, ethical, and safety concerns.

9.2. Publication Content Limits

Public materials should not include:

• weaponized exploit code;
• live credentials, tokens, keys, or secrets;
• private customer data;
• unnecessary target-specific infrastructure details;
• bypass chains not needed for defensive understanding;
• social engineering scripts;
• reproduction steps that materially lower the skill threshold for active exploitation before remediation is broadly available.

9.3. Credit and Attribution

Credit is discretionary and must not expose a reporter, researcher, vendor, user, or affected organization without appropriate consent or public basis.

If a reporter requests anonymity, PCL should honor that request unless legal obligations require otherwise.

10. Severity and Prioritization

Severity is not determined by novelty, personal interest, or public attention. Severity must be based on technical impact, affected population, exposure, exploitability, remediation availability, evidence confidence, and whether active exploitation is known.

PCL may reference CVSS, EPSS, KEV status, vendor severity, public exploit status, asset criticality, and contextual risk. These inputs are aids, not substitutes for judgment.

When severity is uncertain, publish uncertainty rather than inflate confidence.

11. External Conduct

PCL evaluates conduct to the extent it reflects judgment, restraint, authorization discipline, evidence handling, and suitability to represent a security lab.

Conduct outside formal PCL activity may affect affiliation when it demonstrates:

• unauthorized testing;
• exploit development;
• data exfiltration;
• reckless public disclosure;
• harassment or threats;
• vendor intimidation;
• deliberate misrepresentation;
• disregard for legal or ethical boundaries;
• actions that materially increase risk to users, vendors, researchers, or PCL.

12. Violation Classes

12.1. Low Severity

Low-severity violations are correctable process failures that do not materially increase third-party risk. Examples include incomplete case notes, minor metadata omissions, missed internal formatting requirements, or late status updates.

Expected response:

• documented correction;
• mentoring or process review;
• no publication until corrected;
• escalation only if repeated.

12.2. Medium Severity

Medium-severity violations create avoidable risk, show poor judgment, or repeat prior low-severity failures. Examples include premature vendor contact, weak evidence minimization, unapproved use of PCL identity, inadequate redaction, or avoidable scope ambiguity.

Expected response may include:

• temporary suspension from case work;
• mandatory review before external communication;
• removal from sensitive evidence access;
• retraining;
• DRB review.

12.3. High Severity

High-severity violations materially increase risk or breach core boundaries. Examples include unauthorized exploitation, exploit development, data exfiltration, public disclosure before coordination, intimidation, evidence tampering, knowingly false claims, or access-control bypass outside explicit authorization.

Expected response may include:

• immediate suspension;
• removal of affiliation;
• revocation of access;
• preservation of records;
• notification to affected parties where appropriate;
• legal or regulatory escalation where required.

13. Appeals and Review

A researcher may request review of a violation classification unless immediate action is needed to prevent harm, preserve evidence, comply with law, or protect third parties.

Appeals should address facts, authorization, evidence, and proportionality. Appeals should not relitigate whether convenience, curiosity, or perceived importance justified boundary violations.

14. Amendments

These rules may be updated as PCL’s operating model, legal context, or publication process changes. The current version controls future affiliated activity. Prior conduct may be evaluated under the version in effect at the time, with current standards used as guidance for ongoing access and affiliation decisions.

Authorization Boundary

Only the responsible system owner can authorize testing of a third-party system. PCL review, coordination, or publication does not create or expand that authorization.