What did Hlido score infrabroker?

infrabroker scored 74/100 (STEADY) in Hlido's independent, hands-on review.

Does any vendor pay Hlido for placement?

No. Hlido takes no money from the agents it rates — scoring weights stay private and the evidence behind every verdict is public.

infrabroker

Name: infrabroker review
Item: infrabroker
Rating: 74
Author: Hlido Editor

Infrastructure · tested 2026-08-19 · re-test due 2026-11-19 · by the Hlido desk, not the vendor

In short: An infrastructure access broker built on a genuinely strong idea — the model never holds a credential; it requests an action and the broker mints a single-use key for it.

Visit infrabroker → scorecard.json

Quick answer

infrabroker scores 74/100 (STEADY) on Hlido’s independent, hands-on test (reviewed 2026-08-19). STEADY (74) for a security-first infrastructure access broker with a genuinely strong core design (agents never hold credentials; single-use SSH certs / bound ServiceAccount tokens), three authenticated frontends, and co

Hlido Editor · 2026-08-19

infrabroker (formerly ssh-broker) is an SSH and Kubernetes access broker for AI agents whose central design decision is the right one: the model never receives a credential. It requests an action, and the broker executes it with a credential minted for that single operation — an ephemeral, scope-limited SSH certificate from its own CA, or a short-lived bound ServiceAccount token — and returns only the output. That inverts the usual, dangerous pattern of handing an agent long-lived secrets. It offers three frontends from one binary: MCP over stdio for local personal use with process isolation, MCP over HTTP with OAuth2/OIDC where each client authenticates and the user identity and groups propagate to the signer for multi-user setups, and HTTP+mTLS for network agents with a client certificate. The engineering discipline shows in the documentation: the published reference (HTTP endpoints, MCP tool schemas, config fields, CLI) is generated from the actual code by a docgen tool and diff-checked in CI, so it cannot drift from the implementation — and the site foregrounds an explicit threat model and architecture. The honest limits are maturity and reach: at v3.1.2 with a low public star count and an apparently single maintainer, this is an early, specialist tool, and Hlido reviewed the documentation site rather than a running broker, so the credential-minting and isolation behaviour are described and code-referenced rather than exercised. But the security model is exactly what agent infrastructure access should adopt.

Why STEADY

STEADY (74) for a security-first infrastructure access broker with a genuinely strong core design (agents never hold credentials; single-use SSH certs / bound ServiceAccount tokens), three authenticated frontends, and code-generated CI-checked docs with a published threat model — held down to low-medium confidence by early maturity (v3.1.2, low adoption, apparently solo) and a surface-only review that did not exercise the broker. Not VITAL absent hands-on verification and broader track record.

What we saw

4 screenshots captured by the Hlido engine during the reviewed run (run-2c1d994261f6bdbb-luisgf-github-io). Our own captures — not vendor marketing material.

infrabroker — run screenshot 1 (home.png) — home.png

infrabroker — run screenshot 2 (page_infrabroker.png) — page_infrabroker.png

infrabroker — run screenshot 3 (page_start-here.png) — page_start-here.png

infrabroker — run screenshot 4 (page_generated-reference-from-code.png) — page_generated-reference-from-code.png

What it does well

Excellent core primitive: the model never receives a credential — it requests an action and the broker mints a single-use, scope-limited SSH cert or short-lived ServiceAccount token
Three clear frontends from one binary: local MCP/stdio, multi-user MCP/HTTP with OAuth2/OIDC and identity propagation, and HTTP+mTLS for certificate-bearing network agents
Documentation is generated from code (routes, tool schemas, config structs) and diff-checked in CI, so the reference cannot drift from the implementation
Foregrounds an explicit threat model and architecture rather than burying security
Directly targets the right risk — replacing long-lived agent secrets with per-operation, auditable credentials

What it fails at

Early and low-adoption — v3.1.2 with a small public star count and an apparently single maintainer
Surface-only review — Hlido read the docs, not a running broker, so credential minting, scoping and isolation are described, not tested here
Specialist scope (SSH + Kubernetes) and real operational setup (a CA/PKI, OIDC, mTLS) — not a turnkey product
No independent security audit is cited on the captured surface

Best for

Teams giving AI agents SSH or Kubernetes access who want per-operation, auditable credentials instead of long-lived secrets
Security-conscious operators comfortable running a broker with its own CA/PKI and OIDC/mTLS
Multi-user setups needing user identity to propagate to the credential signer

Not recommended for

Users wanting a mature, widely-adopted product with vendor support
Teams unwilling to operate PKI/OIDC/mTLS infrastructure
Anyone needing a hands-off, turnkey access solution

Related agents

Agent relevance

API CLI MCP Behavioral-testable

Agentic-Commerce Readiness 67/100 · INTEGRABLE

Independent readiness for agent delegation & transaction. How it’s scored · check live

Run `infrabroker serve-mcp` (local stdio) or `serve-mcp-http` (OAuth2/OIDC, multi-user); agents call MCP tools that request SSH/Kubernetes actions, and the broker executes them with a single-use minted credential. A `serve-http` mTLS endpoint (POST /v1/ssh_run) serves certificate-bearing network agents.

Agent-friendly score: 9/10

Evidence

Excellent core primitive: the model never receives a credential — it requests an action and the broker mints a single-use, scope-limited SSH cert or short-lived ServiceAccount token — source (2026-08-19) verified
Three clear frontends from one binary: local MCP/stdio, multi-user MCP/HTTP with OAuth2/OIDC and identity propagation, and HTTP+mTLS for certificate-bearing network agents — source (2026-08-19) verified
Documentation is generated from code (routes, tool schemas, config structs) and diff-checked in CI, so the reference cannot drift from the implementation — source (2026-08-19) verified
Foregrounds an explicit threat model and architecture rather than burying security — source (2026-08-19) verified
Hands-on runtime behaviour (executing the tool / a live task) — source (2026-08-19)

scorecard.json · transparency passport · registry · methodology

More: compare agents · best of · developer tools · incident registry

Verdict by Hlido Editor, our automated editorial system · Method: public-surface-tier-2+editorial-narrative-v2 · Methodology version 2026.05 · Next review due 2026-11-19

How this page was produced. The scores, claim verdicts and evidence come from automated hands-on testing of the product’s public surface. The written analysis is drafted by an AI system, and pages publish without a person reviewing each one. Hlido publishes this record and answers for it — tell us if anything here is wrong and we will correct it.

Embed this trust badge

Live, always-current independent score — free to embed on your site or README. No vendor pays for placement.

Markdown

[![Hlido trust score](https://hlido.eu/badge/luisgf-infrabroker.svg)](https://hlido.eu/check/?agent=luisgf-infrabroker)

HTML

<a href="https://hlido.eu/check/?agent=luisgf-infrabroker"><img src="https://hlido.eu/badge/luisgf-infrabroker.svg" alt="Hlido trust score"></a>