AccessFlow vs hoop.dev: a gateway you connect through versus a proxy you submit to

The short version

In one line: hoop.dev lets your existing clients connect through a gateway that records and can hold a command; AccessFlow makes you submit the statement and decides before it runs.

Choose hoop.dev when what you want is a single door for engineers to reach infrastructure through, with the tools they already use: psql by hostname, kubectl, SSH, remote desktop and the AWS command line all routed through one gateway that records the session and can hold a command for approval. Its newer sidecar goes further in one direction, sitting in front of a PostgreSQL, SQL Server or HTTP endpoint with a few milliseconds of overhead to block or mask what an AI agent sends and receives. Choose AccessFlow when what you want is a governance record of every statement: submitted through its editor, API or Model Context Protocol (MCP) server, checked against written rules, scored by an AI analyzer, routed by policy through a multi-stage approval chain, executed under row-level security and export controls, and written to an audit log that can prove it has not been edited since.

The products meet at the review step. hoop.dev's gateway can require approval of the exact command before it runs; AccessFlow requires it for everything by default and lets policy decide what does not need a person. Where they part is in what surrounds that step: hoop.dev reaches sideways into hosts, clusters and desktops, and AccessFlow reaches downwards into the data with masking, row rewriting, export governance and signed reports, and outwards into API calls and deployments.

Side by side

✓ Included · ◐ With caveats or in a paid edition · ✕ Not available · ? Not documented

Not documented means we could not find the capability in hoop.dev's public documentation on the date in Sources; it does not mean the product lacks it. Where the gateway and the sidecar differ, the cell says which one is meant.

Where each one sits in the path to the database

hoop.dev today is two things in one repository. The gateway is the established product for human access: a person signs in with the organisation's identity provider, opens the web app or the CLI, and reaches a database, a shell, a cluster or a Windows desktop through it. A local tunnel daemon lets ordinary clients keep working, so psql -h pg-prod.hoop goes through the gateway with placeholder credentials while the real ones stay on the agent side. Along the way the session is recorded for playback, sensitive values in results are redacted by a detection engine, guardrail patterns block dangerous commands, and a connection or an individual command can be held until someone in the right group approves it from Slack, Teams or the web app. The sidecar is the newer piece, aimed at AI agents: a single binary next to a PostgreSQL, SQL Server or HTTP endpoint that decodes the wire protocol, applies an ordered deny list, optionally asks a language model to classify the statement, and rewrites the response before the client sees it, with an Enterprise control plane to manage a fleet of them.

AccessFlow is a single service, and it does not sit on the wire. A person types into its editor, an application calls its REST API, or an agent calls its MCP server, and what arrives is a statement to be judged, not a connection to be relayed. The statement is parsed so that its type and the exact tables and columns it touches are known, compared with the datasource's allow-list and, on the relational engines, its written review rules, sent to the AI analyzer for a risk score and a list of issues, and passed to a routing policy that decides who, if anyone, must approve it. Once approved it executes through the proxy under row-level security, masking and export rules, and the result is stored masked. Every step is an audit entry chained to the previous one with a keyed hash, so a later edit or deletion can be found by the built-in verifier, and the chain can be streamed to a SIEM or to write-once storage.

The consequence is symmetrical. hoop.dev gives you native tools and a recording of what happened; AccessFlow gives you a decision before anything happens, at the price of asking people to submit rather than connect. AccessFlow's roadmap lists a native wire-protocol gateway as unscheduled work, so if native-client access is a requirement today, that is a point for hoop.dev and not a gap that is about to close.

Where AccessFlow is the better fit

