Cloud Testing Boundary Addendum

1. Purpose

This addendum bounds testing of cloud and infrastructure assets for engagement the engagement agreed during scoping under the applicable Statement of Work. It applies where the scope includes the cloud provider identified during scoping (e.g., AWS) accounts, networks, or services.

Cloud testing is divided into three categories that are treated differently:

• Active testing targets — assets the Client owns or controls that may be actively exercised within safe limits.
• Configuration / passive review targets — assets reviewed read-only for misconfiguration, never actively attacked.
• Provider infrastructure — shared platform infrastructure that is never an active target and may be subject to separate provider rules.

2. Account and Region Scope

3. Active Testing Targets

The following customer-owned cloud assets may be actively tested within safe limits:

• The customer-owned cloud assets enumerated and confirmed in writing during scoping (e.g., public endpoints, load balancers, application hosts).
• No shared provider infrastructure and no asset outside that confirmed list is an active target.

Active testing excludes any action that would degrade availability for other tenants or for production users outside the agreed window.

4. Configuration / Passive Review Targets

The following assets are reviewed by configuration and read-only inspection only — they are not actively attacked:

• IAM, network, storage, logging, and service configurations reviewed read-only for misconfiguration.
• Reviewed using Client-provided read access (e.g., CloudTrail, AWS Config, Security Hub, GuardDuty) rather than intrusive testing.

Where available, the Client provides read access (for example CloudTrail, AWS Config, Security Hub, GuardDuty, or a SecurityAudit role) so the review can be evidence-based rather than intrusive.

5. Provider Infrastructure and Provider Rules

• Shared provider infrastructure (the control plane, managed-service backplanes, and other tenants) is never an active target.
• The Client is responsible for confirming that testing is permitted under the applicable provider terms and for completing any required provider notification or approval before active testing begins.
• Activities that require separate provider approval (for example denial-of-service or stress testing) are governed by the Special Approval Addendum and are excluded until separately authorized.

6. Boundaries and Prohibited Actions

• Accessing, modifying, exfiltrating, or destroying production data not in the authorized targets
• Attacking systems, endpoints, or accounts not in the authorized targets
• Social engineering of Client personnel unless separately authorized
• Denial of service or load testing unless separately authorized
• Introducing persistent artifacts (backdoors, modified prompts) into any environment
• Sharing test artifacts, prompts, or findings outside the named delivery contacts
• Publishing or referencing Client systems or findings without written consent

In addition, Provider will not pivot from an in-scope cloud asset into systems, accounts, or networks not listed in the authorized targets, and will not access customer data beyond the minimum necessary to demonstrate a finding.

7. Evidence and Escalation

• Cloud findings are documented with the specific account, region, and resource identifiers, and with secrets and sensitive values masked.
• Evidence handling, retention, and deletion follow the Rules of Engagement and the Evidence Handling Policy.
• Emergency stop and escalation follow the Rules of Engagement.

8. Signatures

Client:

Signature: ______________________________ Name: ______________________________ Date: ____________

Provider (aisecurity.llc):

Signature: ______________________________ Name: David Wolf Title: Principal Date: ____________

These materials are provided for transparency and scoping. They are not legal advice and do not replace a final signed agreement. Consult qualified legal counsel before execution.