Effective Date: August 12, 2026 Version: attestation-2026-08-12
This Source Access Attestation is presented before a customer first executes a covered third-party Source operation through ZENITH by FINA1 and may be re-presented when the applicable legal, credential, ownership, or requested-use conditions materially change.
Customer attestation
By selecting “Accept and continue”, the person accepting this Attestation confirms, on behalf of the applicable customer organization, that:
- Authorized access. The customer is authorized to access the selected provider, Source, account, document, website, application, API, database, or information resource.
- Authorized credentials. Any credential, API key, token, cookie, account, subscription, or license supplied or connected to Zenith is valid and authorized for the requested use.
- Lawful instructions. The requested access, retrieval, processing, normalization, analysis, display, storage, caching, disclosure, redistribution, publication, and downstream use comply with applicable law and third-party rights.
- Source obligations. The customer is responsible for reviewing and complying with applicable Source terms, license limits, privacy requirements, contractual restrictions, confidentiality obligations, attribution requirements, geographic restrictions, and usage limits.
- No circumvention. The customer will not use Zenith to bypass CAPTCHA, access controls, anti-bot systems, credential restrictions, paywalls, technical protection measures, or geographic restrictions.
- No prohibited or consequential action. The customer will not direct unlawful, harmful, fraudulent, destructive, write-capable, or consequential activity prohibited by the FINA1 Terms of Service, Acceptable Use Policy, Source Terms, or applicable operation policy.
- Third-party content. Third-party materials remain subject to the rights of their respective owners. FINA1 does not grant rights in those materials or represent that the customer’s use is permitted by the Source.
- Customer responsibility. The customer is responsible for validating outputs and for its downstream decisions, products, services, publications, display, storage, redistribution, commercialization, and other use.
- Technical agency. Zenith acts as the customer’s technical agent solely to carry out the customer-selected permitted request and does not become a party to the customer’s agreement with the Source.
- Terms and liability allocation. The customer accepts the FINA1 Terms of Service, Customer-Directed Source Access Terms, Acceptable Use Policy, Privacy Policy, and applicable Data Processing Addendum, including the governing indemnity, disclaimer, suspension, and limitation provisions.
- Authority to bind organization. The accepting user has authority to make this Attestation for the customer organization or has been granted permission by an authorized organization administrator to initiate the request.
- Continuing accuracy. The customer will stop using the affected Source operation and update its authorization information if any representation above becomes inaccurate.
Customer-facing disclosure
The acceptance interface should present the following disclosure with an affirmative acceptance control:
You are directing Zenith to access the selected third-party Source on your organization’s behalf. By continuing, you confirm that your organization is authorized to access and use the Source and any connected credentials, and that the requested use complies with applicable law, Source terms, licenses, privacy obligations, contractual restrictions, and third-party rights. Zenith provides technical access and normalization; it does not grant rights in third-party content or determine that your use is legally permitted.
Required acceptance evidence
The Service should record an immutable or append-only acceptance record sufficient to establish the governing legal and operational state, including:
{
"terms_version": "terms-2026-08-12",
"source_terms_version": "source-access-2026-08-12",
"attestation_version": "attestation-2026-08-12",
"aup_version": "aup-2026-08-12",
"privacy_version": "privacy-2026-08-12",
"accepted_by_user_id": "authenticated-user-id",
"accepted_for_organization_id": "organization-id",
"accepted_at": "ISO-8601 timestamp",
"provider_id": "selected-provider-id",
"operation_id": "selected-operation-id",
"credential_binding_id": null,
"requested_use": ["PRIVATE_APPLICATION_USE"],
"request_id": "request-id"
}The Service may additionally retain minimized IP-address and user-agent evidence where reasonably necessary to establish acceptance, prevent fraud, or defend legal claims, subject to the FINA1 Privacy Policy and retention schedule.
Re-attestation triggers
The Service may require renewed acceptance when:
- the FINA1 Terms of Service or Customer-Directed Source Access Terms materially change;
- this Attestation materially changes;
- organization ownership or authorized-control status changes;
- a new customer Source credential is bound;
- a Source changes from public to authenticated access;
- the requested use materially expands, including to display, redistribution, persistent storage, caching, or a different commercial purpose;
- a Source complaint, legal request, policy incident, or security event requires renewed confirmation;
- a relevant license or authorization expires or changes; or
- FINA1 reasonably requires re-attestation to maintain reliable evidence of authorization.
Runtime denial conditions
Zenith should deny a physical Source request before execution when required legal or authorization evidence is absent or invalid, including when:
- current governing terms have not been accepted;
- this Attestation is absent, revoked, expired under applicable policy, or version-incompatible;
- the operation is classified as prohibited, consequential, destructive, or non-read-only without separate authorization;
- required customer credentials or license references are missing;
- a prohibited-use signal is present;
- the operation is not technically live or lacks required substantive validation; or
- the Source is unavailable or materially degraded.
A pre-execution denial must not be represented as a successful Source request.
Record integrity
A completed Source request should remain linked to the exact legal-policy and operation-policy versions that governed the request when it occurred. Later policy versions apply prospectively and do not rewrite the historical acceptance record.