HypAware Data Processing Addendum

1. Definitions

• Customer Data: the AI session recordings and related data that Customer’s machines sync to HypAware Cloud, and reports generated from them.
• Personal Data: any information in Customer Data that relates to an identified or identifiable person.
• Data Protection Law: the privacy laws that apply to the Personal Data, including, where they apply, the EU GDPR, the UK GDPR, the Swiss FADP, and US state privacy laws such as the CCPA.
• Subprocessor: a third party Hyparam uses to process Customer Data.
• Security Incident: a breach of security that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Data.
• Operator: a member of Hyparam staff with administrative access to HypAware Cloud.

2. Roles and scope

2.1 Customer is the controller of Personal Data in Customer Data (or a processor for its own customers). Hyparam is Customer’s processor (or subprocessor). Under the CCPA, Hyparam is Customer’s service provider.

2.2 Hyparam is an independent controller of account data (emails, sign-in records, roles, organization membership, and dashboard analytics), website data, product telemetry, and service usage metrics (counts and identifiers, never content), as described in the Privacy Policy. This DPA does not cover that processing.

2.3 This DPA does not cover the HypAware CLI running on a machine that is not connected to HypAware Cloud. In that case no data reaches Hyparam.

3. Customer’s instructions

3.1 Hyparam processes Customer Data only on Customer’s documented instructions. The instructions are the Terms, this DPA, and how Customer and its users configure the product, including capture sources, folder classes, and the organization’s managed configuration.

3.2 Customer understands how the product works today and instructs Hyparam to process Customer Data on that basis:

• (a) every member of Customer’s organization can read every other member’s synced sessions and every published report;
• (b) a connected machine syncs every folder that has not been marked otherwise, and syncs history already on the machine;
• (c) reports are generated by sending query results over Customer Data to Anthropic, without redaction;
• (d) generated reports are reviewed, and may be edited, by an Operator before they are published to Customer.

3.3 If Hyparam believes an instruction breaks Data Protection Law, it will tell Customer.

4. Customer’s responsibilities

4.1 Customer is responsible for having a lawful basis to record and sync the sessions, and for giving notice to, and getting any required consent from, the people whose work is recorded. That includes telling them what is recorded, that it is synced, and who can read it.

4.2 Customer is responsible for using the product’s controls (folder classes, .hypignore, session ignore, the first-sync review, local purge) to keep out data it does not want processed. HypAware does not scan for or redact secrets or personal data.

4.3 Customer will not use HypAware to sync special categories of personal data, or data subject to sector rules such as HIPAA or PCI DSS, unless the parties agree in writing first.

5. Hyparam’s obligations

5.1 Hyparam will process Customer Data only to provide HypAware to Customer, and as the law requires. If the law requires other processing, Hyparam will tell Customer first unless the law forbids it.

5.2 Hyparam will not sell Customer Data, will not share it for cross-context behavioral advertising, will not keep, use, or disclose it outside the direct business relationship with Customer, and will not combine it with personal data from other sources except as the CCPA allows a service provider to. Hyparam certifies that it understands these limits.

5.3 Hyparam will not use Customer Data to train models. Report generation uses Anthropic’s API under Anthropic’s Commercial Terms, which exclude training on API inputs and outputs.

5.4 Hyparam may create information about how the product is used that contains no Customer content and does not identify Customer or any person, and use it to improve product performance and customer experience.

5.5 Hyparam will not publish findings from Customer’s reports, with or without Customer’s name, without Customer’s written approval.

6. Hyparam personnel and Operator access

6.1 Operators can read any organization’s Customer Data. Operator standing is limited to named Hyparam staff on an allowlist, plus one administrative token held on the server. Shell access to the host and Operator standing are limited to named staff; Hyparam will give Customer the current list on request. Access is granted and removed by hand and removal is part of Hyparam’s offboarding procedure.

6.2 Operators may read Customer Data only for these purposes: (a) reviewing and publishing Customer’s reports, (b) support Customer asked for, (c) security and abuse investigation, and (d) keeping the service running. Hyparam does not read Customer’s session logs outside those purposes.

6.3 Everyone with Operator standing is bound by a duty of confidentiality.

6.4 Operator reads through the query and search interfaces are recorded in an audit trail kept with Customer’s data. Operator views of reports and drafts, and listing views in the admin surface, are not recorded today. Access made directly on the server host is not recorded. Customer cannot see the audit trail today, and Hyparam does not provide audit records except where the law requires it.

6.5 Hyparam does not copy Customer Data off the production server to staff devices, personal AI accounts, or development or test environments. Test fixtures are synthetic. Development runs against Hyparam’s own staff sessions. There is no staging environment.

7. Security

Hyparam will keep in place the measures in Annex II. Customer has read Annex II, including the items listed there as not yet in place, and agrees the measures are appropriate for the data it chooses to sync. Hyparam may change the measures as long as the overall level of protection does not go down.

8. Subprocessors

