Data Processing Agreement

§ 1Parties, subject matter and duration

This agreement is between the holder of the account that adds a site to Agent Tracking (the “Controller”) and FINAL MASTER LLC, 7901 4th St N Ste 300, St. Petersburg, FL 33702, USA (the “Processor”). Full details are in the imprint.

The subject matter is the processing of data that the script agent.js collects on the Controller's pages and sends to the Processor, of server log lines the Controller uploads, and their storage, aggregation and display in the dashboard, the API and the MCP endpoint. Annex 1 describes the processing in detail.

The agreement starts when the site is added and ends when the Controller removes the site from the account or the account is deleted. Section 7 says what happens to the data then.

§ 2Nature and purpose of the processing, categories of data and of data subjects

The purpose is a statistic of whether and how AI assistants and AI agents visit the Controller's site and use its WebMCP tools. The processing consists of collecting, transmitting, storing, aggregating into daily totals, displaying and deleting.

The categories of data are those listed in Annex 1. The data subjects are visitors of the Controller's site and people who use an AI assistant that visits it.

§ 3Instructions

The Processor processes the data only on documented instructions from the Controller. This agreement and the settings the Controller makes in the dashboard (adding, verifying, publishing and removing a site, uploading a log) are those instructions. Further instructions are given in text form to hi@finalmaster.net.

If the Processor considers an instruction unlawful, it informs the Controller without delay and may suspend carrying it out until the Controller confirms or changes it.

The Processor does not process the data for its own purposes. In particular the data is not used for advertising, profiling or the training of models, and is not passed to third parties unless a law requires it; in that case the Processor informs the Controller before processing, where the law allows.

§ 4Obligations of the Processor

The Processor ensures that only persons who are bound to confidentiality have access to the data.

It implements the technical and organisational measures in Annex 2 under Art. 32 GDPR and may develop them further as long as the level of protection does not fall. Material changes are documented in Annex 2 with a new date.

It assists the Controller in responding to requests from data subjects. The stored data contains no identifier through which a particular person could be found; the Processor confirms this on request and, on instruction, deletes the records of a named period.

It assists the Controller with the obligations under Art. 32 to 36 GDPR as far as the information available to it allows. A personal data breach affecting this processing is reported to the Controller at the account address without undue delay after the Processor becomes aware of it, with the details under Art. 33 (3) GDPR as far as they are available.

It keeps the record under Art. 30 (2) GDPR and provides the Controller with the details the Controller needs for its own record; Annex 1 contains them.

§ 5Sub-processors and international transfer

The Controller consents to the use of the following sub-processors:

• NexoSystems IT-Solutions, Niederzier, Germany: provision and connectivity of the server on which the data is stored. The hosting provider has no access to the contents of the data in regular operation.
• GitHub, Inc., 88 Colin P. Kelly Jr. Street, San Francisco, CA 94107, USA: storage of a daily copy of the database, encrypted with AES-256 before it leaves the server, in a private repository. The key is held only by the Processor; GitHub cannot read the contents. The transfer rests on the adequacy decision for the EU-US Data Privacy Framework, of which GitHub is a member.

No other sub-processors are used. In particular the data is not transmitted to providers of email, payment or analytics services; messages to the Controller itself contain no data of data subjects.

Transfer to the Processor. The Processor is established in the United States. All data under this agreement is stored and processed on the server in Germany; the Processor reaches it only over an encrypted administrative connection, and the pseudonymised records described in Annex 1 are the only data an administrator can see. For Controllers in the EU or EEA the standard contractual clauses of the European Commission (Decision (EU) 2021/914, Module Two, controller to processor) form part of this agreement, with the Controller as data exporter, the Processor as data importer, Annex 1 as their Annex I.B, Annex 2 as their Annex II, the optional docking clause selected, the law and courts of Ireland for Clauses 17 and 18, and the supervisory authority of the Controller's member state under Clause 13. Where this agreement and the clauses conflict, the clauses prevail. Controllers in the United Kingdom are covered by the UK International Data Transfer Addendum to the same clauses.

If the Processor intends to add or replace a sub-processor, it informs the Controller at the account address at least 30 days in advance. The Controller may object for a substantial reason related to data protection. If no agreement is reached, the Controller may end this agreement by removing the site.

§ 6Evidence and audits

