Realistic security testing. Explicitly authorized.

Purpose of these Security Testing Terms

These terms establish baseline rules for authorized security assessments performed by ShabuShabu Security.

They are intended to define how active testing is separated from ordinary website use, independent vulnerability research and activity outside a client-authorized engagement.

A specific statement of work, written scope, order, authorization document or other engagement record may add to or modify these baseline rules for a particular assessment.

Authorization to perform security testing

ShabuShabu will perform active penetration testing only against systems that the client is authorized to submit for testing and that are included within the agreed engagement scope.

The client represents that it has sufficient authority to request testing of the identified systems or has obtained the permissions required from the relevant system owner.

Authorization applies only to the agreed testing period, systems, environments and activities. It does not automatically extend to other domains, companies, accounts, cloud resources or connected third-party services.

Engagement documents and scope

The final testing scope may be documented through a statement of work, testing authorization, project communication or another agreed record that clearly identifies the engagement.

Depending on the assessment, the engagement documentation may define:

• target domains, applications, APIs, IP ranges or environments;
• user roles and testing accounts;
• staging or production testing conditions;
• testing dates or an agreed testing window;
• approved techniques and known restrictions;
• third-party services that must remain outside scope;
• high-risk workflows requiring special handling;
• communication and escalation contacts;
• engagement-specific confidentiality or data-handling requirements.

In-scope systems

Only assets included in the approved engagement should be treated as intentional security-testing targets.

Depending on the agreed assessment, in-scope assets may include web applications, APIs, SaaS functionality, authentication systems, AI features, test accounts or other specifically identified technical components.

Where scope is defined by a domain, product or environment rather than an exhaustive endpoint list, the parties should still share a reasonable understanding of which infrastructure belongs to the authorized assessment.

Out-of-scope systems

Unless specifically authorized, ShabuShabu will not intentionally test systems that fall outside the approved engagement.

• unrelated third-party applications or infrastructure;
• customer or employee accounts not provided or approved for testing;
• external vendors discovered through integrations;
• unapproved cloud resources or separate business units;
• payment, identity or infrastructure providers outside the client’s authorization;
• systems explicitly identified as excluded from the engagement.

Test accounts, credentials and access

The client may provide dedicated test accounts, API credentials or other access necessary to evaluate authenticated functionality and different permission levels.

Where possible, testing credentials should be dedicated to the engagement rather than shared with ordinary production users.

Credentials provided for testing should be used only for the authorized assessment and handled in accordance with the applicable engagement and security requirements.

Permitted testing activities

Within the agreed scope, ShabuShabu may use manual security testing, technical inspection and supporting tools to identify and validate security weaknesses.

Depending on the engagement, testing may examine:

• authentication and account security controls;
• authorization and privilege boundaries;
• session and application state handling;
• web application and API behavior;
• business logic and workflow abuse;
• sensitive-data exposure;
• application integrations and trust boundaries;
• AI, LLM, agent and tool-permission boundaries where included in scope;
• controlled validation of vulnerability exploitability.

Supporting automation may be used, but assessment findings are evaluated in the context of the authorized product and practical security impact.

Restricted and destructive activities

Activities capable of creating significant operational, physical, financial or third-party impact are not assumed to be permitted merely because general penetration testing has been authorized.

Unless separately and explicitly approved, the assessment should not intentionally include:

• denial-of-service or deliberate service-exhaustion activity;
• intentional destruction or corruption of production data;
• large-scale extraction of real customer information;
• unapproved phishing, impersonation or social engineering;
• physical intrusion or physical-security testing;
• malware deployment or persistent unauthorized access;
• changes intended to cause lasting production disruption;
• testing against third-party systems outside the agreed authorization.

If a higher-risk technique is relevant to the assessment, the parties can establish explicit conditions before that activity occurs.

Production testing and operational safety

Where production testing is included in the authorized scope, ShabuShabu will seek to validate security impact while avoiding unnecessary disruption to legitimate users and business operations.

The client should identify particularly sensitive operations, irreversible transactions, fragile components and known technical limitations before active testing begins.

Testing in staging may reduce operational risk, but a staging assessment is not automatically equivalent to testing the production architecture if material differences exist between environments.

Stop conditions

ShabuShabu may pause or stop an activity when continuing the test would create unreasonable risk or move beyond the agreed authorization.

