Privacy Policy

Who is responsible for what

For this website and for your HypAware Cloud account details, Hyparam decides how the data is used. In legal terms we are the controller.

For the AI sessions your organization syncs to HypAware Cloud, your organization decides what is recorded and shared, and we process it for them. In legal terms they are the controller and we are their processor. Our Data Processing Addendum covers that processing. If your sessions were synced through your employer’s organization, ask them first about access or deletion.

What this website collects

We use PostHog (US Cloud) for site analytics. Requests go through our own domain and are forwarded to PostHog. The PostHog script loads with the page. Where consent is required, we show a banner before setting analytics cookies or recording sessions. We determine this from the country of your connection. If your country cannot be determined, we show the banner.

Where consent is required, before you choose, and if you choose Decline, PostHog runs without cookies, without browser storage, and without session replay. Page views and the events listed below are still sent to PostHog. Decline means no cookies and no replay. It does not mean no analytics.

Outside those regions, PostHog uses a cookie and browser storage and records sessions by default. In any region, choosing Accept enables those features. Replay masks everything typed into form fields. It does not mask page text.

What is sent: page views, clicks, and seven named events: install command copied, outbound link clicked, sign-in clicked, contact form submitted (the form name only, never the fields), pricing viewed, docs viewed, and section viewed. For clicks on this website, PostHog records the element clicked, including its text and link address. When you sign in to the HypAware dashboard and analytics is allowed, we link your analytics activity, including your earlier visits to this site from the same browser, to your account, using your account identifier, email, role, and organization. Signing out clears the link on that browser.

PostHog receives your IP address with each event and uses it to estimate your country and city. We have not turned on PostHog’s option to discard it.

We use Google Ads to measure which of our ads bring people to this site. The Google Ads tag loads from Google only after you choose Accept, or by default where consent is not required unless you choose Decline. If your browser sends a Global Privacy Control signal, the tag does not load. When it loads, it sets Google advertising cookies and sends Google your IP address, browser information, the address of the page you are on, and whether you arrived by clicking one of our ads. We have turned off ad personalization and Google signals for this tag and turned on Google’s restricted data processing, so data from your visit is not used to build remarketing audiences or to personalize ads. Google handles this data under its own privacy policy.

The contact forms collect your name, email, company, and message. The sales form also asks for company size. With each submission we also send which form you used, the full address of the page you were on (including anything after the question mark, such as campaign tags), and the time. Submissions go to Clarify, our CRM. A hidden field catches spam bots; if it is filled in, nothing is sent.

The site is static files on Amazon S3 behind Amazon CloudFront in the United States (us-east-1). CloudFront receives your IP address to serve the page.

Cookies and browser storage on this site

You can change your choice at any time with the Your Privacy Choices link in the footer of every page. Choosing Decline there is also how you opt out of the sharing of personal information for advertising under US state privacy laws, and we treat a Global Privacy Control signal from your browser the same way for the Google Ads tag.

PostHog keeps session replays for 30 days. Analytics events have no expiry set in PostHog; we keep them until we delete them. Contact form submissions and sign-up records stay in Clarify until we delete them.

The HypAware CLI on your host

The CLI records AI activity from the capture sources you turn on: AI clients such as Claude Code, Codex, and Cursor, raw Anthropic and OpenAI API traffic routed through the local gateway, and OpenTelemetry logs, traces, and metrics. The Privacy guide in our documentation lists every supported source and what it records. Recording is content-level. A recorded session can include:

• Prompts, responses, and system prompts
• The tool list, tool calls with their arguments, and tool results. Tool results can contain file contents, command output, and anything else the agent read
• Model, client version, timestamps, and token and cost figures where the client reports them
• The working directory and repository root as absolute paths, which usually include your OS user name
• The git remote URL (credentials in the URL are stripped), branch, and commit SHA
• Your AI provider account identifier: the Anthropic account UUID or the OpenAI user field
• Request and response headers for each exchange, with authorization, API key, cookie, and account ID headers redacted

A host is any machine the CLI runs on: your own computer, a build server, or a cloud machine where an AI vendor runs your agent, such as a Cursor Cloud agent’s machine. Some AI clients keep their conversations on the vendor’s service instead of on a machine you control, such as Codex Cloud and ChatGPT Work, or Cursor Cloud agents. For those, the CLI reads the conversations from the vendor’s API with your own sign-in or key. hyp session ignore and hyp privacy client work for them as for any other client. Folder markings work for Cursor Cloud agents, because the CLI runs on the agent’s machine and sees its folders. They do not work for Codex Cloud or ChatGPT Work, because the CLI reads those from OpenAI’s service and never sees the folders they ran in. ChatGPT Work can include everyday conversations that are not about coding.

