Assessment Terms Addendum

Effective Date: [EFFECTIVE_DATE]
Version: v1.0
Client: [CLIENT_LEGAL_NAME]
Provider: aisecurity.llc
Master Agreement: [MASTER_AGREEMENT_NAME]
Assessment Type: [AI_PRODUCT_SECURITY_ASSESSMENT / AGENTIC_WORKFLOW_HARDENING / ENTERPRISE_REVIEW_PACK]

1. Purpose

1.1 This Assessment Terms Addendum ("Addendum") supplements the Master Agreement and governs any scoped AI product security assessment, agentic workflow review, enterprise review pack, or related advisory engagement performed by Provider.

1.2 This Addendum is intended to keep assessment work explicit: what is authorized, what evidence may be collected, how findings are handled, and what the client may rely on. It does not create a certification, compliance guarantee, or audit opinion.

1.3 If this Addendum conflicts with a Statement of Work, the more specific assessment scope controls for the applicable engagement, provided the conflict does not reduce mandatory confidentiality, data handling, or safety protections in the Master Agreement.

2. Assessment Objectives

2.1 The assessment may include one or more of the following objectives:

• identify attack paths, abuse cases, and control gaps in LLM, RAG, agentic, or other AI-enabled systems;
• map data, prompt, retrieval, tool-use, and model boundaries;
• review evidence quality for enterprise scrutiny;
• produce a prioritized remediation backlog; and
• support buyer-facing security review, governance, or procurement readiness.

2.2 Provider will describe the exact objective set in the applicable Statement of Work or kickoff memo.

3. Authorization and Testing Boundaries

3.1 Client authorizes Provider to perform only the specific activities listed in the applicable Statement of Work, Rules of Engagement, or written amendment.

3.2 Unless expressly authorized in writing, Provider will not:

1. attempt destructive testing;
2. execute denial-of-service testing against production;
3. access data outside the defined scope;
4. exfiltrate production data except the minimum necessary to document a finding;
5. persist access, backdoors, or credentials; or
6. test third-party systems not expressly covered by written authorization.

3.3 If Provider encounters a condition that suggests the assessment should expand beyond the written scope, Provider will pause and request written approval before proceeding.

4. Evidence Use

4.1 Provider may collect only the minimum evidence reasonably necessary to document findings, support remediation, and preserve the integrity of the engagement record.

4.2 Evidence may include screenshots, request/response traces, logs, configuration snapshots, prompt traces, control maps, architecture notes, and short excerpts of relevant artifacts.

4.3 Provider will not publish raw client data, raw job-description corpora, raw survey answers, private keys, tokens, or other sensitive material in public deliverables.

4.4 If Provider needs to retain sensitive evidence longer than the engagement, Provider will follow the retention and redaction rules in the applicable Master Agreement, Schedule, or this Addendum.

5. Findings and Reporting

5.1 Findings are delivered as directional security engineering evidence, not as a guarantee that every issue has been identified.

5.2 Provider may assign severity or priority based on technical impact, exploitability, business context, and exposure. Those ratings are advisory, not a certification label.

5.3 Client may request factual corrections to the report. A factual correction request may not be used to suppress a valid finding, but it may be used to correct scope, terminology, architecture details, or evidence interpretation.

5.4 Provider will label any public-safe summary as claim-ready only where the supporting evidence and publication controls are sufficient for external use.

6. Retest and Verification

6.1 Unless otherwise specified in the Statement of Work, one follow-up verification pass may be included for the highest-priority findings if remediation evidence is provided within the agreed review window.

6.2 Retest is limited to validating whether the specific issue has been remediated. Retest is not a full re-assessment of the system unless separately scoped.

6.3 If the remediation changes system architecture, authentication boundaries, data flow, or authorization model, Provider may require an updated scope before retesting.

7. Client Responsibilities

7.1 Client will identify a primary technical contact and a security contact for rapid coordination during the assessment.

7.2 Client will provide timely access to the systems, documents, and environment(s) identified in the scope.

7.3 Client is responsible for ensuring that any third-party approvals required for the assessment have been obtained before testing begins.

7.4 Client will promptly notify Provider of any systems, data classes, or business periods that are off-limits.

8. No Certification or Warranty

8.1 Provider does not certify that Client is secure, compliant, or free of vulnerabilities.

8.2 Provider does not guarantee that all issues will be found, that all controls are effective, or that all findings will be exploitable in the same way in production.

8.3 Provider's assessment outputs are time-bound and reflect the state of the environment at the time of analysis.

9. Publication and Disclosure

9.1 Provider may reference the engagement in aggregate, anonymized, or public-safe form only in accordance with the publication and claim-readiness rules applicable to the engagement.

9.2 Client may not publicly quote or market the results of the assessment without prior written approval of the specific language and context.

9.3 Any sponsor or partner relationship is separate from the assessment and does not change methodology, findings, or conclusions.

10. Term

10.1 This Addendum remains in effect for the duration of the applicable assessment and survives as necessary for confidentiality, evidence handling, and dispute resolution.

11. Signature Blocks

Client: [CLIENT_LEGAL_NAME]

Signature: _______________________________

Name: [CLIENT_AUTHORIZED_SIGNATORY_NAME]

Title: [CLIENT_AUTHORIZED_SIGNATORY_TITLE]

Date: _______________________________

Provider: aisecurity.llc

Signature: _______________________________

Name: David Wolf

Title: Principal

Date: _______________________________