Security

01Local

On your host

Recordings live in a local cache under ~/.hyp. With Claude Code attached, raw request and response bodies pass through a spool directory that only your user can read (mode 0700). HypAware reads each file for the few fields it needs and deletes it. The spool is capped at 512 MB by default. Every local listener (the gateway, the OpenTelemetry listener, the client listeners) binds to loopback only.

A connected host holds two credentials, each in a file only your user can read (mode 0600). The forward credential lets the daemon send rows to your organization, pull the organization’s managed configuration, and renew itself. It cannot read data. It lasts 21 days by default and renews automatically. The query credential lets you read your organization’s data from the CLI. Its refresh token lasts 30 days, and access tokens last one hour.

hyp leave deletes the forward credential from the host. It does not revoke it on the server, and there is no hyp remote logout command. If a host is lost, ask us to revoke its credential. Removing a member from the organization revokes that member’s sign-in sessions.

If you turn on a connected tool (GitHub or Linear), its sign-in stays on your host. hyp github login and hyp linear login store it in a file only your user can read (mode 0600, in a directory with mode 0700). hyp github logout and hyp linear logout remove it; revoke HypAware’s access in GitHub’s or Linear’s settings as well. The Linear sign-in is read-only (scope read; the browser sign-in uses PKCE and a callback on 127.0.0.1) and refreshes automatically. GitHub has no read-only option, so the GitHub sign-in can read and write every repository your account can reach (the repo scope); HypAware only reads with it. A token given through an environment variable (GITHUB_TOKEN or LINEAR_API_KEY by default) carries whatever access it has. With neither a token nor a GitHub sign-in, HypAware uses your existing GitHub CLI sign-in and its access.

For AI clients whose conversations are kept on the vendor’s service, HypAware uses the credential you already have and keeps no copy of it. Codex Cloud and ChatGPT Work use the ChatGPT login Codex keeps on the host. Cursor Cloud agents use a Cursor API key from the CURSOR_API_KEY environment variable, which HypAware sends only to api.cursor.com. The file that connects a Cursor Cloud agent (mode 0600) names the agent and the repository and holds no key. The Cursor key is Admin-scoped, so it can reach more than the one agent HypAware reads. The ChatGPT login reaches your whole ChatGPT account. hyp cursor-cloud disconnect does not revoke the Cursor key; revoke it in Cursor’s settings.

When installed globally through npm, the daemon checks the npm registry about once a day and installs new versions of the hypaware package by itself. It checks the registry for a new version and uploads nothing you recorded. It is also a remote code update channel. An organization’s managed configuration can also set the flag. Set auto_update to false to turn it off and update by hand.

HypAware automatically masks recognized credentials and sensitive file-tool contents before writing them to the local cache, and again before cloud forwarding or file export. Built-in rules include known credential formats and a heuristic for random-looking tokens; they are on by default with no switch to turn them off. Organization and local custom patterns add export-only masking. Older recordings are masked on export, but their local contents are not rewritten. See the redaction documentation for the current defaults, exceptions, and detection limits. This is not comprehensive secret or personal data detection. The hypaware-privacy skill is a manual review you can run before syncing; its samples go to your coding agent’s model provider.

On AI providers HypAware does not fully support, the gateway stores only what it can decode and drops the rest with a warning. HypAware may record less than the full session on those paths, never more.

02Cloud

HypAware Cloud

HypAware Cloud runs in Amazon Web Services, Oregon (us-west-2), fronted by Amazon CloudFront. It is multi-tenant: organizations share infrastructure, and each organization’s data is kept in its own partitions.

Connections from your host and your browser use TLS, which terminates at Amazon CloudFront with a minimum of TLS 1.2 (the AWS 2021 security policy). The connection from CloudFront to the application host is plain HTTP inside the AWS network today, not TLS. Outbound calls to Anthropic and AWS use HTTPS.

The server takes the organization from the verified credential on every request, never from anything the client sends. A request for another organization’s data is refused unless the caller is a Hyparam operator. Separation between organizations is by partition, enforced in the server on every request, not by separate accounts or storage credentials.