Environment variables are not recorded as a field. Anything that appears inside a conversation is recorded as part of it, so recordings may contain personal, confidential, or secret information. On AI providers HypAware does not fully support, it may record less than the full session, never more.

Recordings are stored in a local cache under ~/.hyp. Rows age out after 120 days on a host that is not connected to an organization, and after 90 days on one that is. You can change the window.

A host that is not connected to an organization does not send your recordings anywhere. The HypAware daemon still makes three kinds of outbound connection. When installed globally through npm, it checks the npm registry about once a day for a new version of the hypaware package and, by default, installs it. It uploads nothing; the registry sees your IP address and a user agent. Setting auto_update to false turns it off. When you route an AI client through the local gateway, the daemon forwards that client’s traffic to the AI provider it was already going to. If you turn on a connected tool (GitHub or Linear, below), or an AI client whose conversations are kept on the vendor’s service, the daemon reads from that service’s API with your own sign-in, token, or key. There is no crash reporting, and there is no usage telemetry on a host that is not connected to an organization.

In proxy mode, all of the AI client’s HTTPS traffic passes through the local gateway. Only AI provider hosts (api.anthropic.com, api.openai.com, chatgpt.com) are decrypted, using a certificate authority generated on your host and limited to those AI provider hosts. Everything else is tunnelled without being decrypted: the gateway sees the hostname and byte counts and does not record them. The Security page has the details.

When you connect a host to an organization

Running hyp remote login or hyp join, or choosing the managed option during setup, connects the host to HypAware Cloud, operated by Hyparam. From then on recorded rows are sent to our server, including conversation content and every field listed above. hyp remote login also sends the host’s hostname as a label.

Defaults to know about. Every folder syncs unless you mark it otherwise. History already on the host is imported and synced too, back as far as the local retention window. A browser sign-in that enrolls a host for the first time holds the first sync until the end of the day (or the end of the next day, if fewer than four hours remain) so you can review what will be sent. hyp join and token sign-ins have no hold and show no notice.

Your controls

• Mark a folder ignore (never recorded), local-only (recorded, never synced), or sync, with a committed .hypignore file or the hyp privacy commands
• Be asked once per new folder instead of syncing by default: hyp privacy folders ask
• Keep one conversation out of the record: hyp session ignore. Not available for OpenClaw and Hermes sessions
• Keep one client’s future sessions from syncing: hyp privacy client <name> local-only. Not available for a client your organization requires
• Delete local recordings: hyp privacy purge. This never deletes copies already synced
• Disconnect: hyp leave. This stops syncing. It does not delete anything on the server
• Stop a cloud client: hyp codex-cloud disconnect or hyp cursor-cloud disconnect. Neither deletes what was recorded
• Folder markings do not apply to raw API traffic, OpenTelemetry data, or connected tools, because those sources carry no working directory. They also do not apply to Codex Cloud or ChatGPT Work, which the CLI reads from OpenAI’s service without seeing their folders

The hypaware-privacy review skill samples your local recordings to look for secrets and personal material. It runs inside your coding agent, so the excerpts it samples are sent to that agent’s model provider like any other turn. It masks credential values in what it reports back.

A connected host reports product telemetry to our server: command names, outcomes, durations, error codes, adapter names, OS type, CPU architecture, Node major version, and HypAware version. It never includes prompts, responses, paths, or command arguments. hyp telemetry off turns it off. On the server, telemetry is kept for 30 days.

Connected tools

HypAware can read activity from the tools your team tracks work in, so a query can connect a session to the issue or pull request it led to. Today those tools are GitHub and Linear (an issue tracker). Every connected tool follows the same rules:

• It is off until you turn it on
• It runs on your host, with your own sign-in or a token you provide. That credential stays on your host
• It only reads. About once a day, unless you change that, it calls the tool’s API for the records you chose. The requests carry none of your recorded content, but they name the repositories or teams being read
• It keeps the shape of the work and leaves the content in the tool: record IDs and numbers, states, the account IDs of the people involved, timestamps, how records link to each other, and, for code, commit SHAs and changed file paths. It does not keep titles, descriptions, bodies, or comment text
• Its rows age out of the local cache like recordings. On a host connected to an organization they sync, every member can read them, and the server keeps them until deleted, like other synced data
• hyp github logout and hyp linear logout remove the sign-in from your host. To revoke HypAware’s access, also remove it in GitHub’s or Linear’s settings

What each tool reads and keeps:

