What breaks when code execution is driven by agent context instead of review gates?

Review gates lose visibility when execution is generated at runtime from context, memory, or retrieved data. Security teams no longer have a stable artifact to inspect before production. That breaks assumptions about traceability, approval timing, and separation between data and instructions, which is why runtime controls and provenance tracking become essential.

Why This Matters for Security Teams

When code execution is driven by agent context, the control problem shifts from approving a known change set to governing a moving decision stream. That matters because review gates depend on stable artefacts: a diff, a ticket, a signed package, or a change window. Once an agent can assemble instructions from memory, retrieved content, or live tool output, the security team may not know what exactly was executed, why it was selected, or whether a human ever saw it.

This is where classic approval workflows start to fail. A review gate can confirm that a prompt, policy, or workflow was acceptable at one moment, but it may not capture the downstream actions the agent generates after retrieval and context accumulation. Guidance in the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward the same operational reality: provenance, traceability, and bounded authority matter more than one-time approval alone.

In practice, many security teams discover this only after an agent has already executed an unreviewed action path that no traditional change board ever explicitly approved.

How It Works in Practice

The practical break point is the loss of a predictable approval boundary. In a normal software delivery flow, a reviewer inspects code, configuration, or policy before release. In an agentic system, execution may emerge from a chain of retrieved documents, memory state, tool outputs, and dynamic planning decisions. The final action can be technically valid yet operationally surprising, especially if the agent is allowed to call tools, write files, invoke APIs, or trigger workflows without a separate runtime control plane.

Security teams usually need to split control into three layers:

• context governance, so the agent only sees approved sources and bounded memory;
• execution governance, so tool use, command generation, and side effects require policy checks at runtime;
• provenance logging, so every instruction source and action is traceable after the fact.

That approach aligns with the MITRE ATLAS adversarial AI threat matrix, which is useful for mapping prompt injection, data poisoning, and tool abuse to concrete failure modes. It also fits the CSA MAESTRO agentic AI threat modeling framework, where control placement is tied to agent lifecycle and trust boundaries.

Where teams get into trouble is assuming that a review gate on the prompt, policy file, or code template is enough. Once context can change at runtime, the real decision surface becomes the combination of retrieval results, memory contents, and execution permissions. These controls tend to break down in highly dynamic integrations, such as autonomous ticket handling or API orchestration across multiple SaaS systems, because the effective instruction set is assembled after the review step has already closed.

Common Variations and Edge Cases

Tighter runtime control often increases latency, operational overhead, and false rejection rates, so organisations have to balance agility against assurance. Best practice is evolving here, and there is no universal standard for how much autonomy should be allowed before a human review is mandatory.

Some teams only need approval for high-risk actions, such as credential creation, privilege escalation, payments, or production changes. Others require review for any action that crosses a trust boundary or touches regulated data. The right threshold depends on how much blast radius the agent has, how reliable the retrieval layer is, and whether the organisation can prove what source material shaped the action.

Two edge cases are especially important. First, if an agent is operating over stale memory or cached retrieval, the issue may not be malicious intent but outdated context causing unsafe execution. Second, if the system is designed for human-in-the-loop review but the human only sees a summarised action instead of the full provenance trail, the gate becomes ceremonial rather than protective. The OWASP Top 10 for Agentic Applications 2026 is a useful reference for these trust-boundary failures, and the Anthropic report on AI-orchestrated cyber espionage shows why runtime checks matter when adversaries actively shape context.

When agent context drives execution, the question is not whether review happened, but whether the review saw the same decision inputs the agent later used.

Related resources from NHI Mgmt Group

• What breaks when agent permissions rely on command patterns instead of execution semantics?
• What breaks when source-code review is used instead of mobile testing?
• What breaks when sandbox validation does not match actual execution in agent systems?
• What breaks when audit logs do not capture agent delegation and decision context?