trezor-agent's dependency list names python-daemon twice, and its tags use two schemes

The key is generated on the device and never reaches the computer

That sentence is the project. Instead of storing a key on the machine and unlocking it with a passphrase when you need it, the key is generated and stored on the hardware device, and the private material never arrives on the host. The design write-up lives in a separate document rather than on the repository front page, which tells you where to look for the details. What the front page does list is the range of uses: signing email, signing commits and software packages, driving password stores through two named tools, and authenticating web tunnels and file transfers. The practical consequence of the design is that each of those operations becomes a device round trip. The agent is doing the cryptography with the device rather than reading a secret, so the cost is a prompt on a small screen per operation rather than a passphrase typed into a terminal.

Four devices, four components, and one component in someone else's repository

Four hardware devices are listed as supported: two Trezor models, a Blockstream device, and an OnlyKey. The repository is described as holding one shared library plus the agents that talk to those devices, and the four components are named separately. Three of them are published as their own installable packages, the shared library and two of the agents on a package index. The fourth, the Jade agent, is linked to the Blockstream repository rather than to anything published from here. So this is a four-part project where three parts are versioned here and one part is not, which matters for anyone tracking updates: a change to the Jade path shows up as a commit in a different project's history, under a different release cycle, with a dependency boundary in between.

Five protocol modules in the library, and one has no documentation page

The shared library is installed as six packages, of which five are protocol or device modules: one for the age encryption scheme, one for device handling, one for GPG, one for SSH, and one for a third signing and verification agent protocol that the front page never mentions in prose. The documentation index has a page for installation, and then one each for SSH, GPG and age, one for configuring the PIN entry program, and one for Windows. Six pages against five protocol modules, and the pairing does not line up: the signing protocol has no page, and the PIN entry and Windows pages have no module of their own. The PIN entry page exists for a mundane reason worth naming, because a device that asks for a numeric code needs a helper program to display the layout and capture the digits in a terminal or on another system.

One dependency appears twice with two different minimum versions

The install list has fifteen entries and one of them is repeated: a daemon library is required at one version floor near the top of the list and again at a lower floor further down. Whichever resolver you use, the effective constraint is the stricter of the two, so it is harmless in practice and wrong in the file. Two other entries are more telling about how the list was assembled. A reStructuredText processor is a runtime requirement, which is a documentation-formatting library, and the wheel build tool is listed alongside it, which is a build-time package. Neither belongs in what a user installs at run time. One entry does carry a platform marker so that it installs only on Windows, and the rest are unconditional, which is consistent with a package that supports both a POSIX and a Windows platform classifier.

The release list mixes two tag schemes and one entry disagrees with itself

The three most recent releases are named inconsistently. The newest is a namespaced tag with a library prefix and a dotted version. The one before it is recorded under the same namespaced scheme while its own title uses the older plain prefix, so the name and the title of the same release disagree. The third uses the plain prefix again. Underneath the naming, the cadence is uneven: the plain-prefixed release before the two newest ones dates from September 2024, and the next release did not appear until February 2026, a gap of about seventeen months. The newest tag was published in March, and the last push to the default branch is dated July, so the working tree is several months ahead of any release. The version declared in the packaging file does match the newest tag, which is one thing that is consistent.

A production stability label next to a setup.py and a version bump file

The packaging metadata classifies the library as production stable, and it is delivered through a setup script rather than a modern build file, with a version-bump configuration file at the repository root and a separate release shell script. Linting is configured through its own file rather than a modern linter's configuration, and there is a tox file for test environments. The declared floor is Python 3.8, while the classifier list mentions only that the package is Python 3 and gives no per-minor versions, so a user cannot tell from the metadata which interpreters are actually exercised. The licence is declared as the LGPL in both the repository and the classifiers, which is the one place where the two surfaces agree completely.

The feature history is documented through vendor firmware announcements

The three blog posts the front page points at are not project write-ups. They are firmware release announcements for three successive versions of the Trezor firmware, covering SSH login, then signing and transaction features, then decryption support. Two are hosted on a blogging platform and one on a forum thread. That choice tells you where the capability boundaries come from: this project cannot add a signature scheme the firmware refuses to perform, so the project's own history is a sequence of firmware versions. The gap is that all three announcements concern SSH and GPG. The age encryption scheme has its own documentation page and its own module in the library, but no announcement among the three describes it, so the newest protocol the project supports is the one with no vendor post behind it.

Editorial conclusion

Suitable if you already own one of the four supported devices and want the key to stay on it, since that is the whole design claim and it is stated plainly rather than implied. Before you rely on it, check which protocol you actually need against the documentation index, because one of the five protocol modules in the library has no page there, and note that only three of the four agent components are published from this repository. Install it as a library rather than from a tag, since the tag naming is inconsistent across releases.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. romanz/trezor-agent on GitHub