On the server, these rows join your organization’s graph, which links issues to the pull requests they reference and through them to commits and recorded sessions. Members and operators read these links like other graph data. A link records that an issue referenced a pull request, not that the pull request implemented or closed it. A Hyparam operator can also run a GitHub backfill for configured repositories, with a token held on our server. It pulls the same kinds of records (issues, pull requests, reviews, commits, changed file paths, and actor logins) and does not store titles or bodies. There is no Linear backfill, and Hyparam holds no Linear token.

HypAware Cloud

Synced data is stored on a single server we operate in Amazon Web Services in the United States (Oregon, us-west-2), behind Amazon CloudFront. Everything for your organization, including recorded sessions, search indexes, reports, report generation transcripts, and transcripts of conversations with Ask (the question box in the dashboard), lives on that server’s volume, separated from other organizations by partition. The volume and its snapshots are encrypted at rest with AWS EBS encryption. Daily snapshots are kept for 14 days.

Inside your organization, visibility is uniform. Every member can list, search, and read every other member’s synced sessions in full, including prompts, tool arguments, tool results, and working directory paths. Every member can read every published report. Admins can also see the member roster, including emails, last sign-in times, and hostnames, and can add and remove members and manage access tokens.

Hyparam operators can read any organization’s data: sessions, search, reports, report drafts, Ask conversation transcripts, member rosters, and host lists. Operator standing is limited to named staff, granted and removed by hand. Today operators use it to review reports from schedules Hyparam sets up and from manual runs they start, before those reports are published, for support you ask for, and for security and keeping the service running. Ask conversations hold the questions members ask in the dashboard, the conversation history, the session data the model looked at, and the answers. Operators read them to check the answers Ask gives, for support you ask for, and for security and keeping the service running. Members and admins cannot see the stored transcripts in the product. We do not read your session logs outside those purposes, and we do not copy customer data off the server to laptops, personal AI accounts, or test environments. Operator reads through query and search, including reads of Ask conversation transcripts, are written to an audit trail for the organization concerned. Operator views of reports and report drafts are not audited, and neither are listing views. The audit trail is not visible to your organization today. Staff with access to the server itself can read data without leaving an audit record.

Reports are generated on our server using Anthropic’s API under Anthropic’s standard commercial terms, through Hyparam’s own account. To write a report, the model runs queries over your organization’s synced sessions, and the results are sent to Anthropic as they are stored: prompts, responses, tool arguments, paths, git remotes, and account identifiers can all be included. The collector masks recognized credentials and sensitive file-tool contents before syncing. The server applies no additional redaction before sending query results to Anthropic. Requests use a prompt cache that Anthropic holds for one hour. Anthropic’s commercial terms exclude training on API inputs and outputs. Report generation can run on a schedule without a person starting it. Ask uses the same Anthropic API under the same terms. Your question, the conversation so far, the session data the model queries to answer it, and who is asking (your email address, your hosts’ names, and the dashboard page you are on) are sent to Anthropic as they are stored.

A report from a schedule Hyparam sets up, or from a manual run started by a Hyparam operator, starts as a draft that only Hyparam operators can see. An operator reviews it in the dashboard, may edit it, and publishes it to your organization. Reports from schedules your organization’s admins set up are published to your organization when generated, without operator review. Reports can quote session text word for word. We keep the full transcript of each generation run (the instructions, the model’s output, and the query results it saw) with your organization’s data. Operators can read those transcripts. Members cannot.

You sign in with Google. For your account we hold your verified email, the identifier Google gives us, your organization and role, sign-in times, active sessions, the hosts you connected (ID and hostname label), a record of the terms version you accepted and when, and the first and last name your Google account shares, if any. We do not store passwords. The first time you sign in to an organization or first connect a client, we send your email, your name if Google shares it, your organization’s name, and the date to Clarify, our CRM. Application logs record the email address of a sign-in that was refused, along with organization names and session IDs, and never contain session content or query text. Amazon CloudFront, which fronts HypAware Cloud, keeps access logs with your IP address, browser user agent, and the address requested for 90 days; we use them for security and troubleshooting.

The dashboard sets a sign-in cookie (HttpOnly, Secure, SameSite=Lax) that lasts up to 90 days and expires after 30 days without use. Two short-lived cookies are used during sign-in and onboarding. The dashboard keeps one local storage entry of its own that remembers which reports you have seen. Its name contains your organization name and your user identifier, its value is a timestamp, and it is not removed when you sign out. After analytics is allowed, it keeps a second entry, hypaware.signin.v1, holding the session ID of the current sign-in so each sign-in is counted once. It is removed if you decline analytics. The dashboard loads PostHog for analytics under the same consent rules as this site, and shows the same banner when you haven’t chosen yet. It records page views and clicks. For each click it sends the page, the type and position of the element clicked, and for some buttons a fixed name we assign. It also sends one named event, sign_in_completed, with the sign-in method and whether it is your first sign-in. When you answer a feedback question on a report or recommendation, it sends your answer (yes or no) as soon as you click it, along with which report or recommendation page it was about. If you then write a comment and press Send, it sends the comment too. A comment is sent as you wrote it, including anything you paste into it, so leave out anything you don’t want to share with us. Other than that comment, it doesn’t send the text of what you clicked, report or session content, or form input. It doesn’t record sessions. It loads no other third-party scripts or fonts.

