Nested agents: what they mean for your data exfiltration (on Postgres)

Many teams assume that once a PostgreSQL client is launched, any subprocess it spawns automatically inherits the same security guarantees. In reality, a nested agent can bypass the original access controls and open a covert channel for data exfiltration.

When a service account runs a psql session and then invokes another client, perhaps a backup script, a data‑science notebook, or an automated export tool, the second process often connects directly to the database using credentials cached on the host. The original authentication event is no longer visible, and the database sees a new connection that appears legitimate because it presents the same static password or IAM role. This pattern is common in CI pipelines, ad‑hoc debugging sessions, and AI‑assisted workflows where a language model triggers a downstream query.

Why data exfiltration risk rises with nested agents

Nested agents create three distinct gaps:

• Credential leakage: The first process may expose its secret to the child, intentionally or through environment inheritance.
• Untracked queries: The database treats the child connection as a fresh session, so any audit trail tied to the original user disappears.
• Blind data export: Export tools can issue COPY or SELECT … INTO statements that stream full tables to the attacker’s host without triggering existing monitoring.

Because the child process bypasses the original authentication checkpoint, traditional IAM policies and role‑based access controls cannot stop it. Even if the parent user’s token is short‑lived, the child inherits the same static secret and can run for hours.

What a proper data path looks like

The missing piece is a control surface that sits on the actual network path between the identity provider and PostgreSQL. The setup that issues tokens and defines least‑privilege roles decides who may start a connection, but it does not enforce anything once the TCP stream is open. Without a gateway in the data path, the request reaches the database directly, leaving no place to audit, mask, or block suspicious commands.

hoop.dev as the enforcement layer

hoop.dev inserts itself as a Layer 7 proxy that terminates the client connection, validates the OIDC token, and then forwards traffic to PostgreSQL. Because all traffic flows through hoop.dev, it becomes the only point where policy can be applied.

hoop.dev records each session, preserving a replayable audit trail that shows exactly which user initiated the export and what statements were executed. It masks sensitive columns in query results, so even if a nested agent attempts to pull credit‑card numbers, the response is redacted in real time. When a query matches a pattern for bulk data movement, hoop.dev routes the request to a just‑in‑time approval workflow, requiring a human reviewer before the export proceeds. If a command looks like a destructive DROP or an unexpected COPY TO STDOUT, hoop.dev blocks it outright.

Because the gateway holds the database credential, the downstream PostgreSQL server never sees the secret. This guarantees that even a child process cannot extract the password from the environment, and the agent running inside the network cannot read it either.

Getting started with hoop.dev for PostgreSQL

Deploy the gateway using the Docker Compose quick‑start, then register your PostgreSQL instance as a connection. The documentation walks you through OIDC configuration, connection registration, and policy definition. For a step‑by‑step walkthrough, see the getting‑started guide and the broader feature overview on the learn site. The open‑source repository provides the full source code and example configurations.

FAQ

Do nested agents still work when hoop.dev is in place?

Yes. hoop.dev does not block legitimate subprocesses; it simply ensures that every downstream connection is mediated, audited, and subject to the same policies as the original request.

Can hoop.dev mask data during a bulk export?

hoop.dev can apply inline masking rules to result sets, so sensitive fields are redacted before they leave the database, even for large copy operations.

What logs does hoop.dev generate for auditors?

hoop.dev emits a per‑session log that includes the authenticated user, timestamp, executed statements, and any approval decisions. These logs can be streamed to your SIEM or retained for compliance reporting.

Explore the code and contribute to the project on GitHub.