On request, the Processor makes available to the Controller the information necessary to demonstrate compliance with this agreement, as a rule as a description in text form of the processing and of the measures in Annex 2. The source code of the service is public and can be inspected at any time.

If that is not sufficient, the Controller or an auditor it appoints who is bound to confidentiality may audit compliance: with at least 14 days' notice, during usual business hours, without disproportionate disruption of operations and at most once per calendar year unless a specific reason requires a further audit. The Controller bears the costs of the audit.

§ 7Deletion and return

Independently of this agreement, raw data is deleted automatically 90 days after it was collected. Daily totals remain as long as the site is in the account.

When the Controller removes the site from the account, the Processor deletes all raw data, daily totals, the tool registry and the settings belonging to it without delay and permanently. The same applies to all sites of an account when the account is deleted. Encrypted backup copies expire within 30 days.

The daily totals of a site can be exported from the dashboard as CSV at any time before removal.

Statutory retention duties remain unaffected; to the Processor's knowledge none apply to the data described here.

§ 8Liability

The liability of the parties towards data subjects is governed by Art. 82 GDPR. Between the parties, section 7 of the terms of service applies.

§ 9Final provisions

The agreement is concluded when the Controller adds a site in the dashboard. It applies accordingly to every further site. Where it conflicts with the terms of service, this agreement prevails in matters of data protection.

If the Processor amends this agreement, it publishes the new version with its date at this address and informs the Controller at the account address. The new version applies immediately to sites added afterwards, and to existing sites 30 days after the notice unless the Controller removes the site before then.

The English text is binding. The agreement is governed by the law that governs the terms of service, except that the standard contractual clauses incorporated in section 5 are governed as they themselves provide, and nothing in this agreement limits rights that the GDPR grants data subjects or the Controller.

Annex 1: The processing in detail

Collected and stored per page view: the page path without query string and fragment; the referrer host and the utm_source parameter, only to attribute the visit to an AI assistant; the result of that attribution (referrer and user agent matched against a published, versioned list); a session id. For WebMCP tools in addition: the tool name, a hash of its description and schema, the duration and outcome of a call (success or failure, error class), the names of the input keys; the name of an element marked as a goal when it is clicked or submitted; a hash of the manifest at /.well-known/webmcp.

The session id is a SHA-256 hash of a random value generated afresh every day, the domain, a coarse browser class (mobile or desktop, or the id of a known agent) and the network address, shortened to 16 characters. The network address is not stored. From the next day on, the hash can no longer be linked to the day before.

Not collected: the network address as such, cookies or anything else placed on the device, values of input fields or form contents, names, email addresses or accounts of visitors, screen or device characteristics. Events with fields other than the intended ones, and batches from a domain other than the registered one, are discarded.

Server log lines the Controller uploads or sends by script: from a line, the day, the agent name and the page path are taken over. The network address is used while the request is processed only to group one agent's fetches and to check the agent against its vendor's published address ranges, and is discarded when the request ends. The log file itself is not stored.

Duration: raw data 90 days; daily totals, tool registry and manifest hash until the site is removed. Location: a server in Germany.

Annex 2: Technical and organisational measures

• Server access: The server is in a data centre in Germany. Access is exclusively over SSH with keys; password login is disabled.
• Access to the data: The dashboard is reachable only after sign-in. Sign-in is by a link sent to the account address, valid for 30 minutes and for one use; the session ends after 30 days or on sign-out. Each site is visible only to its account holder. A public stats page appears only when the Controller switches it on explicitly, and shows totals only.
• Pseudonymisation and data minimisation: as in Annex 1. The random value for the session id is regenerated daily and the old one discarded. Batches over 50 events, fields outside the list, query strings and input values are discarded on receipt.
• Transmission: The script, the ingest endpoint and the dashboard are served and accept data over TLS only.
• Separation: Data is stored and queried per domain; ingest is limited per account and per sending address.
• Deletion: Raw data is deleted automatically every day after 90 days. Removing a site deletes all of its data in one transaction.
• Availability: The database writes transactionally. Every day a consistent snapshot is encrypted with AES-256 and stored outside the server (see section 5); the key is held only by the Processor.
• Change control: The service is deployed from public, versioned source code with automated tests. Discarded batches are counted without reference to a person.