When subagents operate under a transparent policy, every request they make is tied to an identity, every response can be inspected for sensitive data, and any risky command is stopped before it reaches the target system. In a well‑governed environment, shadow ai is visible: each AI‑driven assistant’s actions are logged, masked, and approved. That is the ideal state for teams that let AI‑driven assistants act on their behalf.
In practice, many organizations embed subagents directly into scripts or CI pipelines and hand them long‑lived credentials. Those bots connect straight to databases, Kubernetes clusters, or SSH hosts without any intermediate check. The credential is often a static password or API key stored in a repository, and the subagent runs with the same broad permissions it inherited from the original engineer. Because there is no gate, the team cannot tell who triggered a query, what data was returned, or whether a dangerous command was issued. The result is a blind spot that can be exploited for data exfiltration or lateral movement.
The core precondition for solving this problem is the existence of a non‑human identity for the subagent. By assigning each bot its own OIDC or SAML token, the system can at least know *who* the request claims to be. However, without placing enforcement on the data path, the request still travels straight to the target, the token is simply presented, and the target honors it without any audit, masking, or approval step. The setup alone does not prevent a compromised subagent from issuing destructive commands or leaking PII.
Shadow AI and subagents: the core challenge
shadow ai describes the phenomenon where an AI‑driven subagent performs actions that are invisible to the human operators who delegated the task. The subagent may generate queries, modify configurations, or extract logs, all while the originating engineer assumes the operation is safe because the bot holds a privileged token. The challenge is two‑fold: first, the identity of the subagent must be verifiable and scoped; second, the actual traffic must be inspected and controlled before it reaches the target system. Without a gateway that sits in the middle, the organization cannot enforce just‑in‑time approvals, block dangerous commands, or mask sensitive fields in real time.
Why the data path matters
Setup components such as OIDC identity providers, service accounts, and role‑based policies decide *who* may start a connection. They are necessary, but they do not provide enforcement. The only place to examine the payload, SQL statements, HTTP requests, or shell commands, is the data path that carries the traffic from the subagent to the resource. By inserting a Layer 7 gateway at that point, the system gains visibility into every request and response, enabling policy checks that are impossible to implement on the target side alone.