With approval workflows in place, autonomous agents authenticated via Entra can only act after a human reviewer validates each high‑risk request, and every interaction is recorded for audit.
Why approval workflows matter for autonomous agents
Teams often give service accounts or AI agents a static Entra token and let them talk directly to databases, Kubernetes clusters, or SSH endpoints. The token proves identity, but once the connection is established the agent can execute any command it knows, modify data, or pivot laterally without any visibility. In practice this means a compromised credential instantly grants unrestricted access, and there is no evidence of what the agent did.
What Entra provides and what it leaves open
Entra (or any OIDC/SAML provider) supplies the identity token that tells the system *who* is making the request. That is the essential setup: the token is verified, groups are read, and the request is allowed to start. However, identity alone does not enforce policy on the data path. The request still reaches the target resource directly, bypassing any gate that could require a human sign‑off or record the activity.
How hoop.dev adds approval workflows to Entra‑based agents
hoop.dev sits in the Layer 7 gateway between the Entra‑issued identity and the infrastructure resource. Because the gateway intercepts the wire‑protocol traffic, it is the only place where enforcement can occur. When an autonomous agent initiates a command that matches a policy‑defined risk pattern, hoop.dev pauses the request, creates an approval ticket, and routes it to a designated reviewer. The reviewer can approve, deny, or modify the request before it continues. This entire flow is driven by hoop.dev; without the gateway the agent would never be stopped.
In addition to the explicit approval step, hoop.dev records the full session, captures the exact command line, and stores the response for replay. Sensitive fields in the response can be masked in real time, ensuring that downstream logs never expose secrets. Because the gateway holds the credential for the target resource, the agent never sees the password or private key, further reducing the blast radius of a compromised token.
Designing effective approval policies
Approval policies are defined per connector. For a PostgreSQL database you might require approval for any DROP DATABASE or ALTER ROLE statements. For Kubernetes you can flag kubectl delete or kubectl exec into privileged pods. The policy language lets you combine command patterns, target namespaces, and user groups, so you can tailor the workflow to the risk profile of each service.
Because the policy lives in hoop.dev, you can change it centrally and have the change take effect for every Entra‑authenticated agent instantly. This eliminates the need to patch each individual service or rotate credentials when a new rule is added.
Integrating approval workflows with CI/CD pipelines
Many organizations trigger database migrations or infrastructure changes from automated pipelines. By routing those pipeline jobs through hoop.dev, you keep the same approval guardrails that apply to ad‑hoc agent activity. A pipeline that attempts to run a destructive migration will be paused, a ticket created, and a release engineer can give the final go‑ahead before the change is applied.
This approach preserves the speed of automation while still enforcing human oversight on the most critical actions, a balance that pure “no‑approval” pipelines cannot achieve.
Scaling the gateway for many agents
hoop.dev is designed to run as a containerized service that can be replicated behind a load balancer. Each replica shares the same policy store, so approval decisions are consistent regardless of which instance handles the request. The gateway’s stateless design means you can add capacity as the number of Entra‑based agents grows, without changing the approval logic.
Security considerations beyond approval
While approval workflows address the risk of unauthorized actions, hoop.dev also provides complementary controls. Session recording gives you a forensic trail; inline masking prevents sensitive data from leaking into logs; and just‑in‑time credential handling ensures that agents never hold long‑lived passwords. Together these controls create a defense‑in‑depth posture that goes far beyond a simple token check.
Getting started
To wire Entra identities through hoop.dev, deploy the gateway using the provided Docker Compose or Kubernetes manifests, configure Entra as the OIDC provider, and register the target resources you want to protect. Detailed steps are available in the getting‑started guide and the broader feature overview on the learn site. The repository contains all the manifests and example policies you can adapt.
FAQ
- Do I need to change my existing Entra applications? No. hoop.dev consumes the existing OIDC tokens; you only add the gateway in front of the target services.
- Can I require approvals for only a subset of commands? Yes. Policies are defined per connector, so you can target risky SQL statements, privileged kubectl verbs, or specific SSH commands.
- What happens to the session data? hoop.dev stores a replay‑able log that includes timestamps, user identity, and the approved command. The log can be exported for compliance reporting.
- Will the gateway add latency? Because hoop.dev operates at Layer 7 and only inspects protocol messages, the added latency is typically measured in milliseconds, which is negligible for most workloads.
- How do I audit who approved a request? Each approval ticket records the approver’s Entra identity, the time of decision, and the rationale provided, all visible in the session record.
For the full source code, contribution guidelines, and to explore additional policies, visit the GitHub repository.
