In a well‑controlled environment, every planner‑executor agent runs with the minimum permissions required for its task, and every action is traceable to a specific identity. The system automatically denies operations that fall outside the agent’s role, prompts a human reviewer for risky commands, and records the entire session for later review. When those guarantees hold, the organization can trust automated workflows without fearing privilege creep or hidden data leaks. Achieving that state requires a gate that understands both the agent’s identity and the target resource, and can enforce rbac policies at the protocol level.
The getting‑started guide walks through deploying the gateway in a container environment.
Why rbac matters for planner‑executor agents
Today many teams hand a planner‑executor a long‑lived service account key or embed a static token in the workflow definition. The agent then connects directly to databases, Kubernetes clusters, or SSH hosts with full admin rights, because the surrounding orchestration layer has no visibility into the individual request. No central component logs which command was issued, which rows were read, or whether the operation matched the intended purpose. If the agent is compromised, the attacker inherits the same unrestricted access, and there is no audit trail to pinpoint the breach.
Where enforcement must happen
Introducing rbac at the identity layer solves part of the problem: the service account can be granted a role that lists allowed actions, and the orchestration system can refuse to issue a token that exceeds that role. However, the request still travels straight to the target resource, bypassing any point where the command can be inspected or a human can intervene. The gateway does not yet mask sensitive fields in query results, does not record the exact sequence of commands, and cannot enforce just‑in‑time approvals for high‑risk operations. In short, the rbac check alone does not provide the full guardrails an organization needs.
Beyond the missing inspection point, organizations also need evidence that the agent behaved as expected. Auditors ask for a chronological log that shows who initiated each query, what data was returned, and whether any step required manual sign‑off. Without a central observer, that evidence must be reconstructed from scattered system logs, which is error‑prone and often incomplete. The gap leaves compliance programs under‑documented and incident responders without a reliable replay.
How hoop.dev enforces rbac in the data path
hoop.dev sits in the data path between the planner‑executor and the target system, turning the connection into a controllable session. When an agent presents an OIDC token, hoop.dev validates the identity, looks up the rbac mapping, and decides whether the requested operation is permitted. If the action is allowed, hoop.dev forwards the traffic; if it exceeds the role, hoop.dev blocks the command before it reaches the backend. For operations that require additional scrutiny, hoop.dev can pause the request and route it to an approver for a just‑in‑time decision. Throughout the session, hoop.dev records every command and response, masks columns such as credit‑card numbers or personal identifiers, and stores the audit trail in a secure log. Because the enforcement point is outside the agent’s process, hoop.dev never sees the privileged credentials, and the organization gains complete visibility into automated workloads.
The learn site explains how masking and just‑in‑time approvals are configured.
Because hoop.dev operates at layer 7, it can parse the protocol and apply policies with fine granularity. For a PostgreSQL connection, hoop.dev can allow SELECT on a whitelist of tables while denying INSERT or UPDATE on sensitive schemas. For an SSH session, it can restrict the command line to a predefined allowlist and redact any arguments that contain passwords. These inline controls happen before the backend sees the request, guaranteeing that the policy is the final gate.
Key considerations when deploying hoop.dev for agents
Before deploying hoop.dev for planner‑executor agents, verify that the identity provider can issue short‑lived OIDC tokens and that group membership reflects the desired rbac hierarchy. Define clear role definitions that map to the specific commands the agent needs, and avoid granting wildcard privileges. Test the approval workflow with a low‑risk operation to ensure that the pause‑and‑approve mechanism works as expected. Monitor the session logs regularly to confirm that masking rules are applied and that no unauthorized commands slip through. Finally, keep the hoop.dev agent container close to the target resource to minimize latency and to ensure that the gateway always sees the full payload.
Deploying multiple hoop.dev instances behind a load balancer lets you serve thousands of concurrent agents without a single point of failure. Each instance shares the same policy store, so updates to rbac roles propagate instantly. The architecture also supports geographic redundancy, keeping the data path close to the protected resources and reducing latency for high‑throughput workloads.
Finally, treat the rbac policy as living documentation. When a new service is added or an existing workflow changes, update the role definitions in hoop.dev promptly. The gateway can reload policies without downtime, ensuring that agents always operate under the latest constraints. Regularly review the session logs to spot patterns that may indicate over‑privileged roles and adjust them accordingly.
FAQ
- Can existing IAM policies replace hoop.dev’s rbac enforcement? Existing IAM policies control who can obtain a token, but they do not inspect the actual command, mask data, or record the session. hoop.dev provides those enforcement outcomes in the data path.
- Does hoop.dev store the planner‑executor’s secret keys? No. The gateway holds the credential needed to reach the backend, while the agent never sees it, which prevents credential leakage.
- What happens when a command is blocked? hoop.dev returns an error to the client, logs the attempt, and, if configured, notifies an approver for a manual override.
Explore the source code on GitHub to get started.
