Policies

Accessibility

The standard we work toward, what the website does today, what we have not yet checked, and how to tell us about a barrier.

Our commitment

We want people with disabilities to be able to learn about Horme, join the beta, and use the product. We treat accessibility as a product requirement, not an extra.

The standard we work toward

We design the Horme website with the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA in mind, and we keep improving accessibility as the product changes.

We have not had an independent accessibility audit, and we do not claim that the website or the app fully conforms to WCAG 2.2 Level AA.

What the website does today

• Pages use headings in order, one main heading per page, and landmarks for the header, navigation, main content, and footer.
• A "Skip to content" link is the first thing keyboard users reach.
• Every link, button, and form field can be reached and used with a keyboard, and keyboard focus is shown with a visible outline.
• The waitlist form has visible labels and explains errors in words, such as "enter your email address". Those messages are marked up to be announced automatically to screen readers (using aria-live); we have not confirmed this with a manual screen reader test.
• Images that carry meaning have text alternatives. Decorative images and patterns are hidden from screen readers.
• The illustrative product view on the home page has a text description, and workflow diagrams are built as ordered lists that make sense without their connecting lines.
• Tables use real table headers, and wide tables scroll inside their own area on small screens instead of shrinking the text.
• Body text is checked against WCAG AA contrast ratios.
• Motion is minimal, and animations and transitions stop when your system asks for reduced motion.
• The layout works from small phones to large monitors without horizontal scrolling of the page.

Known limits

• The Horme web app is in private beta and has not yet been assessed against WCAG 2.2 Level AA.
• The website has not been tested with every screen reader and browser combination.
• Some code style diagrams in the documentation are plain text arranged with spacing and line characters. Screen readers read them line by line, and each has a caption that explains it.

Other formats

If you need information from this website in another format, such as plain text or a document that works better with your assistive technology, email hello@usehorme.com and tell us what you need.

Report a barrier

If something on the website or in the app is hard or impossible for you to use, email hello@usehorme.com with "Accessibility" in the subject line. It helps to include:

• the page or screen
• what you were trying to do and what happened
• the browser, device, and any assistive technology you use

We will reply to let you know how we plan to address it.

Accessibility policy

This policy explains how Horme approaches accessibility as an organization.

Design and development

New and changed pages and features should meet WCAG 2.2 Level AA where we reasonably can. That includes semantic structure, keyboard access, visible focus, sufficient contrast, text alternatives, labeled forms with clear errors, and support for reduced motion.

Communication

We write in plain language and communicate with people in a way that takes their disability into account, including by providing information in another format on request.

Accommodation requests

If a barrier stops you from using Horme, contact us and we will work with you on a reasonable alternative while we fix it.

Feedback

Anyone can give feedback on accessibility by email at hello@usehorme.com. We read every message and use it to decide what to fix.

Training

If Horme brings on staff or contractors who build or support the product, they will be introduced to this policy and to accessible design and communication.

Testing and review

We check accessibility when we make significant changes to the website, using automated checks and manual testing such as keyboard only navigation, zoom, and reduced motion. We review this policy when Horme changes in a way that affects it.

Responsibility

The operator of Horme is responsible for this policy and for acting on accessibility feedback. TODO: name the responsible role once the operator is set up

As Horme grows

Organizations in Ontario can take on additional obligations under the Accessibility for Ontarians with Disabilities Act as they grow, for example by hiring employees. We will review this policy against those obligations as Horme changes. Legal review

Acceptable Use

What Horme may not be used for, how authorized security testing fits, and what we do about abuse.

Why this policy exists

Horme sends work to coding agents that run on real computers with access to real repositories. That power can be misused. This policy applies to the Horme website, the web app, the runner, and the coding agents you start through Horme.

What you may not do

Do not use Horme, or agents started through Horme, to:

• access computers, networks, accounts, or data without authorization
• steal or harvest credentials, tokens, or secrets
• create, distribute, or run malware
• attack, damage, or disrupt systems you do not own or are not authorized to test
• run denial of service attacks, or flood other services with traffic
• send spam or run phishing campaigns
• mine cryptocurrency on computers or accounts without their owner's permission
• use repositories, computers, or accounts you are not authorized to use
• abuse or violate the terms of AI provider services, such as Anthropic's or OpenAI's, through Horme
• get around Horme's rate limits, usage limits, or security controls
• access, or try to access, another Horme user's account, runners, or data
• use Horme's servers to attack or probe third parties
• store, create, or share illegal content, or do anything else that is illegal

Authorized security testing

Horme is a developer tool, and security work is legitimate work. You may use Horme and its agents for security testing of systems you own, or that you have clear permission to test, within the scope of that permission.

If you find a vulnerability in Horme itself, follow Report a security issue. Do not access other users' data, degrade the service for others, or run destructive tests against Horme.

What we do about abuse

