aisecurity.llc — legal document
Security Operations Schedule
Operational control schedule covering access, logging, incident handling, and evidence retention.
Purpose
1.1 This Security Operations Schedule ("Schedule") supplements [MASTER_AGREEMENT_NAME] (the "Master Agreement") and governs the operational security controls, access management practices, logging commitments, incident handling procedures, scope boundaries, and evidence retention obligations that aisecurity.llc ("Provider") maintains when performing services that involve access to [CLIENT_LEGAL_NAME]'s ("Client") systems, data, credentials, environments, or materials.
1.2 This Schedule applies to any engagement under the Master Agreement where Provider is granted access to Client systems, networks, APIs, models, agents, datasets, or credential material, or where Provider performs active security testing, assessment, or advisory work.
1.3 Controls described in this Schedule are proportional to the sensitivity of the data accessed and the nature of the authorized scope. Provider will apply heightened controls where the potential impact of a control failure is greater.
Definitions
2.1 "Authorized Scope" means the systems, environments, models, datasets, domains, APIs, endpoints, agents, accounts, and third-party integrations expressly listed in the applicable Statement of Work, testing authorization, or written amendment. Nothing outside the Authorized Scope is in scope.
2.2 "Client Credentials" means usernames, passwords, API keys, OAuth tokens, certificates, private keys, secrets, service accounts, and other access artifacts provided by or provisioned on behalf of Client.
2.3 "Security Event" means an actual or suspected unauthorized access, credential misuse, data exfiltration, integrity compromise, service disruption, or other incident affecting Client assets or data, whether caused by Provider, a third party, or unknown means.
2.4 "Evidence" means logs, screenshots, API call records, script outputs, configuration snapshots, testing artifacts, notes, vulnerability proof-of-concept materials, and other work products produced in connection with Authorized Services.
2.5 "Retention Period" means [DEFAULT_EVIDENCE_RETENTION_DAYS] days following completion or termination of the applicable engagement, unless extended by Client request, applicable law, legal hold, or active dispute.
2.6 "Critical Finding" means a vulnerability or security deficiency with a CVSS base score of 9.0 or higher, or that in Provider's professional judgment poses immediate and serious risk to Client systems, data, or operations.
2.7 "High Finding" means a vulnerability or security deficiency with a CVSS base score of 7.0–8.9, or that poses significant near-term risk.
2.8 "AI/ML Asset" means machine learning models, model weights, fine-tuning datasets, training pipelines, inference infrastructure, model APIs, agent orchestration systems, embedding stores, vector databases, and related components.
Authorized Scope and Rules of Engagement
3.1 Provider will act only within the Authorized Scope. Scope changes require a written amendment, change order, or supplemental authorization signed by an authorized representative of Client before Provider extends its activities.
3.2 The following are out of scope by default and require explicit written authorization for each action:
- systems, environments, or accounts not expressly listed in the Authorized Scope;
- denial-of-service, load, or stress testing against production systems;
- destructive testing, data deletion, or permanent configuration changes;
- live detonation of malicious payloads in production or connected environments;
- exfiltration of actual production data beyond what is minimally necessary to demonstrate a finding;
- social engineering, phishing, or physical penetration activities; and
- access to or extraction of AI/ML model weights, proprietary training data, or fine-tuning datasets beyond what is minimally necessary and expressly authorized.
3.3 If Provider discovers that a test action may exceed the Authorized Scope, Provider will pause, document, and seek written authorization before proceeding.
3.4 Provider will not use testing methods that would constitute a violation of applicable law, including the Computer Fraud and Abuse Act (CFAA) or equivalent statutes.
Access Controls
4.1 Provider will use only the Client Credentials and permissions expressly provided or authorized by Client for the Authorized Scope.
4.2 Provider will not use, store, copy, share, or reuse Client Credentials beyond the scope and duration necessary to perform Authorized Services.
4.3 Provider will store Client Credentials in a dedicated, access-controlled secrets management system, separate from Provider's general systems, with access limited to personnel directly involved in the engagement.
4.4 Provider will immediately notify Client and invalidate or rotate any Client Credentials that Provider knows or reasonably suspects have been exposed, compromised, or used outside the Authorized Scope.
4.5 Provider will not: (a) provision new privileged accounts; (b) create backdoors, persistent implants, or persistent remote access mechanisms; (c) modify authentication configurations; or (d) add or modify API keys, OAuth applications, or service account permissions, except as expressly authorized in writing for each action.
4.6 Provider will delete or return all Client Credentials upon completion of the applicable engagement or earlier upon Client request, and will certify deletion upon request.
Least Privilege
5.1 Provider will request and use only the access permissions necessary to perform the specific Authorized Services, and will not accumulate access beyond what current tasks require.
5.2 Provider will prefer read-only, non-privileged, or sandboxed access where it is sufficient for the authorized work.
5.3 Where elevated or administrative privileges are necessary, Provider will: (a) document the specific justification before requesting them; (b) notify Client in advance; and (c) relinquish them promptly upon completion of the task requiring them.
Logging and Activity Records
6.1 Provider will maintain contemporaneous records of:
- access events involving Client systems, APIs, environments, and AI/ML Assets;
- testing and assessment activities performed within the Authorized Scope, including timestamps, target systems, tools used, and actions taken;
- tool invocations, script executions, exploit attempts, and payload deliveries during authorized testing;
- vulnerability findings, notes, and interim analysis; and
- material communications with Client about scope, assumptions, authorization changes, or blockers.
6.2 Provider's logs will be stored in access-controlled, integrity-protected storage and will be maintained in sufficient detail to reconstruct what actions were taken, against which targets, by whom, and when.
6.3 Provider will not disable, suppress, tamper with, or circumvent Client-side logging, monitoring, or detection systems. Where testing requires simulating detection evasion, Provider will document the scope of that authorization specifically.
6.4 Logs constituting Evidence will be retained for the Retention Period and handled in accordance with Section 7.
Evidence Retention and Chain of Custody
7.1 Provider will retain Evidence for the Retention Period and will manage it with care proportional to its sensitivity.
7.2 Evidence containing Client Credentials, personal data, vulnerability proof-of-concept material, access tokens, model weights, proprietary prompts, or other sensitive material will be: (a) encrypted at rest; (b) stored in access-controlled systems; and (c) accessible only to personnel directly involved in the engagement.
7.3 Provider will maintain a basic chain-of-custody record for Evidence, documenting: the date Evidence was collected; the system or source; the personnel who collected and accessed it; and any transfers or copies made.
7.4 Evidence may be retained beyond the Retention Period only if: (a) required by applicable law or regulation; (b) subject to a legal hold; (c) needed for active dispute resolution; or (d) Client requests extended retention in writing.
7.5 Upon expiry of the Retention Period or Client's written request, Provider will securely delete Evidence using a recognized deletion standard (e.g., NIST SP 800-88 or equivalent) and certify deletion in writing upon request.
Findings Notification and Escalation
8.1 Provider will communicate security findings to Client in accordance with the following severity-based timelines:
Critical Finding (CVSS 9.0+): verbal or electronic notice to Client's designated security contact within [CRITICAL_NOTIFICATION_HOURS] hours of Provider identifying the finding, followed by a written summary within [CRITICAL_WRITTEN_SUMMARY_HOURS] hours;
High Finding (CVSS 7.0–8.9): written notice within [HIGH_NOTIFICATION_HOURS] hours of Provider identifying the finding; and
Medium and Low Findings (CVSS below 7.0): documented in the engagement report or at agreed reporting intervals.
8.2 Provider will include in finding notifications, to the extent available: (a) a description of the finding; (b) the affected system, component, or asset; (c) the potential impact; (d) any evidence (screenshots, logs, or proof-of-concept); and (e) Provider's initial remediation recommendation.
8.3 Security findings are Client Confidential Information. Provider will not disclose findings to third parties without Client's prior written authorization, except as required by applicable law.
8.4 Public disclosure of any security finding requires mutual written agreement, a disclosure timeline, and reasonable advance coordination with Client's security and legal teams.
Security Event Handling
9.1 If Provider discovers or reasonably suspects a Security Event affecting Client assets or data during or after service delivery, Provider will:
- immediately cease any activity that may be contributing to the event;
- notify Client's designated security contact within [SECURITY_EVENT_NOTIFICATION_HOURS] hours of discovery, regardless of whether the event is confirmed;
- provide available details including affected systems, potential impact, actions taken, and preliminary cause assessment;
- preserve all Evidence relevant to the event and maintain chain-of-custody records;
- cooperate fully with Client's incident response, investigation, and remediation process; and
- follow Client's written instructions regarding containment, communication, and disclosure.
9.2 Provider will not publicly disclose a Security Event involving Client assets without Client's prior written authorization, except as required by applicable law.
9.3 Upon request, Provider will provide a written post-incident summary within [POST_INCIDENT_SUMMARY_DAYS] business days of resolution, including a timeline, root cause analysis (where available), and lessons learned.
AI and ML-Specific Controls
10.1 When testing or assessing AI/ML Assets, Provider will apply the following controls in addition to the general controls in this Schedule:
- prompt injection and adversarial input testing will be performed only in authorized test environments unless the parties expressly agree in writing to limited production testing;
- Provider will not extract, copy, or retain model weights, proprietary embeddings, fine-tuning datasets, or training data beyond what is minimally necessary to document a specific finding and expressly authorized;
- Provider will not attempt to reconstruct proprietary training data, system prompts, or model configurations through inference or membership-inference attacks beyond what is expressly authorized; and
- AI/ML Assets discovered to be vulnerable to Critical or High findings will be treated with the same urgency and notification requirements as findings against traditional systems.
10.2 Provider will document the specific AI/ML testing methodologies applied, including prompt injection vectors tested, agent behavior observations, tool-use boundary tests, and model supply-chain checks performed.
10.3 Unless expressly authorized, Provider will not: (a) cause models to generate output that would constitute a regulatory violation; (b) interfere with AI/ML Assets used in production decision-making; or (c) submit data to third-party AI APIs using Client's API credentials beyond what is expressly required by the Authorized Scope.
Subcontractors and Personnel
11.1 Provider will ensure that all personnel and subcontractors with access to Client systems, assets, or data are subject to:
- confidentiality obligations at least as protective as the Master Agreement;
- appropriate background verification practices proportional to the sensitivity of the access granted; and
- access strictly limited to what is necessary for their role in the Authorized Services.
11.2 Provider will not grant subcontractors access to Client Credentials, systems, or Confidential Information without Client's prior written approval of the use of subcontractors on the engagement.
11.3 Provider remains fully responsible for the acts and omissions of its personnel and approved subcontractors in connection with services.
Tool and Environment Controls
12.1 Provider will use security tooling that is: (a) current and maintained; (b) appropriately licensed; (c) reasonably fit for the Authorized Scope; and (d) not known to contain malicious code or unauthorized surveillance features.
12.2 Provider will not install, deploy, or run tooling on Client systems, networks, or AI/ML infrastructure without specific prior written authorization identifying the tool, version, purpose, and target system.
12.3 Provider will disclose, upon written request, the general categories of tools and techniques used in connection with an engagement.
12.4 Provider will not use Client test environments, sandbox infrastructure, or lab systems to develop offensive capabilities for use against any party other than Client, and only within the Authorized Scope.
Schedule Review and Updates
13.1 Provider will review this Schedule annually, following a material Security Event, or following a material change in the services provided, and will provide Client with a written summary of any proposed changes.
13.2 Proposed changes to this Schedule will be provided to Client with [SCHEDULE_UPDATE_NOTICE_DAYS] days' written notice before taking effect. Client may object to changes that materially reduce protections, and the parties will negotiate in good faith to resolve objections.
13.3 Client may request an ad-hoc review of this Schedule following a material regulatory development, a significant change in the Authorized Scope, or a Security Event.
Signature Blocks
Client: [CLIENT_LEGAL_NAME]
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title:
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title:
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name: [CLIENT_AUTHORIZED_SIGNATORY_NAME]
Title
Title:
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title: [CLIENT_AUTHORIZED_SIGNATORY_TITLE]
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title:
Provider: aisecurity.llc
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title:
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title:
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name: David Wolf
Title
Title:
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title: Principal
Signatory
Signature
Signature: _______________________________
Date
Date: _______________________________
Name
Name:
Title
Title: