AI agents are rapidly moving from tools that developers supervise to tools that work in the background, often with no one watching. That shift sounds efficient, but it introduces a security problem that has become hard to ignore: when no human is present to catch a bad decision, the system itself has to enforce safety.
The Lethal Trifecta and Why Humans Are Not the Safety Net
The danger with capable AI agents is not any single capability but the combination of three of them operating together. An agent that can access private data, process untrusted content, and communicate with external systems creates a pathway where a prompt injection or off-script behavior can escalate from a questionable output to actual data exfiltration or a destructive action.
The uncomfortable truth is that having a developer sitting at the keyboard does not eliminate this risk. A coding agent with a human present can still fetch malicious instructions from an external bug report, reach into private repositories, and communicate outward. The human might notice something suspicious, but they might not, and relying on human attention as the last line of defense is exactly the assumption that breaks down in unattended scenarios.
When the same agent runs without supervision, the margin for error shrinks dramatically. There is no one to reject an unexpected tool call, intervene when the agent takes a strange turn, or halt a session before it compounds a mistake. This combination of capabilities was first described as the lethal trifecta, and it remains a useful model because it focuses on what actually makes a bad outcome possible rather than assuming that every malicious instruction can be recognized before the agent acts on it.
How Background Agents in Production Containers Create the Problem
On modern engineering teams, background agents inside cloud development containers are being used to investigate production issues, inspect logs and data, modify code, run tests, and open pull requests, often without anyone actively supervising the session. This approach is becoming standard practice in software factories, and it is not reckless by accident. It is efficient and increasingly necessary.
But the threat model that comes with it is straightforward. A background engineering agent investigating a production incident needs access to private data. It also processes content that is not fully under anyone's control, including source code, issue comments, dependencies, tool output, logs, and information retrieved from external systems. And it needs network access to communicate with GitHub, internal services, package registries, and other systems to finish its work.
Cutting off the network would make the agent safe, but it would also make it largely useless. All three components of the trifecta are therefore present in a typical unattended agent setup, and the obvious alternatives each carry their own problems. Putting production credentials inside the container expands the agent's authority and places high-value secrets into the same environment as the model, shell, tools, and untrusted content. Requiring a human whenever production access is needed defeats much of the point of running the agent unattended in the first place.
Layer One: Access Without Credentials
The first layer of the solution follows a simple principle: give agents access to the actions they need, not the credentials behind them. Production systems are exposed through an MCP or API gateway as controlled tools, while database credentials, logging credentials, and other production secrets stay behind that gateway. The container holds an identity that lets it request approved operations, not the keys to the systems themselves.
When the agent needs to query a production database, it requests the operation through the gateway. The gateway can enforce that the call is read-only and inspect the arguments before forwarding it. The same applies to logs and other internal systems. This means the broad permissions of a credential do not automatically become the permissions of the agent. A database account behind the gateway might technically support writes, while the tool exposed to the agent supports only approved reads.
More importantly, there is no production credential inside the container for prompt injection or off-script behavior to expose. The agent could be instructed to print the password as many times as it wants, but the password simply is not there. This reduces the authority available inside the agent environment, but it does not solve the full problem, because the agent still receives sensitive data and the gateway only controls calls that actually pass through it.
Layer Two: Watching What the Gateway Cannot See
An agent does far more than call MCP tools or APIs. It reads and writes files, executes shell commands, invokes local tools, and can discover other ways to communicate. None of that activity passes through the gateway, so the agent also reports to a runtime engine. Tool calls can be evaluated before execution, providing visibility and enforcement over actions that never reach the gateway.
The distinction matters because the gateway governs access to the systems behind it, while runtime enforcement provides a control point over what the agent is doing inside its own execution environment. Containers add another useful property to this setup. The hooks configuration is baked into the image, and the workload runs unprivileged, so the agent cannot rewrite its configuration and disable the instrumentation watching it.
That said, the agent still holds private data, processes untrusted content, and maintains external communication. The first two layers reduce the risk, but the third layer addresses what remains.
Layer Three: Breaking the Trifecta Through Session-Aware Egress
The third layer adds a one-way egress restriction to the session. Once the agent accesses a source that has been marked or automatically detected as sensitive, the session becomes restricted for the remainder of its lifecycle. Before touching sensitive data, the agent operates within its normal network policy. After it touches a sensitive source, egress is locked down.
The agent can keep working during a restricted session. It can reason over production data, edit files, run tests, use approved production tools, push code to its approved repository, and open a pull request. What changes is where information can leave the session. A restricted session can communicate only with destinations approved in advance for that specific workflow.
It cannot suddenly call an arbitrary website, use a newly discovered remote tool, or send data to an unknown endpoint because something in its context instructed it to. The critical insight is that the system does not need to determine whether the agent has been compromised, classify a prompt injection, or decide whether the agent's current behavior looks malicious. The rule is deterministic: this session accessed sensitive data, so from now on it is restricted to communicating only with destinations approved for that workflow.
Why Security by Design Beats Detection
Runtime detection and protection still matter and are actively used, but the restriction does not depend on detection being correct. For this particular risk, it is more effective to remove one of the capabilities required for a bad outcome than to try to recognize every possible way the agent might reach it, which is extremely difficult to get right with a low false-positive rate.
The practical version of this idea initially sounded simpler: once the agent touches production, remove all network access. That also removes much of the reason for having the agent in the first place. A background coding agent may still need to push a branch, open a pull request, report the result of a job, or call another approved internal service, all of which are technically egress. The useful rule is therefore not that nothing leaves, but that nothing leaves through a destination that was not approved in advance.
Similarly, the trigger for the restriction does not rely on inferring whether every database, API, bucket, log source, or tool contains sensitive information. That would create another classification problem. In practice, the administrator already knows which sources are sensitive and declares them. Accessing one changes the state of the session.
The Three Questions Every Team Must Answer
Any team running unattended or mostly autonomous agents eventually has to answer three questions: can the agent reach sensitive systems without holding the credentials behind them, what controls the actions that happen outside those governed calls, and once the agent has accessed sensitive data, where is it still allowed to communicate. These three questions map directly to the three layers described above, and the answers determine whether an autonomous agent deployment is genuinely safe or merely convenient.
The risk model is the same whether somebody is watching or not. What unattended execution removes is the person who might catch the problem before the architecture does. When there is nobody to approve, notice, or stop what happens next, security by design is the only reliable way to enable autonomous agents at scale.