Function Call Blocklist Enforcement Prompt

This prompt is designed for security engineers and agent platform builders who need to enforce a dynamic blocklist of prohibited function calls or argument patterns at the model level. The primary job-to-be-done is preventing an agent from invoking specific tools, APIs, or function signatures that have been flagged as high-risk, regardless of the user's role or the agent's other permissions. This is a defense-in-depth measure that sits between the agent's reasoning layer and the tool execution layer, catching disallowed invocations before they reach the runtime.

Use this prompt when you maintain a blocklist that changes over time—for example, when a new vulnerability is disclosed in an internal API, when a deprecated function must be retired across all agents, or when specific argument patterns (such as rm -rf or unescaped SQL fragments) must be denied even if the function itself is normally allowed. The prompt expects a structured [BLOCKLIST] input containing function names, argument regex patterns, and optional risk metadata. It is not a replacement for tool-level authorization or sandboxing; it is a prompt-level enforcement layer that adds a second check. Do not use this prompt as the sole security control for high-risk production systems—always combine it with runtime guards, audit logging, and human review for irreversible actions.

Before deploying this prompt, ensure you have a reliable mechanism for updating the [BLOCKLIST] placeholder with fresh entries and for logging every denial decision with the matched rule. Common failure modes include blocklist bypass through function aliasing (e.g., calling a wrapper that invokes the blocked function indirectly), argument encoding (e.g., base64-encoded payloads that evade regex patterns), and prompt injection that attempts to override the blocklist instructions. Your eval suite should include adversarial test cases for each of these bypass vectors. If your blocklist grows beyond a few dozen entries, consider moving enforcement to a pre-execution validation layer in your application code rather than relying solely on model attention to catch every match.

This prompt template is designed to be inserted into your agent's system instructions or placed as a pre-flight check before any tool execution. It instructs the model to act as a security enforcement layer that inspects every proposed function call against a configurable blocklist. The blocklist can target specific function names, dangerous argument patterns, or combinations of both. The prompt is structured to produce a structured JSON decision that your application harness can parse and act on before the tool is ever invoked.

textCopy
You are a function call security enforcer. Your sole task is to inspect a proposed function call and determine if it matches any entry on the active blocklist. You must deny any invocation that matches, regardless of other permissions, user role, or prior context. You must also detect and deny attempts to bypass the blocklist through aliasing, encoding, or indirect invocation.

## BLOCKLIST
[BLOCKLIST]

## PROPOSED FUNCTION CALL
Function Name: [FUNCTION_NAME]
Arguments: [FUNCTION_ARGUMENTS]
Calling Agent: [AGENT_ID]
User Context: [USER_CONTEXT]
Session Risk Score: [SESSION_RISK_SCORE]

## INSTRUCTIONS
1. Check if [FUNCTION_NAME] exactly matches any blocked function name in the BLOCKLIST.
2. Check if [FUNCTION_NAME] is an alias, wrapper, or indirect path to a blocked function. Consider common aliasing patterns such as renamed imports, dynamic dispatch, or reflection-based invocation.
3. Check if [FUNCTION_ARGUMENTS] contain any blocked argument patterns defined in the BLOCKLIST, including encoded, obfuscated, or base64-encoded versions of blocked values.
4. Check if the combination of [FUNCTION_NAME] and [FUNCTION_ARGUMENTS] matches any compound blocklist rule.
5. If any check matches, the decision is DENY. Otherwise, the decision is ALLOW.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with no additional text:
{
  "decision": "ALLOW" | "DENY",
  "matched_rule_id": "string | null",
  "match_type": "exact_function_name" | "alias_detected" | "argument_pattern" | "compound_rule" | "none",
  "denial_reason": "string | null",
  "bypass_attempt_detected": true | false,
  "bypass_method": "string | null"
}

To adapt this template, replace the [BLOCKLIST] placeholder with your actual blocklist definition. The blocklist should be a structured list of rules, each with a unique ID, the function name or pattern to block, the match type, and an optional argument pattern. For example: [{"rule_id": "BLK-001", "function_name": "execute_shell_command", "match_type": "exact_function_name"}, {"rule_id": "BLK-002", "function_name": ".*", "match_type": "argument_pattern", "argument_pattern": "rm -rf /"}]. The [FUNCTION_NAME] and [FUNCTION_ARGUMENTS] placeholders should be populated by your application harness with the actual proposed tool call before this prompt is sent to the model. The [AGENT_ID], [USER_CONTEXT], and [SESSION_RISK_SCORE] placeholders provide additional context that can help detect context-dependent bypass attempts, such as a low-privilege agent attempting to call a function through a higher-privilege proxy. After receiving the model's JSON response, your harness must parse the decision field and block execution if it is DENY. Log every decision, especially denials with bypass_attempt_detected set to true, for security auditing. Do not rely solely on this prompt for security; it is one layer in a defense-in-depth strategy that should also include application-level enforcement.

This prompt is designed to act as a pre-execution gate, not a post-hoc auditor. It must be invoked after the model proposes a function call but before that call is executed by the runtime. The harness should intercept the proposed tool name and arguments, inject them into the [PROPOSED_FUNCTION_CALL] placeholder, and evaluate the model's structured output (an allow or deny decision) to determine whether to proceed. Because this is a security-critical control, the default behavior on any parsing failure, timeout, or model error must be deny—a fail-closed posture prevents blocklist bypasses caused by infrastructure glitches.

The implementation requires a strict validation layer around the model's output. Parse the response into a typed object with a boolean allowed field and a string reason field. If the model returns allowed: false, log the denial reason, the full function call payload, and the session ID, then return a controlled error to the agent loop without revealing the blocklist contents to the user. If the model returns allowed: true, perform a secondary, non-LLM check: a deterministic string match of the function name against the canonical blocklist stored in your application config. This defense-in-depth step catches cases where the model hallucinates an allow decision for a blocked function. Only after both the model check and the deterministic check pass should the function call proceed to execution.

For model selection, prefer a fast, inexpensive model (such as GPT-4o-mini, Claude Haiku, or a fine-tuned small classifier) because this gate adds latency to every tool call. The prompt's structured output requirement means you should set response_format to JSON mode or use function/tool calling to enforce the schema. Implement a short timeout (under 2 seconds) and a single retry on transient failures; if the gate cannot make a decision within the latency budget, deny the call and escalate to an on-call channel if the denial rate spikes. Log every decision—allow and deny—to an append-only audit store with the model's reasoning, the deterministic check result, the session context, and a timestamp. These logs are essential for tuning the blocklist, investigating bypass attempts, and demonstrating policy enforcement to auditors.

The blocklist itself should be maintained outside the prompt in a configuration store (environment variable, feature flag, or database) and injected into the [BLOCKLIST] placeholder at runtime. Never hardcode the blocklist in the system prompt. When updating the blocklist, deploy the new list to the configuration store first, then roll out the prompt change; this decoupling lets you revert the blocklist independently if a new entry causes excessive false positives. Test the harness with the adversarial cases described in the prompt's test suite—particularly alias attacks (calling a blocked function through a wrapper or renamed import) and encoding attacks (base64-encoded arguments that hide blocked parameter patterns). If the model fails these tests, do not weaken the blocklist; instead, add the bypass pattern to the deterministic check layer or escalate to a human reviewer until the prompt can be hardened.