A pause may also be appropriate when a newly discovered issue materially changes the expected risk of continuing the assessment.

Testing can resume after the relevant condition is understood and any necessary scope or operational decision has been made.

Third-party services and infrastructure

Modern applications frequently rely on hosting, cloud platforms, authentication providers, payment systems, analytics, messaging services and other external infrastructure.

A client’s authorization does not automatically grant ShabuShabu permission to attack or disrupt those independent providers.

Where an assessment requires interaction with a third-party service, the testing approach may be limited to the client’s authorized use of that integration unless broader permission has been established.

Sensitive data and evidence handling

A security assessment may produce technical evidence containing application data, internal identifiers, request information, screenshots, logs or other sensitive material.

ShabuShabu should collect only the evidence reasonably necessary to validate and explain a security finding.

Where the assessment encounters real user data, the preferred approach is to minimize unnecessary access, copying and retention whenever practical.

Engagement-specific confidentiality or data-handling requirements may impose additional controls.

Security findings and reporting

Assessment reports are intended to describe validated weaknesses in a form that helps the client understand security impact and remediation.

Depending on the engagement and finding, reporting may include:

• a description of the affected security control;
• technical evidence supporting the finding;
• the affected application, endpoint, role or workflow;
• practical attack impact;
• relevant conditions required for exploitation;
• remediation guidance and defensive priorities;
• attack-chain context where multiple weaknesses interact.

Automated signals that cannot be meaningfully validated may be treated differently from confirmed security vulnerabilities.

High-impact findings during testing

If testing identifies a weakness that appears to create significant immediate security exposure, ShabuShabu may communicate the finding before completion of the final report.

The appropriate escalation method depends on the engagement, available contacts, operational context and nature of the finding.

No fixed notification SLA is created by this public page unless a specific engagement separately defines one.

Client responsibilities

A meaningful security assessment depends on accurate scope and operational information. The client should provide information reasonably necessary for ShabuShabu to understand the authorized testing boundary.

Client responsibilities may include:

• confirming authority over the systems submitted for testing;
• identifying relevant domains and environments accurately;
• providing appropriate test accounts where required;
• disclosing important production restrictions;
• identifying third-party systems that must remain outside scope;
• maintaining appropriate backups and operational safeguards;
• providing an appropriate contact for material security or operational issues.

AI and LLM security testing

Where AI or LLM functionality is included in the assessment, the scope should identify which model-driven capabilities, connected tools, data sources and application actions may be tested.

AI testing may evaluate prompt-injection resistance, context boundaries, retrieval behavior, agent permissions, tool access, sensitive-data handling and application controls surrounding model output.

Where an AI system can perform real-world actions, send communications, modify records, spend funds or invoke privileged external tools, the engagement may impose additional restrictions on how those capabilities are validated.

The presence of a model-generated action does not expand ShabuShabu’s authorization beyond the underlying engagement scope.

Remediation and retesting

Where retesting is included or separately agreed, ShabuShabu may reassess previously reported vulnerabilities after the client implements remediation.

The purpose of retesting is to determine whether the previously identified security condition or attack path remains reproducible.

A retest does not automatically constitute a new full penetration test of functionality that was not part of the original retest scope.

Limitations of a security assessment

Penetration testing provides a security assessment within a defined scope, technical environment and period of testing.

It should not be interpreted as a representation that a complex application or organization can never contain another vulnerability, particularly after software, architecture, configuration, dependencies or threat conditions change.

The value of the assessment is to identify meaningful weaknesses, improve security controls and reduce attack surface within the agreed engagement — not to issue an absolute guarantee of future security.

Scope changes, suspension and conflicting instructions

Either party may identify circumstances requiring testing to be paused while an authorization, safety or operational concern is clarified.

Material additions to scope should be agreed before active testing expands into the newly identified assets or activities.

If engagement-specific written terms conflict with these general public Security Testing Terms, the specific engagement documentation may control to the extent of that conflict.

Nothing on this public page establishes a fictional governing-law jurisdiction, dispute forum or other legal term that has not been separately agreed by the relevant parties.

Contact and related policies

Questions about a prospective authorized assessment can be submitted through the ShabuShabu Contact page.

Our Testing Methodology explains the assessment process from scope through remediation and retesting.

Independent researchers who believe they have already discovered a security issue affecting a ShabuShabu-operated system should use the Responsible Disclosure process rather than treating these client testing terms as an open authorization.