How Hawkeye is built, in the terms a reviewer will ask about.

The shape of it

• No inbound path from the internet. Your machines dial out to Hawkeye; Hawkeye never dials in. The panel reaches a machine only back down that machine's own outbound tunnel, so there is nothing to port-forward and nothing of yours answering the public internet. Exactly, because this page promises exactness: the agent itself does keep one listener — TCP 8891, bound to every interface — as a faster path for callers already on your LAN or tailnet, and it is where box-to-box copies and direct probes go. It takes the same bearer key as every other path, it is not reachable from the internet by anything Hawkeye installs, and XFER_PORT_DIRECT=0 removes it at the cost of that direct path.
• Orgs are a hard tenant boundary. A machine in someone else's org is not a filter you can widen — it is not addressable. Crossing the boundary is a request the other side approves, and the approval is redeemed once.
• Tokens are hashed at rest and single use. Invites, install links and pairing codes are stored as hashes, compared in constant time, and marked redeemed atomically. A leaked token costs you that token, not the fleet.
• Sessions are server-side, with CSRF tokens on every mutating form, cookies that are HttpOnly, Secure and SameSite=Lax, and passwords stored as PBKDF2 hashes.
• Scopes are a closed vocabulary. An app or device asks for named permissions; anything outside the vocabulary is dropped, and the dangerous ones are quarantined behind an explicit tick on the approval screen that shows you the requesting IP.
• Your machine's key is a Worker secret. It is never a database row, never returned by an API, and never passes through a browser or a model.
• Every privileged action is audited — who asked, who approved, what ran, where, when. What that gives you between those boundaries is a record of what was done, not a gate in front of it. Read it as evidence after the fact, not as a control that stops something first. One caller stands outside even the record's attribution: the shared fleet key is a break-glass credential, accepted without an identity chain, so its actions are attributable to the key rather than to a person, and the policy that is being observed is not evaluated for it at all. Its uses are counted and the recent ones kept, which is how a machine can show you how often break-glass was reached for. Narrowing it is open work, not a shipped property — treat possession of that key as possession of the fleet.

Said plainly, because a reviewer will find it anyway

• The desktop installers are not code-signed or notarised; there are no signing certificates on this project yet. Checksums are published beside every download so you can verify what you got.
• Authority boundary (observe_only). Enrollment and client pairing require approval. After pairing, allowed actions execute without per-action approval: each machine's policy is evaluated and written to the audit trail in observe mode (XFER_POLICY_MODE defaults to observe, deliberately) rather than applied. A connected AI client can still raise an explicit human request when it creates one, and cross-org access is still a request the other side grants.
• The daemon's default configuration opens a local listener for LAN use. If that is not what you want, turn it off at install time.
• Findings from our own adversarial reviews are tracked in the repository, fixed in order of severity, and the open ones are open in writing.

Reporting a security issue

Email contact@transition2.ai. We aim to acknowledge a report within 2 business days and will work with you on a fix and disclosure timeline before anything is made public. No bug bounty program exists today — we're grateful for a report regardless. This deployment is operated by Transition 2 Consulting Inc., under the laws of British Columbia, Canada — see Terms for the full contracting details.

Reading order for a buyer: what is stored, then who is responsible for what, then what it costs.