hoop.dev vs Teleport

The hoop.dev sidecar decides what every statement does after Teleport lets someone in. It blocks a statement or holds it for a person before the database runs it, and masks sensitive values in the result.

Get started free Talk to us

On the wire

① Decode

② Judge

③ Act

postgres:5432 · raw

51 00 00 00 2a 53 45 4c
45 43 54 20 65 6d 61 69
6c 2c 20 73 73 6e 20 46
52 4f 4d 20 63 75 73 74
6f 6d 65 72 73 3b 00 5a
00 00 00 05 49 54 00 00
00 21 00 01 65 6d 61 69
6c 00 00 00 40 06 00 02
44 00 00 00 1c 00 02 00
2e 70 61 72 6b 40 61 63
51 00 00 00 2a 53 45 4c
45 43 54 20 65 6d 61 69
6c 2c 20 73 73 6e 20 46
52 4f 4d 20 63 75 73 74
6f 6d 65 72 73 3b 00 5a
00 00 00 05 49 54 00 00
00 21 00 01 65 6d 61 69
6c 00 00 00 40 06 00 02
44 00 00 00 1c 00 02 00
2e 70 61 72 6b 40 61 63

Raw wire protocolSELECT email, ssn FROM customers;one of thousands per second

structured action

{  action:  "read",  table:   "customers",  columns: ["email", "ssn"],  rows:    "all",  agent:   "agent-19"}

same shape for SQL, SSH, HTTP, gRPC and RDP

rulesOPA · postgres-prod.rego

mask pii.* on readssn is PII → mask

AI analyzeryour model

payload + ticket + history!bulk read, unusual for this ticket

decisionbefore the query runs

Maskssnbefore it reaches the agent
Approvebulk read→ @data-owner, waiting …→ @data-owner  approved
runs now, ssn masked

What does each one decide?

hoop.dev decides what each statement does. Teleport decides who gets in, and for how long. Every claim cites the page that backs it: our docs for hoop.dev, Teleport’s docs for Teleport.

hoop.dev and Teleport, feature by feature
	hoop.dev sidecar	Teleport
A decision on each statement before it runs	YesA guardrail denies a matching statement before the database sees it, and the client reads the reason.¹	PartlyTable-level grants on PostgreSQL, set when the connection opens. Its docs describe no check on what a statement says.²
Sensitive values masked in results	YesRewrites sensitive values in the response, in memory, before they reach the client.³	NoIts database docs describe none.²
A model scores each statement’s risk	YesThe AI Analyzer classifies each SQL statement and HTTP request body. Block and allow in Open Source, warn and defer in Enterprise.⁴	NoIts database docs describe none.⁵
A person approves one statement	YesA risky statement waits until a person releases it. Enterprise.⁴	NoApprovals grant a role or a resource for a time window, not a single query.⁶
A record of each database query	YesEach statement, what each rule decided and why, over OpenTelemetry.⁷	YesAn audit event for each SQL query, with its text, parameters, database and user.⁵
What it covers	PartlyPostgreSQL, MySQL, SQL Server, MongoDB, ClickHouse, HTTP, MCP, the Kubernetes API and SSH.³	YesSSH servers, Kubernetes clusters, databases, applications, Windows desktops and MCP servers.⁸
MCP servers	YesAn MCP lane hides the tools a rule denies and judges each tool call.⁹	YesEnrolls and proxies MCP servers. Roles allow or deny tools by name or pattern.¹⁰
Who reaches which resource	NoIt works after your access layer has decided. Keep the one you run.	YesRoles pick databases by label, plus the database users and names a person may use.²
Single sign-on for people	NoNot an identity provider. Your IdP and Teleport keep that job.	YesGitHub in Community. Okta, Entra ID, Google, SAML and OIDC in Enterprise.⁸
Time-limited access with approvers	NoIt grants no access. It judges what runs inside the access you granted.	YesA role or a resource for a set time, with approvers. Full in Enterprise, role requests from the CLI in Community.⁶

The hoop.dev gateway, our old architecture, also has access requests, session recording and identity federation. Read the gateway docs.

Which one do you need?

Once agents reach production, the question moves from who gets in to what they run.

Agents send thousands of statements that nobody reads.hoop.dev
Customer data must never reach an agent’s context.hoop.dev
One risky write should wait for one person, without pausing the whole session.hoop.dev
You want to start free at any company size.hoop.dev
People need one door to servers, clusters and desktops, with single sign-on.Teleport
Agents and engineers already go through Teleport, and you need to control what they run.Both

How do the two run together?

Who sends it

AI agent
Engineer

Teleport

Who gets in

Single sign-on
Short-lived certificate
Role and time limit

hoop.dev sidecar

What each statement does

SELECT email FROM customersMaskedmaria@acme.com
UPDATE plans SET price = 0Held for a person
DROP TABLE ordersBlocked

Your resources

PostgreSQL
MySQL
MongoDB
SSH
Kubernetes

One request, left to right. Teleport decides who gets in. The hoop.dev sidecar decides what each statement does, and only what passes reaches your resources.

You can keep Teleport.
Add hoop.dev.

Put the hoop.dev sidecar in front of one database, free under MIT, and watch it decide on every statement your agents send. Teleport keeps deciding who gets in.