We may investigate suspected violations. Depending on what happened, we may warn you, remove content, limit features, suspend or close your account, revoke runner access, or report the activity to the relevant authorities where the law requires or allows it.

Report abuse

If you believe someone is using Horme in a way this policy prohibits, email hello@usehorme.com with "Abuse" in the subject line.

Changes to this policy

We may update this policy as Horme changes. The last updated date above shows when it last changed.

Cookies

The website sets no cookies and uses no analytics or tracking. The private beta app uses one essential sign in cookie.

Summary

• The Horme website sets no cookies.
• The website uses no analytics, advertising, or tracking tools, and does not use local storage, session storage, or similar browser storage.
• The Horme app, available only in private beta, uses one essential cookie to keep you signed in.

The website

www.usehorme.com is a set of static pages. It does not set cookies or store anything in your browser. Fonts and images are served from our own site, so loading a page does not contact other companies.

If you join the waitlist, the form sends your email address directly to our database. That request does not set a cookie.

The Horme app

When you sign in to the Horme app, it sets one cookie so you stay signed in between pages.

This cookie is needed for sign in to work, so the app does not ask you to accept it. The app does not use analytics, advertising, or tracking cookies. Legal review

How to control cookies

Signing out of the app removes the sign in cookie. You can also delete or block cookies in your browser settings. If you block the sign in cookie, you will not be able to stay signed in to the app.

Changes

If we ever add analytics or other cookies that are not essential, we will update this page first, and we will not load them until you agree where the law requires consent.

Security

How the runner and the web app fit together, the safeguards that exist today, and what we do not claim.

How Horme touches your machine

Horme has two parts: a web app that holds your projects, tasks, and run records, and a runner that you install on your own computer.

• Agents run on your computer, under your user account, in repositories you add.
• Horme cannot start an agent in a repository until that repository has been explicitly trusted on the machine running the Horme runner (node runner trust <path>). Trust is stored locally on your machine, not in the Horme database, so a browser session alone cannot grant it.
• The runner picks up only tasks from the Horme account it is paired with.
• The runner starts only the Claude Code or Codex command line tools you already have installed, along with git. It starts them as fixed programs with separate arguments, not through a shell.
• Agents act on the instructions in your tasks. Depending on the agent and its settings, they can change files and run commands in those repositories. Review their work before you merge or run it.
• Concurrent runs may use separate Git worktrees, which keep each run's git state separate. Git worktrees are not a filesystem security sandbox. Depending on the coding agent and your operating system permissions, an agent process may technically be able to access files outside its assigned worktree that your operating system user can access. Horme does not currently provide filesystem isolation.

Account separation

Browser access to the Horme database is restricted by Postgres row level security and column level grants, so a signed in browser session can read and write only its own account's data. We test this with separate accounts.

Privileged operations, such as the runner reporting task and run progress, do not go through the browser's row level security at all. They use separate runner API endpoints that authenticate the runner's own token and check that it owns the task or run before making any change.

Credentials

• Runner access tokens are stored only as one way hashes. The token itself stays on your computer.
• Pairing codes are single use and expire shortly after they are created.
• Privileged database credentials are used only on our servers and are never sent to the browser. We check our builds for this.
• Horme does not collect or store your Claude Code or Codex credentials. Agents use your own sign in on your machine.

The website

• The website is served only over HTTPS and tells browsers to keep using HTTPS.
• It sends standard browser security headers that block framing by other sites and limit what browsers may do with its pages.
• It has no analytics or third party scripts, and it loads its fonts from its own domain.
• Waitlist signups can be added from the website but cannot be read back from it.

What we do not claim

• Horme is in private beta. Security work is ongoing, and the product is changing.
• Horme does not hold security certifications such as SOC 2 or ISO 27001.
• Horme has not had an independent security audit or penetration test.
• No software is free of vulnerabilities, and we do not claim Horme is.

What you can do

• Connect only repositories and computers you trust Horme and your agents to work in.
• Keep secrets out of task prompts and references.
• Review agent changes before you merge, deploy, or run them, and keep using version control.
• Keep Claude Code, Codex, and the Horme runner up to date.

Report a security issue

If you believe you have found a vulnerability in Horme, please tell us privately. See Report a security issue, or email hello@usehorme.com with "Security" in the subject line.

Subprocessors

The service providers that process personal information on our behalf today, what each one handles, and where.

Current subprocessors

These service providers process personal information on behalf of Horme today.

Services that are not Horme subprocessors

• Anthropic and OpenAI. Claude Code and Codex run on your computer under your own accounts. Horme's cloud service does not directly send information to Anthropic or OpenAI. The Horme runner on your computer passes tasks to Claude Code or Codex, and those applications may send prompts, repository content, and other information to their provider under your own account and agreement with that provider, not on behalf of Horme. Legal review: subprocessor classification
• GitHub. We use GitHub to store Horme's own source code. It does not receive customer information from Horme.

Changes to this list

We update this page before a new service provider starts processing personal information for Horme.