Use the gateway boundary for controls that cannot be allowed to vanish, such as outbound data restrictions, tool permissions, and budget limits. Keep prompts for steering, not for enforcing the controls that must survive compaction. The clean split is durable enforcement outside the context and conversational guidance inside it.
Why the Enforcement Boundary Matters
The question is really about where a control still exists when the model’s context changes. Prompts can steer behaviour, but they are not a durable enforcement layer. If a rule must survive compaction, tool switching, retries, or a different prompt author, it belongs outside the context where the system actually decides whether an action is allowed.
That distinction matters because many agent controls are not advisory. Outbound data restrictions, tool permissions, approval gates, and budget caps need a boundary that can be checked every time an action is attempted. A prompt can request restraint; a gateway can enforce it.
A useful way to think about the split is that prompts shape intent while the gateway shapes admissible execution. When those two are confused, teams often assume they have control coverage simply because the model was instructed to behave. In practice, instructions can be bypassed by prompt injection, overwritten by orchestration changes, or lost when the conversation is summarized.
What Belongs in Prompts, and What Belongs at the Gateway
Prompts are best used for guidance that improves agent judgment inside a session: task framing, preferred workflows, user-facing tone, or conditional reminders about policy. They are appropriate when the control is soft, contextual, or meant to influence behaviour rather than block it.
The gateway boundary is the right place for controls that must remain true regardless of the prompt content. That includes outbound network restrictions, data-loss controls, tool allowlists, per-action authorization, spending thresholds, environment separation, and request-level policy checks. These controls should be evaluated at the point of execution, not merely stated in text.
This is why gateway-mediated authorization is the cleaner pattern for agent permissions. If the agent can ask for a tool, send data, or spend money, the decision should be made by policy enforcement that sits outside the model’s context. NHIMG’s AI Agent Authorisation Guide is a practical reference for task-scoped access, just-in-time privilege, and per-action decisions. For boundary enforcement in protocol-heavy environments, MCP Security Guide shows why gateways are where token passthrough, tool access, and policy checks become enforceable controls rather than conversational advice.
The same logic applies when agents act on behalf of people. If the authority model depends on who requested the action, the boundary must verify the principal and the request, not rely on prompt text to preserve intent. Zero Trust for AI Agents is useful here because it treats verification and least privilege as runtime properties, not prompt conventions.
How to Decide the Right Split in Practice
Use prompts when you want the model to prefer a behaviour. Use the gateway when you need the system to refuse an action. If the control failure would create data exposure, unauthorized tool use, or unbounded spend, a prompt is not strong enough on its own.
That distinction becomes even more important once the agent uses external tools, browsers, or delegated credentials. At that point, a prompt is only one influence on behaviour, while the real blast radius is determined by what the gateway will permit. NHIMG’s AI Agent Observability, Audit and Incident Response Guide helps with the complementary question of what must be logged and attributable when enforcement fails or is bypassed.
For teams building or buying an agent platform, the operational test is simple: ask whether a malicious or malformed prompt could still cause the control to disappear. If the answer is yes, the control is misplaced. A prompt can explain the policy, but only the boundary can preserve it under attack, transformation, or drift.
Risk and Threat Considerations
Relying on prompts for hard controls creates a brittle security posture. Prompts can be ignored, truncated, overridden by system changes, or manipulated through indirect prompt injection, while gateway checks continue to hold if they are enforced outside the model’s context.
Failure mechanism: The agent receives a conversational instruction that looks like policy, but the actual execution path has no independent gate, so the next tool call, data egress, or spend event is allowed even when the prompt is altered or missing.
Impact: Organisations can lose control over outbound data, tool use, and budget exposure, especially when the same agent is reused across tasks or environments and the prompt is treated as the primary control surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent controls here hinge on runtime privilege and enforceable authority boundaries. |
| ASI02 — Tool Misuse | Gateway checks prevent unsafe tool calls that prompts alone cannot reliably block. | |
| ASI09 — Human-Agent Trust Exploitation | Prompt-only controls are vulnerable when users or content steer the agent into unsafe actions. | |
| Recommendation — Enforce per-action authorization and least privilege at the gateway, not in prompts. Gate every tool invocation with policy before the agent can execute it. Move trust-sensitive approvals and refusals out of conversational instructions. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The question is fundamentally about where access decisions must be enforced. |
| AC-6 — Least Privilege | Agent permissions should be limited by runtime policy, not prompt wording. | |
| AU-2 — Event Logging | Boundary enforcement should be observable and auditable when agents act or are denied. | |
| Recommendation — Enforce access decisions at the boundary that mediates the action. Constrain agent capabilities to the minimum needed for each request. Log authorization decisions and blocked actions at the enforcement point. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Zero Trust Architecture | Zero trust places verification and policy enforcement outside the trusted context. |
| Recommendation — Verify each request independently before allowing tool or data access. | ||
| OWASP ASVS | V8 — Authorization | The core issue is whether authorization is enforced by policy or merely described in text. |
| V16 — Security Logging and Error Handling | Boundary controls need evidence when a request is blocked or permitted. | |
| Recommendation — Centralize authorization checks outside the application prompt layer. Record denied and allowed actions at the enforcement boundary. | ||
Practitioner Guidance
What to prioritise: Put every irreversible or high-blast-radius rule behind a request-time policy decision. If the action can leak data, invoke a tool, or incur cost, enforce it where the action is approved, not where the conversation is written.
What to verify: Check that the gateway can independently deny the action even when the prompt is empty, summarized, or rewritten. A good test is to remove the instructional text and confirm that the same refusal or approval outcome still occurs.
Common mistake: Teams often use prompts to document policy and then assume they have implemented policy. That shortcut is acceptable only for guidance; it is unsafe for enforcement.
Practitioner takeaway: Treat prompts as a coordination layer and the gateway as the control plane, because only the latter survives context loss, prompt manipulation, and agent reuse.