Sign-in uses OpenID Connect with PKCE through Google. We store no passwords. Multi-factor authentication for your account is whatever your Google account enforces. The dashboard session is an HttpOnly, Secure, SameSite=Lax cookie that lasts up to 90 days and expires after 30 days without use. Access tokens last one hour and are held in memory, never in browser storage. Organization read tokens last up to 90 days and can be revoked. Join tokens for unattended hosts default to one year and can be minted for up to ten.

There are three roles: member, publisher, and admin. Roles control who can manage members and tokens. They do not limit reading. Every member can read every other member’s synced sessions in full, search them, and read every published report. If that does not fit your team, use the folder controls on each host to keep work local.

Hyparam operators can read and administer every organization: sessions, search, reports and drafts, Ask conversation transcripts (Ask is the question box in the dashboard), members, hosts, tokens, and managed configuration. Operator standing is an allowlist of named staff plus one administrative token held on the server. Shell access to production and operator standing are limited to named staff. Access is granted and removed by hand, and removal is part of offboarding. Operators read customer data for five purposes: reviewing and publishing reports from schedules Hyparam sets up and from manual runs they start, checking the answers Ask gives, support you asked for, security and abuse investigation, and keeping the service running. We do not copy customer data to laptops, personal AI accounts, or test environments; test fixtures are synthetic and development runs against our own staff’s sessions.

Operator reads through query and search are recorded in an audit trail kept with the organization’s data, including reads of Ask conversation transcripts. Views of reports and drafts, and listing views in the admin surface, are not audited. Your organization cannot see its audit trail today. Anyone with shell access to the server can read data without an audit record, and the audit records sit on the same volume.

Reports are generated on the server with Anthropic’s API, called directly under Anthropic’s standard commercial terms through Hyparam’s own account. The model queries your organization’s sessions, and the query results go to Anthropic as stored, without additional server-side redaction, up to 200 rows per query. Requests use a one-hour prompt cache on Anthropic’s side. Anthropic’s commercial terms exclude training on API inputs and outputs. One API key serves all organizations, and there is no per-organization opt-out today. Reports from a schedule Hyparam sets up, or from a manual run started by a Hyparam operator, are drafts until a Hyparam operator reviews and publishes them. Reports from schedules your organization’s admins set up are published to your organization when generated, without operator review. The full transcript of each generation run is stored with your organization’s data and is readable by operators only. Ask requests and responses are stored on the server and readable by operators only. Ask sends the member’s question, the conversation history, the query results, and the member’s email address, host names and current dashboard page to Anthropic under the same terms. Published reports are served under a content security policy that blocks scripts.

Application logs do not contain session content, prompts, query text, search patterns, IP addresses, or user agents. They do contain organization names, session and host IDs, and the email address of any sign-in that was refused. Amazon CloudFront access logs for app.hypaware.ai and api.hypaware.ai record IP address, user agent, and requested address, and are kept for 90 days.

The server volume is encrypted at rest with AWS EBS encryption, and so are its snapshots. It is snapshotted daily and each snapshot is kept for 14 days. A restore from snapshot has not yet been rehearsed.

Synced data has no expiry. There is no tool today to delete an organization’s synced sessions or a whole organization; deletion is done by hand on the server on request or when an organization leaves, within 30 days, and snapshots expire 14 days after that. Product telemetry expires after 30 days.

The dashboard loads PostHog for page views and, when you are signed in and analytics is allowed, links them to your account. Session replay is off in the dashboard. Click capture masks element text and attributes, so no report or session content is sent. The dashboard loads no other third-party scripts or fonts, and keeps no credentials in browser storage.

03Infrastructure

Our AWS account and detection

The root account has multi-factor authentication and no access keys, and multi-factor authentication is enforced on every staff account. CloudTrail is on across all regions with log validation, GuardDuty is enabled in the regions we use, and buckets that hold anything sensitive block public access. Production shares one AWS account with our website and other projects; it does not have a dedicated account. Dependabot alerts, secret scanning, and push protection are on for every product repository.

04Response

Incident response

A named Hyparam executive owns security incident response. If we confirm a breach affecting your data, we will notify your organization’s admins by email without undue delay and no later than 72 hours after confirmation, with what we know at the time and updates as we learn more.