8.1 Customer gives general authorization for Hyparam to use the Subprocessors listed at https://hypaware.ai/subprocessors and in Annex III.

8.2 Hyparam will give Customer’s organization admins at least 30 days’ notice by email before adding a Subprocessor that handles Customer Data.

8.3 If Customer objects on reasonable data protection grounds within the notice period, the parties will talk it through in good faith. If they cannot resolve it, Customer can end its use of HypAware Cloud.

8.4 Hyparam has a written contract with each Subprocessor with data protection terms no less protective than this DPA, and stays responsible for what its Subprocessors do with Customer Data.

9. International transfers

9.1 Customer Data is stored and processed in the United States (Amazon Web Services, Oregon). Other regions are not offered today.

10. Requests from individuals

10.1 If a person asks Hyparam to exercise a privacy right over Personal Data in Customer Data, Hyparam will pass the request to Customer and will not answer it directly, unless the law requires it to.

10.2 Hyparam will help Customer respond. Customer can search and read its data through the product. There is no tool today to delete or correct individual synced sessions. Hyparam does that by hand on Customer’s written request within 30 days.

11. Security Incidents

11.1 Hyparam will notify Customer without undue delay after confirming a Security Incident affecting Customer Data, and no later than 72 hours after confirmation.

11.2 The notice will say what happened, what data and how many people are likely affected, what Hyparam is doing about it, and who to contact. Hyparam will send what it knows at the time and follow up as it learns more. Notice goes to Customer’s organization admins by email from Hyparam’s responsible person for security.

11.3 Notifying Customer is not an admission of fault.

12. Assistance and audits

12.1 Hyparam will give Customer reasonable help with data protection impact assessments and consultations with regulators, as far as they relate to HypAware.

12.2 Hyparam holds no security certification and has not had a penetration test. On written request, no more than once a year, Hyparam will answer Customer’s reasonable security questionnaire and give Customer the information it needs to show compliance with this DPA. If Data Protection Law requires more, the parties will agree on the scope, timing, and cost of an audit ahead of time. Audit results are Hyparam’s confidential information.

13. Return and deletion

13.1 During the term, Customer can retrieve Customer Data through the query interface (up to 10,000 rows per call) and download its reports. There is no one-step bulk export today. On written request before termination, Hyparam will provide a copy of Customer’s data in Parquet format.

13.2 After the Terms end, or earlier on Customer’s written request, Hyparam will delete Customer Data, including reports, report drafts, report generation transcripts, search indexes, graph data, and usage rollups, within 30 days. Deletion is done by hand on the server today. Encrypted backup snapshots of the server volume are kept 14 days, so deleted data leaves all backups within 14 days after deletion. Hyparam will confirm in writing when deletion is complete. Customer Data already sent to Anthropic for report generation is held by Anthropic under Anthropic’s Commercial Terms and is outside Hyparam’s deletion.

13.3 Hyparam may keep Customer Data longer only where the law requires it, and will keep it confidential and not process it for anything else.

13.4 Audit records about Customer’s organization are deleted with Customer Data.

14. General

14.1 If this DPA conflicts with the Terms, this DPA wins for the processing of Personal Data.

14.2 Each party’s liability under this DPA is subject to the limits in the Terms.

14.3 Governing law and venue follow the Terms.

Annex I: Description of processing

Parties. Data exporter and controller: Customer. Data importer and processor: Hyparam Corporation, legal@hyperparam.app.

Subject matter. Storing, indexing, searching, and analyzing Customer’s AI session recordings, and generating reports from them.

Duration. The term of the Terms, plus the deletion period in Section 13.

Nature and purpose. Receiving synced rows from Customer’s machines; storing them on Hyparam’s server; building search indexes, graph projections, and usage rollups; running queries for Customer’s members; generating reports with a third-party language model; Operator review of generated reports; administration and support.

Data subjects. Customer’s employees and contractors who use AI coding tools on connected machines. Any other person whose information appears in a recorded session, for example in source code, tool output, logs, or prompts.

Categories of data.

• Session content: prompts, responses, system prompts, tool lists, tool call arguments, tool results (which can include file contents and command output), and model reasoning signatures
• Session context: absolute working directory and repository paths (these usually contain the OS user name), git remote URL, branch, commit SHA, model, client version, timestamps, token and cost figures
• Identifiers: AI provider account identifier (Anthropic account UUID or OpenAI user field), machine ID, machine hostname label
• Redacted request and response headers for each exchange
• OpenTelemetry logs, traces, and metrics, where that source is on
• GitHub activity, where collected: event type, repository, actor login, numbers, SHAs, changed file paths, review state
• Reports, and the transcripts of report generation runs, which contain query results over all of the above

Special categories. None intended. Session content is free text and Hyparam does not filter it, so Customer controls what is synced (Section 4).

Frequency. Continuous while machines are connected.

Retention. Data is kept on the server until deleted under Section 13. Daily volume snapshots are kept 14 days. Product telemetry expires after 30 days.

