The shift from credential brokering to runtime governance

A privileged engineer opens a session to add one customer certificate. The command runs with valid credentials. It wipes the entire certificate store. Now the company cannot decrypt the files its customers send it, and a routine support task has become an outage.

The privileged access tool did its job. It confirmed a real credential, used by a real identity, at a real time. What it could not do was tell anyone what the command would do before it ran. And it could not stop it.

That is the gap between controlling the door and controlling the room. Credential brokering decides who gets a key and who walks in. Runtime governance decides what the identity is allowed to do once it is inside, in the path of execution, while the action is happening. hoop.dev does both. It controls who gets in and for how long, then governs what they do once connected. A vault does the first and stops at the door. For twenty years that line was a reasonable place to stop. It is not anymore.

Two answers to one question: where does the control point sit?

The contrast below is not two products with different features. It is two answers to a single design question: how far does the control point reach? A vault puts it at the door, on the credential, and stops there. hoop.dev controls the door too, then carries the control point into the path of execution, onto the action itself. Almost everything else follows from how far the control reaches.

Read the left column and you get the story of why the certificate store could be wiped: the control point was at the door, so the vault confirmed the key and never saw the command. Read the right column and you get the fix. The rest of this post walks that comparison row by row.

The door model was built for a smaller problem

Tools like CyberArk vault credentials, broker access, and record sessions. They answer one question well: which credential was used. That question made sense when access meant a known human logging into a known box. Three things broke it, and each one is a place where the control point sits beside the session instead of inside it.

Out-of-band actions slip past the broker. Cron jobs, bash scripts, and ad hoc changes do not always flow through it. A security team can know a change happened and still not know who made it, when, or why. The certificate-store outage came from exactly this: a real action the vault attributed only after the damage was done, because the broker never sat in line to catch it.

"We have CyberArk, but people are still going in and changing cron jobs or running scripts, and that activity doesn't always route through it the way it should. We can tell a change happened. We can't always tell who made it, or when."

Head of Infrastructure Security, Global NeoBank

Destructive commands are invisible until they execute. With enough permissions in a cloud console, one identity can delete production and its backups in a few commands. A control point at the door confirms the credential afterward. It tells you who erased the company. It does not stop the keystroke, because it never sees the keystroke.

AI agents multiply the identities. Every coding agent or service account that inherits an engineer's credentials becomes another identity with access. A team with thirty privileged humans quietly becomes a far larger set of non-human actors, each able to touch production. The door model responds by issuing more keys. The blast radius grows with every one.

Runtime governance happens in the path of execution

hoop.dev extends the control point. It controls access at the door, who connects and for how long, the same job a vault does, then keeps governing while the action runs. The door is the part a vault also covers. The runtime is where hoop.dev goes further.

hoop.dev is a Layer 7 gateway that sits in the data path between any identity and the infrastructure it reaches: databases, servers, Kubernetes, APIs. Because it sits inline on the live connection, it can read what is actually being requested and act on it in real time. That placement is the entire point. Inline enforcement is only possible when the enforcement point is in the session, not next to it. This is what we mean by runtime governance, and it is the line that separates it from credential brokering.

hoop.dev also shrinks what sits behind the door. It grants access just in time and expires it on a schedule or after a set window, so the number of identities with live access to production stays small. That is access control, the job a vault shares. What follows is the part a vault cannot reach.

"Our production data is exactly the kind of regulated, market-sensitive information our customers expect us to protect. The delay of keeping humans in the loop as gatekeepers is completely justified for a business like ours."

Director of Enterprise Architecture, Global Compliance Software Company

Block or route a command before it runs. Change an operation from "read status" to "restart service" and hoop.dev assesses the risk inline. Low risk runs. Medium risk routes to a human in Slack, Teams, or your ticketing system for approval before execution. High risk is blocked. The destructive cloud command never reaches the API, because it runs through hoop.dev first.

Mask sensitive data in the session. hoop.dev identifies known sensitive types, like emails and phone numbers, using inference, with no need to map your schema first. For data that is not a known type, like a line of material non-public information sitting in an innocuous-looking field, you can write a contextual policy that uses a model to score the request and decide whether it runs, routes for approval, or is denied. The decision happens inline, before the data leaves.

Answer the question the vault could not. Every action is recorded with full context: who, what, when, why, the risk assessment, the data involved, and whether it was masked, all tied to a single identity. Session data streams to your SIEM in real time. "A credential was used" becomes "this identity ran this query against this data, here is the assessment, here is who approved it."

Govern humans and agents the same way. The same policy that gates a human engineer gates an agent on the same connection. As non-human identities multiply, the control point stays in one place instead of fragmenting into one key per actor.

You should not have to trust a black box

A vault asks you to trust its decisions without showing you how it makes them. We took the opposite stance. The enforcement engine is open source, so a security team can read exactly what governs its agents and its engineers before deploying it. The code is at github.com/hoophq/hoop. Small teams can run it without a contract.

That matters most for the newest part of the problem. If a model is deciding what your agents can and cannot do with production data, the last thing you want is to take that decision on faith.

It runs alongside what you already have, including CyberArk

hoop.dev does not require you to tear out your existing access stack to get value on day one. It deploys at the wire, plugs into the identity provider and permissions you already run, and works across AWS, GCP, Azure, and OCI without a months-long cataloging project. To developers it is close to invisible: many reach it through their internal developer platform and never think about it.

That includes CyberArk. You do not have to choose between them. hoop.dev runs alongside your vault, which keeps brokering credentials at the door, while hoop.dev adds runtime governance: the real-time prevention, masking, and action-level audit the vault was never positioned to do.

"We've run CyberArk for close to three years now, and it still doesn't cover everything we need it to."

Head of IT Security, Global Aerospace Manufacturing

For security and compliance teams, that means a new layer of action-level control and a clean audit trail without a migration. hoop.dev generates evidence for SOX and SOC 2 audits by recording every action, the data it touched, and the approvals behind it. It does not make anyone compliant. It gives the auditor the record. hoop.dev is SOC 2 Type II and a CNCF member.

The one thing to take away

Your vault knows which credential was used. It cannot tell you what was done with it, and it cannot stop the next destructive command before it runs, because its control point stops at the door. hoop.dev controls that same door, then carries the control point into the path of execution: the action, at the wire, in real time, for every identity including the agents now in your stack.

Read the code at github.com/hoophq/hoop, or book a walkthrough and we will map it to your stack.