The HypAware Cloud server sends product analytics events to PostHog (US Cloud) through hypaware.ai/ingest, with IP geolocation turned off. The events are: a person signed in to an organization for the first time, a host enrolled, the first sync received, the first session recorded, a report published, a report viewed, a recommendation applied, and a recommendation dismissed. They contain your account identifier, your organization, how you signed in and whether that sign-in created the organization, report and recommendation IDs, the enrollment method, HypAware version, OS family, the names of configured clients, session and day counts from a host’s first hour of sync, and the number of recommendations in each report. They never contain session content, prompts, responses, file paths, repository names, hostnames, report or recommendation text, or email addresses. PostHog keeps these events until we delete them. The HypAware version, OS family, and client names in them are copies of product telemetry, so the 30-day server retention above does not apply to those copies. Once a day the server may post the identifier and email domain of an organization whose onboarding has stalled to our internal Slack channel. It may also post the identifier and email domain of an organization that reached a milestone, such as its first session, with the milestones it reached and a count of new members.

HypAware Cloud sends email through Amazon SES, from addresses at hypaware.ai. Service email covers invitations and notices to organization admins about members, hosts, and usage. Product email is triggered by activity in your account, such as your first sign-in, a host connecting, or a report being published, and by inactivity, such as not yet connecting a host. Every product email has an unsubscribe link, and unsubscribing stops all product email. Service email continues while you are a member. Emails greet you by your first name when we have it. They contain your organization name, report titles, hostname labels, counts, and links, and notices to organization admins about members also include the member’s email. They never contain session content, prompts, responses, report or recommendation text, or file paths. Amazon SES keeps the addresses that unsubscribed, bounced, or marked an email as spam, so we do not send to them again.

Retention and deletion

Synced sessions, reports, audit records, report generation transcripts, and Ask conversation transcripts are kept until deleted. Data already sent to Anthropic to generate a report or answer an Ask question is held by Anthropic under its own retention terms and is not covered by our deletion. Removing a member revokes their access and does not delete the sessions they synced. hyp leave and hyp privacy purge do not delete anything on the server.

There is no self-service way today to delete synced sessions or an organization’s data. Deletion is done by hand by Hyparam on request, or when your organization leaves. We delete within 30 days of the request, and backup snapshots expire 14 days after that. To ask for deletion, write to us at the privacy and legal address under Contact. Published reports can also be deleted by an operator on request. Deleting a synced session does not delete Ask conversation transcripts that used it; they are deleted with the organization’s data.

You can pull your organization’s data out through the query interface (up to 10,000 rows per call) and download your reports. There is no one-step bulk export today.

How we use data

We use synced data to provide the service to your organization: session search, usage analysis, reports, and administration. We use site analytics, product telemetry, and information about how the product is used, with your content removed, to improve product performance and customer experience.

We do not use your session content to train models. We do not sell personal information. Apart from the Google Ads measurement on this website, described above, we do not share it for advertising.

We do not publish findings from your reports, with or without your name, unless you approve it.

Who we share data with

We share data with the service providers on our Subprocessors page, each for the purpose listed there. We give organization admins 30 days’ notice before adding a provider that handles synced data. We may disclose data when the law requires it, and we would transfer it as part of a merger or sale of the business, under this policy’s terms.

Your rights

Depending on where you live, you may have the right to access, correct, delete, or receive a copy of your personal data, and to object to or limit how it is used. For website and account data, write to us at the privacy and legal address under Contact. For sessions synced through an organization, ask that organization. We will help them respond.

We do not discriminate against anyone for using these rights. If you are in the EU or UK, you can also complain to your data protection authority.

We are based in the United States, and data is processed in the United States.

HypAware is a tool for professional software teams. It is not directed at children, and we do not knowingly collect data from anyone under 16.

Contact

Hyparam Corporation. Privacy and legal requests: legal at hypaware dot ai. Product support: support at hypaware dot ai.

We will post changes here with a new date.

Version hypaware-2026-11-10.2. Updated November 10, 2026.