Infrabroker

infrabroker

Infrastructure access broker for AI agents — SSH & Kubernetes. The model never touches a credential. *(formerly ssh-broker)*

The agent requests an *action* — run a command on a host, query or change a cluster. infrabroker checks it against policy, 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. Keys, certificates and tokens live in the broker's memory and are discarded after the call: nothing enters the model's context, so a prompt-injected agent has nothing to exfiltrate.

One binary — infrabroker — exposes the same engine (internal/broker) and tool surface (internal/mcpserver) over three transports, chosen by subcommand. (The legacy per-transport binaries broker / mcp-broker / mcp-broker-http remain as thin deprecated wrappers over these subcommands, so existing configs keep working.)

• MCP stdio (local, recommended for personal use) — infrabroker serve-mcp. Tools: ssh_execute, ssh_session_open / ssh_session_exec / ssh_session_close, ssh_list_servers, ssh_put_file / ssh_get_file; with clusters configured, also k8s_get / k8s_list / k8s_logs / k8s_apply / k8s_delete / k8s_list_clusters. No transport auth — isolation comes from the process being launched by the user (as the MCP spec recommends for stdio).
• MCP HTTP + OAuth2/OIDC (remote, multi-user) — infrabroker serve-mcp-http, Streamable HTTP. Same tools, but each client authenticates with an OIDC bearer token validated locally against the issuer's JWKS; the user identity (and groups, for per-user RBAC) is propagated to the signer.
• HTTP + mTLS — infrabroker serve-http, POST /v1/ssh_run (one-shot), for network agents authenticated with a client certificate.

Documentation

This README is a landing page. The detail lives in focused, single-source docs:

Why infrabroker

• Anti-exfiltration (prompt injection): the ephemeral key/cert/token live only in the broker's memory; they never enter the model's context.
• Kubernetes without kubeconfigs: the signer mints a short-lived bound ServiceAccount token (TokenRequest API) per operation; every cluster is default-deny with per-verb/resource/namespace policy and the same dry-run, approval and audit path as SSH.
• Anti-reuse: each cert carries a TTL of minutes, source-address (broker or bastion IP), and — for one-shot — a force-command. Useless outside its host/time/IP.
• Controlled escalation: allow_sudo / allowed_sudo_users live in the signer; a compromised broker cannot escalate where policy forbids it.
• CA compromise bounded: one CA per host group (ca_keys), each key optionally in Azure Key Vault or ssh-agent (YubiKey PIV / SoftHSM / TPM) — the private key never leaves the HSM.
• Audit / non-repudiation: append-only, Ed25519-chained log correlated by serial across signer, broker, and sshd.

The full threat model — including what the system deliberately does not defend — is in THREAT_MODEL.md.

How it works

AI model ──tool call──> broker ──mTLS──> [control-plane] ──mTLS──> signer

(no credential) (ephemeral key (approval + (CA key + in RAM, never guardrails, policy + RBAC, on disk) no CA key) signs the cert) │ └── SSH with the ephemeral cert ──> bastion ──> target host └─ stdout/stderr/exit_code ─> model

The broker sends an *intent* ({host, role, purpose, command?, sudo?, pty?, pubkey, …}); the signer derives every certificate constraint from policy and returns the signed cert. The ephemeral private key is generated in the broker and never leaves it. See ARCHITECTURE.md for the request flow, the design decisions, and the per-hop ProxyJump certificate diagrams.

Feature overview

Comparison with existing solutions

Several tools address SSH access control or AI-agent credential security, but none cover the full combination that infrabroker targets in a lightweight, self-hosted package.

[Teleport](https://goteleport.com/) is the closest commercial equivalent — short-lived SSH certs, RBAC, and since 2025 *Secure MCP*; its Jan-2026 *Agentic Identity Framework* targets the same threat model. The difference is operational weight: Teleport needs a dedicated control-plane cluster, recording proxy, and web UI — orders of magnitude heavier than a Go binary + signer.

[HashiCorp Vault SSH secrets engine](https://developer.hashicorp.com/vault/docs/secrets/ssh) is an SSH CA with full HSM/KMS support and (2025) its own MCP server, but it provides only the *signing* piece — you still build the execution layer (engine.go, session.go, the MCP tools) yourself.

[StrongDM](https://www.strongdm.com/) hides credentials but stores long-lived secrets rather than generating ephemeral certs in memory, making it weaker against exfiltration. [Smallstep SSH CA](https://smallstep.com/) is a lightweight OIDC-integrated SSH CA (close to cmd/signer) with no execution broker or MCP layer. **[ssh-mcp](https://