27.2.2. Service Contract Template

While the Engagement Letter (27.2.1) acts as a formal handshake, the Service Contract or Master Service Agreement (MSA) is the legally binding foundation of your engagement. It codifies the terms, responsibilities, and limitations that protect both you (the Provider) and the Client. This chapter provides a template structure, annotated with expert commentary to highlight clauses critical for AI red teaming.

Disclaimer: This is an educational template, not legal advice. Always have your contracts reviewed by qualified legal counsel.

The Hierarchy of Engagement Documents

Before diving into the template, it’s crucial to understand how the service contract fits with other key documents. They form a hierarchy of specificity, from general legal terms to detailed technical instructions.

The Service Contract sets the overarching legal terms. The Statement of Work (SoW), often an appendix to the contract, details the specific technical scope for *this* particular AI red team engagement. The contract should state that in case of conflict, the SoW’s technical specifications prevail, but the contract’s legal terms govern all else.

Annotated Service Contract Template

Below is a skeletal structure for a service contract. Pay close attention to the explanation boxes, which translate the “legalese” into practical considerations for your red team operations.

AI SECURITY ASSESSMENT SERVICE AGREEMENT

This Service Agreement (“Agreement”) is made and entered into as of [Date] (“Effective Date”), by and between:

Client: [Client Name], with its principal place of business at [Client Address].
Provider: [Provider Name], with its principal place of business at [Provider Address].

1. SERVICES AND SCOPE OF WORK

1.1. Services. Provider agrees to perform the AI security assessment services (“Services”) as described in the Statement of Work (“SoW”), attached hereto as Exhibit A and incorporated herein by reference.

1.2. Changes to SoW. Any changes to the SoW must be mutually agreed upon in writing by both Parties through a formal Change Order document.

Expert Insight: Your SoW is your shield. Never start work without a signed SoW. For AI engagements, it must explicitly define:

The specific model(s) and version(s) in scope (e.g., `gpt-4-turbo-2024-04-09`, internal model `ProjectX-v3.2`).
The target APIs, endpoints, and interfaces.
Permitted attack classes (e.g., prompt injection, model inversion, data poisoning simulation).
Out-of-scope systems (e.g., underlying cloud infrastructure, corporate networks).
Access methods (e.g., API keys, direct model access, access to a sandboxed training environment).

2. CLIENT OBLIGATIONS & AUTHORIZATION

2.1. Authorization. Client represents and warrants that it has full right and authority to authorize Provider to perform the Services on the systems, models, and data specified in the SoW (“Target Systems”).

2.2. Access. Client shall provide Provider with timely access to necessary information, personnel, and Target Systems as required to perform the Services.

Expert Insight: Clause 2.1 is your “Get Out of Jail Free” card. It confirms you have legal permission to conduct what would otherwise be illegal activities. Ensure the person signing has the authority to grant this permission (e.g., CISO, CTO, Head of AI). If you are testing a third-party model via an API (e.g., OpenAI, Anthropic), this clause needs to be adapted to confirm the Client’s use of that API is consistent with the vendor’s terms of service for security testing.

3. CONFIDENTIALITY

3.1. Definition. “Confidential Information” includes, but is not limited to, all information disclosed by one Party to the other concerning the Disclosing Party’s business, technology, model architectures, training data, vulnerabilities, and the results of the Services.

3.2. Obligation. The Receiving Party shall hold in strict confidence and shall not disclose any Confidential Information of the Disclosing Party. The results of the assessment are the Confidential Information of the Client.

Expert Insight: The vulnerabilities you find in an AI model are extremely sensitive intellectual property for the client. Your confidentiality obligations must be ironclad. This section protects the client’s trade secrets and protects you from accusations of leaking information.

4. INTELLECTUAL PROPERTY

4.1. Client Property. All materials provided by Client and all deliverables, including the final assessment report (“Deliverables”), shall be the sole and exclusive property of the Client.

4.2. Provider Property. Notwithstanding the foregoing, Provider shall retain all rights, title, and interest in and to its pre-existing materials, including its proprietary tools, methodologies, scripts, and techniques used to perform the Services (“Provider Tools”). Provider grants Client a non-exclusive, perpetual, royalty-free license to use any Provider Tools incorporated into the Deliverables for its internal business purposes.

Expert Insight: This is a critical distinction. The client owns the *report* (the output), but you own your *methods* (how you produced it). This allows you to reuse your custom prompt injection libraries, model analysis scripts, and attack frameworks for other clients without restriction.

5. LIMITATION OF LIABILITY & INDEMNIFICATION

5.1. Disclaimer of Damages. In no event shall either party be liable for any indirect, incidental, special, or consequential damages arising out of this Agreement. Provider’s services are provided “as-is” and do not constitute a guarantee that all vulnerabilities will be found.

5.2. Liability Cap. Provider’s total liability under this Agreement shall not exceed the total fees paid by the Client to the Provider under the applicable SoW.

5.3. Indemnification. Client shall indemnify, defend, and hold harmless Provider from and against any and all third-party claims, liabilities, and expenses arising from the performance of the Services, provided Provider acted within the agreed-upon SoW and Rules of Engagement.

Expert Insight: Security testing carries inherent risk. A test could inadvertently cause a performance degradation or expose unexpected data.

Liability Cap (5.2): This prevents a situation where a minor issue during a $50,000 engagement could lead to a multi-million dollar lawsuit. Capping liability to the fees paid is a standard industry practice.
Indemnification (5.3): This protects you if your authorized testing activities trigger an alert from a third party (e.g., a cloud provider like AWS or a model provider like OpenAI) and they pursue legal action against you. The client essentially vouches for your actions.

6. GENERAL PROVISIONS

6.1. Governing Law. This Agreement shall be governed by the laws of the State of [State/Country].

6.2. Entire Agreement. This Agreement, including all Exhibits, constitutes the entire agreement between the Parties and supersedes all prior communications and understandings.

Key Clauses Summary Table

Here is a quick reference table translating the purpose of these critical clauses.

Clause	Purpose for the Red Team	What to Watch Out For
Scope of Work (SoW)	Clearly defines your playground and objectives. Prevents scope creep.	Vague definitions of “the AI model.” Insist on specific versions and endpoints.
Authorization	Your legal permission to conduct testing. Your “Get Out of Jail Free” card.	Signatory who lacks the proper authority within the client’s organization.
Provider IP	Ensures you retain ownership of your tools and methodologies for future use.	Clauses that grant the client ownership of your tools or “all IP created during the engagement.”
Limitation of Liability	Caps your financial risk if something goes wrong during testing.	Absence of a cap, or a cap that is unreasonably high (e.g., tied to client’s potential damages).
Indemnification	Client protects you from third-party lawsuits resulting from your authorized work.	One-sided indemnification where you must indemnify the client for everything. It should be mutual or client-to-provider.

Do you have a question about AI Security? Reach out to us here: