Machine Identities for Planner-Executor Agents: A Practical Guide

A newly hired contractor leaves the team, but the CI pipeline that runs their data‑processing jobs continues to use the same static credential that was baked into the planner‑executor configuration, exposing a missing machine identity. The next day a production outage occurs, and the root cause points to a rogue request that bypassed every policy check because the job was running under a generic service account.

In many organizations, planner‑executor agents are wired to a single long‑lived credential. The credential is stored in a configuration file or secret manager and shared across dozens of jobs. Because the identity is human‑agnostic, the system cannot distinguish which job originated a request, nor can it enforce least‑privilege rules on a per‑job basis. Auditing is reduced to a flat log line that shows the service account name, but no context about which pipeline step actually performed the operation. The result is broad standing access with no real visibility into who, or what, touched critical resources.

Why machine identity matters for planner‑executor agents

Introducing a machine identity replaces the single shared secret with a distinct, cryptographically verifiable identity for each planner‑executor instance. The identity is issued by an identity provider (OIDC or SAML) and can be scoped to the exact set of resources the job needs. This solves the problem of indistinguishable access: the gateway can now map a request back to the specific agent that issued it and apply fine‑grained policies.

However, merely having a machine identity does not automatically give you control over what the agent does once it reaches the target system. The request still travels directly to the database, Kubernetes API, or SSH server, and the target sees only the credential presented by the agent. No audit trail is captured at the point of execution, no response data is masked, and there is no opportunity to pause a dangerous command for human approval. In other words, the machine identity fixes “who” but leaves “how” and “what” unchecked.

Putting enforcement in the data path with hoop.dev

This is where a Layer 7 gateway becomes essential. hoop.dev sits between the planner‑executor agent and the target infrastructure, acting as the only place where enforcement can happen. Because hoop.dev proxies the connection, it can inspect each protocol message, apply inline masking to sensitive fields, block commands that violate policy, and route risky operations to a just‑in‑time approval workflow. Most importantly, hoop.dev records every session for replay, providing a complete audit trail that ties each action back to the originating machine identity.

When a planner‑executor job initiates a connection, hoop.dev validates the presented token, extracts the machine identity, and checks the request against the policy engine. If the request is allowed, hoop.dev forwards it to the target using its own credential, so the target never sees the agent’s secret. If the request contains a prohibited command, hoop.dev blocks it before it reaches the backend. If the request is high‑risk, hoop.dev pauses the flow and asks an authorized reviewer to approve it. All of these outcomes, session recording, inline masking, command blocking, and just‑in‑time approval, are possible only because hoop.dev occupies the data path.

Because the enforcement point is external to the agent, the agent cannot tamper with the policy checks or delete its own logs. The architecture therefore satisfies the three‑part model: setup (machine identity) decides who is making the request; the data path (hoop.dev) is the sole place enforcement occurs; and the enforcement outcomes (audit, masking, approvals) exist solely because hoop.dev sits in that path.

Teams that adopt this pattern can still use their existing CI/CD pipelines and planner‑executor frameworks. The only change is to configure the agents to obtain a machine identity token and to point their connections at the hoop.dev gateway. The rest of the workflow, building containers, scheduling jobs, and running queries, remains unchanged.

FAQ

• Do I need to modify my existing planner‑executor code? No. hoop.dev works with standard clients (psql, kubectl, ssh, etc.) and the planner‑executor agents simply direct traffic to the gateway URL.
• How does hoop.dev protect the credential it uses to talk to the backend? The gateway holds the credential internally; agents never receive it, so the backend sees only the gateway’s identity.
• Can I still run high‑throughput jobs? Yes. hoop.dev is designed to handle production workloads and can be scaled horizontally; the policy checks are lightweight and can be tuned for performance.

Getting started with this architecture is straightforward. Follow the getting‑started guide to deploy the gateway, register a machine identity for your planner‑executor agents, and define the policies that matter to your organization.

Explore the open‑source code and contribute to the project on GitHub.