How do organisations decide where to place controls across the prompt, code, and runtime phases of agentic systems?

The best approach is layered control. Use prompt-time governance to limit what agents can do and what they can access, use code security to validate what gets built, and use runtime enforcement to stop or contain harmful behaviour in production. A single control point is not enough because agentic risk changes as decisions move from intent to execution.

Why This Matters for Security Teams

Agentic systems create risk at three different moments: when instructions are formed, when code and workflows are built, and when the system actually executes. That means control placement is not just a design preference, it is a governance decision that affects safety, containment, auditability, and blast radius. Guidance such as the NIST AI Risk Management Framework supports this layered view by pushing teams to manage risk across the full lifecycle rather than relying on one safeguard.

Practitioners often overestimate prompt-time restrictions and underestimate how easily unsafe behaviour reappears through tools, code paths, or runtime side effects. Prompt controls are useful for shaping intent, but they do not verify implementation integrity or stop a compromised dependency from changing behaviour later. Likewise, code review can miss emergent runtime misuse when an agent chains tools in ways the developer did not anticipate. The practical question is not which layer is strongest in theory, but where each layer can fail safely when the others are bypassed.

In practice, many security teams encounter agentic risk only after a tool call, data exfiltration attempt, or unintended action has already occurred, rather than through intentional design of layered control boundaries.

How It Works in Practice

Effective placement starts by mapping the agent’s lifecycle and then assigning controls to the stage where they are most enforceable. Prompt-time controls should constrain objectives, tool eligibility, data scope, and escalation conditions. Code-time controls should validate orchestration logic, dependency integrity, secrets handling, and guardrail enforcement. Runtime controls should monitor outputs, tool calls, network activity, and privilege use so that harmful behaviour can be blocked, rate-limited, or terminated before impact spreads.

This is closely aligned with the control logic behind the OWASP Agentic AI Top 10 and the attack patterns catalogued in the MITRE ATLAS adversarial AI threat matrix. Prompt-time controls are best for policy expression, but they should not be treated as enforcement. Code controls are strongest when developers can assert invariants, such as “this agent may only call these tools with these argument types.” Runtime controls become the final containment layer, especially when agents have access to sensitive data, external APIs, or action-taking permissions.

• Use prompt controls to define intent boundaries, approved tools, and disallowed data classes.
• Use code controls to validate prompt templates, workflow logic, dependency trust, and secrets exposure.
• Use runtime controls to inspect actions, enforce allowlists, and stop unsafe tool chaining.
• Log decisions at each layer so incident responders can reconstruct intent, implementation, and execution.

Security teams should also treat human approval as a control layer only when the approval is meaningful, specific, and tied to high-risk actions, not as a generic override. These controls tend to break down when agents are given broad tool access in loosely governed SaaS environments because the runtime can execute actions faster than policy review can intervene.

Common Variations and Edge Cases

Tighter controls often increase friction, latency, and engineering overhead, requiring organisations to balance safety against delivery speed. There is no universal standard for exact control placement yet, especially for fast-moving agentic architectures where best practice is still evolving. The right design depends on whether the system is advisory, semi-autonomous, or capable of executing transactions without approval.

In high-risk environments, runtime containment usually deserves the strongest emphasis because prompt constraints alone cannot stop tool misuse or emergent chaining. In lower-risk internal assistants, code review and prompt governance may carry more weight than live enforcement, provided the agent has minimal privilege and no external side effects. For regulated or high-impact use cases, current guidance suggests aligning this model with formal risk management such as the CSA MAESTRO agentic AI threat modeling framework and, where implementation controls are needed, NIST SP 800-53 Rev 5 Security and Privacy Controls.

Edge cases appear when a single agent spans multiple trust zones, such as development, production, and external SaaS tools. In those environments, a control that works at prompt time may be irrelevant at runtime if the agent can re-plan, call a new tool, or inherit a broader token than the original design assumed. In practice, the best placement is the one that fails closed at the earliest enforceable point.

Related resources from NHI Mgmt Group

• How do organisations decide between verification and runtime controls for AI systems?
• Why do agentic systems need both runtime controls and event governance?
• How should teams decide where to place prompt injection controls?
• How should organisations decide whether existing identity controls are enough for agentic AI?