Subprocessors. Annex III.

Annex II: Security measures

This annex states what is in place at the date of this DPA. Items not yet in place are at the end.

Hosting and architecture. Amazon Web Services, Oregon (us-west-2), fronted by Amazon CloudFront. Multi-tenant; organizations share infrastructure.

Tenant separation. The server reads the organization from the verified credential on every request and never from client input. Each organization’s data is in separate partitions, enforced by the server.

Encryption in transit. TLS 1.2 or higher (AWS 2021 security policy) from Customer’s machines and browsers to Amazon CloudFront. The connection from CloudFront to the application host is plain HTTP inside the AWS network. Outbound calls to AWS and Anthropic use HTTPS.

Encryption at rest. The server volume and its snapshots use AWS EBS encryption. In the identity store, refresh and join secrets are stored as SHA-256 hashes. Emails, memberships, and machine labels are stored in plain text.

Authentication. Sign-in through Google with OpenID Connect and PKCE. No passwords are stored. Multi-factor authentication for Customer’s users depends on their Google accounts. Dashboard session cookie: HttpOnly, Secure, SameSite=Lax, 30 days idle, 90 days maximum. Access tokens: one hour, held in browser memory only. Refresh sessions: 30 days. Machine forward credentials: 21 days, renewable. Organization read tokens: up to 90 days, revocable. Join tokens: one year by default, up to ten years. Signing secret rotation is supported.

Authorization inside an organization. Roles are member, publisher, and admin. Admins manage members and tokens. All members have the same read access to all of the organization’s data.

Operator access. Section 6. Operator standing comes from an allowlist read when the server starts, plus one administrative token held on the host. Reads made with the shared token are recorded without a personal identity. Shell access to the host is limited to named staff.

AWS account. Root account has MFA and no access keys. MFA is enforced on every staff account. CloudTrail is on in all regions with log validation. GuardDuty is enabled in the regions in use. Buckets holding sensitive material block public access.

Audit logging. Reads through query, search, and the tool interface, identity events, membership and role changes, and report publish, delete, and generate actions are recorded per organization. Not recorded: report and draft views, admin listing views, the member roster view, and any access made directly on the host. Audit records are stored with the data they describe.

Logs. Application logs: no session content, prompts, query text, search patterns, IP addresses, or user agents; they do contain organization names, IDs, and the email address of a refused sign-in. CloudFront access logs: IP address, user agent, and requested address, kept 90 days.

Language model processing. Anthropic API, called directly over HTTPS with one account-wide key under Anthropic’s Commercial Terms. Query results are sent unredacted, capped at 200 rows and 128 KiB per query. One-hour prompt cache on Anthropic’s side. No per-organization opt-out. No zero-data-retention arrangement is in place.

Report handling. Generated reports are drafts, readable by Operators only, until an Operator publishes them. Published reports are served under a content security policy that blocks scripts.

Backups. Daily encrypted snapshot of the server volume, retained 14 days.

Detection and response. CloudTrail and GuardDuty as above, plus the application audit trail. A named responsible person for security incidents. Notification per Section 11.

Development practice. Dependabot alerts, secret scanning, and push protection on all product repositories. Synthetic test fixtures; no Customer Data in development or test.

Staff devices. Disk encryption and screen lock required by policy; laptops enrolled in Apple Business Manager. Offboarding removes host account, operator standing, sessions, IAM user, and repository access, and reclaims the device.

Dashboard. PostHog for page views, linked to the signed-in account when analytics is allowed. Session replay off. Click capture masks element text and attributes; no report or session content sent. No other third-party scripts or fonts. No credentials in browser storage.

Collector (on Customer’s machines). Local cache and credential files readable only by the OS user. Local listeners on loopback only. Locally generated certificate authority, name-constrained to three AI provider hosts, not installed in any OS trust store by current releases. Folder classes, session ignore, first-sync review hold on browser enrollment, and local purge. Daily update check against the npm registry with automatic install, which Customer can turn off.

Not yet in place.

• Encryption between CloudFront and the application host
• Secret or personal data scanning or redaction, on the collector or the server
• Tooling to delete an organization’s data or individual sessions (deletion is by hand)
• Customer-visible audit trail
• Bulk export
• Security certification (SOC 2 intended, no date) and penetration test
• Dedicated production AWS account
• Rehearsed backup restore
• Device management enforcement of disk encryption and screen lock (planned)

Annex III: Subprocessors

The current list is at https://hypaware.ai/subprocessors. At the date of this DPA, for Customer Data:

PostHog is used on the hypaware.ai website, the HypAware dashboard, and for service usage metrics sent by the HypAware Cloud server. On the dashboard it receives account data only, which Hyparam processes as an independent controller under Section 2.2, and never receives Customer Data. Clarify is used only on the website and does not receive Customer Data.

Version hypaware-2026-10-14. Updated October 14, 2026.