Dynamic Tool Denial Prompt for High-Risk Sessions

This prompt is designed for abuse detection engineers and agent platform builders who need to dynamically restrict an agent's tool access based on a real-time, cumulative risk score for a user session. Instead of a static allowlist, this prompt instructs the model to evaluate the current [SESSION_RISK_SCORE] against predefined thresholds and deny access to tools in higher-risk tiers when the score escalates. Use this when a single-turn risk evaluation is insufficient and you need the agent to respond to probing patterns, repeated policy violations, or escalating session danger. This prompt belongs in the system instructions of an agent that has already been assigned a risk score by an external evaluation service. It does not calculate the risk score itself; it enforces the tool access policy that the score dictates.

The ideal user is an engineer integrating a session-risk scoring pipeline into an agentic AI product. You should already have a risk evaluation service that outputs a numeric score per session, updated after each turn. The prompt expects that score to be injected into the [SESSION_RISK_SCORE] placeholder before the model receives the request. The prompt defines tiered tool groups—such as low-risk read-only tools, medium-risk write tools, and high-risk administrative or data-export tools—and maps score thresholds to which tiers are permitted. This approach works well when your risk model detects cumulative patterns: a user who makes three borderline requests across five turns may cross a threshold that a single-turn classifier would miss.

Do not use this prompt when you need the model itself to calculate the risk score from raw conversation history. That task requires a separate classification or evaluation prompt with its own calibration and testing. This prompt is also inappropriate for environments where tool access decisions must be made with zero-latency overhead from model inference; in those cases, enforce the policy in the application layer before the request reaches the model. Finally, avoid this prompt when your tool access policy is entirely static or role-based rather than session-risk-based—a simpler allowlist system prompt will be more reliable and easier to test. Before deploying, validate that your risk scoring service updates the score between turns and that the prompt's threshold values match the score range your service produces.

This template is designed to be injected into the system instructions of an agent operating in a high-risk session. It receives a live [CUMULATIVE_RISK_SCORE] and a tiered [TOOL_RISK_POLICY] mapping, and it must enforce progressive tool denial as the score escalates. The prompt is structured to be stateless per turn, relying entirely on the injected context for its decision, which makes it auditable and easy to test in isolation before integrating into a stateful session manager.

textCopy
You are an agent operating in a monitored session with a dynamic tool access policy.
Your available tools are defined in the [TOOL_DEFINITIONS] block. However, your permission to invoke them is governed by the current session's cumulative risk score and the tool risk policy below.

<risk_context>
Cumulative Session Risk Score: [CUMULATIVE_RISK_SCORE]
Risk Score Range: 0.0 (benign) to 1.0 (maximum risk)
</risk_context>

<tool_risk_policy>
[TOOL_RISK_POLICY]
<!-- Example policy structure:
- Risk Tier: low (score < 0.3) -> Allowed Tools: [read_file, search_docs, calculate]
- Risk Tier: medium (0.3 <= score < 0.7) -> Allowed Tools: [read_file, search_docs]
- Risk Tier: high (score >= 0.7) -> Allowed Tools: []
- Blocked tools must be denied with a structured explanation.
-->
</tool_risk_policy>

<tool_definitions>
[TOOL_DEFINITIONS]
</tool_definitions>

<instructions>
1. Before planning any action, check the current [CUMULATIVE_RISK_SCORE] against the [TOOL_RISK_POLICY] to determine the active allowlist.
2. You may ONLY invoke tools present in the active allowlist for the current risk score.
3. If a user's request requires a tool that is blocked at the current risk tier, do not invoke it. Instead, respond with a structured denial using the following JSON format:
   {
     "status": "tool_denied",
     "denied_tool": "<tool_name>",
     "current_risk_score": <float>,
     "policy_tier": "<low|medium|high>",
     "explanation": "A concise, user-safe explanation of why the tool is unavailable.",
     "safe_alternative": "<suggestion for a permitted action or escalation path, or null>"
   }
4. Do not reveal the raw risk score or internal policy thresholds to the user. Keep explanations general and helpful.
5. If no tools are permitted (allowlist is empty), you may only respond with text. Do not attempt to reason about or simulate tool outputs.
</instructions>

To adapt this template, replace the placeholders with your live application state. [CUMULATIVE_RISK_SCORE] should be a float injected by your abuse detection system at the start of each turn. [TOOL_RISK_POLICY] should be a serialized version of your tiered access rules, which can be dynamically updated without changing the core prompt. [TOOL_DEFINITIONS] should contain the standard JSON Schema function definitions for all available tools. The critical adaptation point is the policy block: ensure the thresholds and tool lists are complete and non-overlapping to prevent ambiguous gating. Before deploying, validate that the prompt correctly parses the injected policy and that the model never invokes a tool outside the computed allowlist, even under adversarial user pressure.

This prompt is not a standalone safety filter; it is a stateful enforcement layer that must be integrated into the agent's execution loop. The core idea is to maintain a cumulative session risk score that increments with each suspicious user turn and decays slowly over benign interactions. Before every tool call, the application layer injects the current risk score and the corresponding tool allowlist into the prompt, forcing the model to evaluate the proposed invocation against the current risk tier. The model never decides the risk score—the application does—but the model enforces the consequences of that score by denying, flagging, or allowing the call.

The implementation requires three tightly coupled components: a risk accumulator that updates the score based on a separate classification prompt or heuristic, a tool gating middleware that intercepts function call requests and injects the dynamic prompt block, and a structured output validator that parses the model's allow/deny/flag decision. The middleware should run after the model generates a tool call but before execution. If the model's decision is deny, the tool call is blocked and the denial reason is logged. If flag, the call is held for human review. If allow, execution proceeds. All decisions must be logged with the session ID, risk score at time of call, tool name, arguments, and model reasoning for auditability.

For testing, build a harness that replays session transcripts with known risk score progressions. Validate that: (1) a session starting at risk score 0 allows all baseline tools, (2) crossing the threshold for a restricted tool triggers a denial on the next turn, (3) a period of benign turns decays the score and restores access, and (4) a session reset clears the accumulator entirely. Common failure modes include the model ignoring the injected risk score and allowing a restricted tool anyway, or the risk accumulator failing to decay, permanently locking a user out. Both failures require monitoring alerts on denial-override events and stuck risk scores. Do not rely on the model alone to enforce safety—the middleware must act as a hard circuit breaker that blocks execution if the model's structured output does not parse or contradicts the risk tier.