• You want a decision before execution, for everything. Every statement goes through routing and, unless a policy or a covering grant says otherwise, through a review plan with named stages and a minimum number of approvers per stage; nobody can approve their own request from any channel.
• Your rules should be written down and predictable. Fourteen named checks with a severity per environment, a block that always puts a person in front of the query and never silently rejects it, and, for routing, masking and row rules, a simulator that replays your own past queries to show what a draft would have changed.
• Row-level and export controls matter. AccessFlow rewrites the query so a user only gets the rows they are cleared for, and can watermark, cap or deny a download; hoop.dev documents masking but not row rewriting or export governance.
• Auditors will ask how you know the log is intact. Keyed hash chaining, an append-only database role, a verify endpoint, signed PDF and CSV reports, and a write-once S3 sink with signed segments.
• Provisioning and infrastructure as code. SCIM 2.0 user and group lifecycle and an official Terraform provider are included; neither is documented for hoop.dev.
• The same sign-off should cover API calls and releases. Outbound REST, SOAP and GraphQL calls and CI/CD deployments go through the same review pipeline and the same audit trail.

Where hoop.dev is the better fit

• One gateway for hosts, clusters and desktops. SSH, Kubernetes, remote desktop, the AWS command line and HTTP endpoints all go through hoop.dev; AccessFlow governs databases, API calls and deployments and nothing else.
• Engineers keep their tools. The tunnel daemon lets psql, DBeaver and ORMs connect by hostname with review and audit still applied; AccessFlow has no native-client path.
• Session recording with playback. A full recording of what was typed and returned, viewable in the browser, is a different kind of evidence from a per-statement audit row and is what some compliance programmes ask for.
• A low-latency sidecar for agent traffic. If an AI agent is already talking directly to PostgreSQL or an HTTP API and you want masking and a deny list inline with a few milliseconds of overhead, the sidecar does that without changing the agent.
• Runbooks and parameterised scripts. Reusable, approvable templates for routine operational tasks are a hoop.dev feature with no AccessFlow equivalent.

Licence, editions and what is gated

hoop.dev's repository is MIT licensed and its pricing page describes an open-source tier that is free, self-hosted and needs no account. The documented caps are per process: an unlicensed sidecar or gateway enforces one guardrail rule and one data-masking rule, and an Enterprise licence lifts the cap for each feature it names, adds the centralised control plane with rule sets delivered to a fleet of sidecars, and comes with support and service levels, priced per identity connecting through the gateway. The licence-management page also notes a difference in failure mode: a gateway stops serving when its licence expires, while a sidecar keeps running under the free-tier caps.

AccessFlow is Apache 2.0 in one edition. Nothing on this page is behind a licence key, there is no rule cap, and there is no control plane to buy because there is one service to run. What you give up is a vendor: support comes from the project's issue tracker and discussions, and the roadmap is public rather than contractual. What is available now and what is planned →

Running both

The natural split is by surface. hoop.dev can be the door to hosts, clusters and desktops, and the tunnel through which engineers reach databases with their own tools, while AccessFlow is where a statement goes when it needs a written decision: the query a reviewer must sign off, the change an on-call engineer wants approved at night, the request an AI agent submits over MCP, the API call or the release that should not proceed on one person's say-so. Both stream to the same SIEM, and AccessFlow's entries carry their chain hashes, so an investigator can see the recorded session on one side and the approved, verified statement on the other. If only one is on the table, decide whether you are governing sessions or governing statements.

Sources

Checked on 16 September 2026. AccessFlow's own claims come from its source repository and the pages of this site they link to. If a vendor's documentation has changed since, please open an issue and we will correct the page.

• hoop.dev repository — the MIT licence, the sidecar and gateway positioning, and the supported protocol table
• hoop.dev pricing — the open-source tier, its per-process rule caps and the Enterprise licence
• License management — what the free licence includes and how the gateway and sidecar behave on expiry
• Sidecar — the sidecar deployment model and the protocols it decodes
• Control plane — fleet management as an Enterprise feature
• Guardrails — the ordered deny list and the note that sidecar human review is not shipped
• Agentic access — the LLM analyzer, its providers and actions
• Data masking (sidecar) — the entity types, strategies and free-tier limit
• Live data masking (gateway) — the detection engines and field types
• Action access requests — command-level approval, reviewer groups and channels
• Just-in-time access requests — time-limited access with automatic expiry
• Session recording — what is recorded and how it is played back
• Hoop tunnel — native-client access by hostname and the connection types it supports
• Identity providers — the OIDC and SAML sign-in options
• SIEM integration — event forwarding
• MCP server — the built-in MCP server
• Runbooks — parameterised, reusable templates