LLM Tool Use Security: Runtime Policies for AI Agents

How runtime policies secure LLM tool use by checking agent identity, intent, tool, resource, parameters, and risk before each action executes.

Published 2026-04-21.

Updated 2026-04-25.

Runtime policies secure LLM tool use by checking an agent's proposed action immediately before the tool executes. They decide whether the agent should be allowed to call a function, API, MCP tool, database, SaaS integration, or credential broker for the current user, task, parameters, and risk context.

This matters because tool-using LLMs turn text into side effects. A model response is no longer just an answer. It can become a CRM query, an email, a GitHub pull request, a Slack message, a database update, a payment, or a file export.

The core security question is not "Can this model generate a tool call?" The question is: Should this exact tool call be allowed to run right now?

Why static tool permissions fail

Traditional applications have predictable paths. A user clicks a button, the application sends a known request, and the backend checks a permission. LLM agents are different. They choose tools dynamically based on prompts, context, retrieved documents, conversation history, and model reasoning.

That creates three problems:

Intent is formed at runtime. The system may not know which tool the agent will call until seconds before execution.
Inputs can be hostile. The agent may read prompt injection from email, web pages, tickets, PDFs, pull requests, or documents.
Credentials are often too broad. Agents are commonly connected to APIs through service accounts, static API keys, or broad OAuth scopes.

If security stops at "the agent has a valid credential," a manipulated agent can perform valid-looking but unsafe actions.

Runtime policies vs. guardrails

Prompt guardrails and runtime policies solve different problems. Guardrails inspect language. Runtime policies control actions.

_Runtime policies compared with prompt guardrails, schema validation, and static IAM._

Layer	What it catches	Remaining gap
Prompt guardrails	Known prompt injection patterns, unsafe instructions, policy-violating text.	They do not know whether a valid tool call should be allowed for this user and resource.
Tool schema validation	Malformed arguments, wrong types, missing fields, invalid enum values.	A syntactically valid call can still be excessive, unauthorized, or malicious.
Static IAM or RBAC	Whether the service account or role has broad permission.	It rarely sees task intent, data volume, delegated user context, or session risk.
Runtime policy	Whether this exact tool call should execute now, with these arguments, for this user.	It must be placed in the execution path and backed by reliable identity and audit data.

You need both. Prompt guardrails reduce the chance that a model produces harmful instructions. Runtime policies ensure that, even if the model produces a risky tool call, the call is checked before it reaches the protected system.

What a runtime policy sees

A useful runtime policy decision needs more than a tool name. It should receive structured context:

{
  "subject": {
    "agent_id": "support-agent",
    "user_id": "user_123",
    "organization_id": "org_abc"
  },
  "intent": {
    "task": "answer_customer_support_question",
    "source": "user_prompt"
  },
  "tool_call": {
    "tool": "crm.getCustomer",
    "action": "read",
    "resource": "customer",
    "parameters": {
      "customer_id": "cus_456"
    }
  },
  "session": {
    "ticket_id": "ticket_789",
    "human_present": true,
    "records_read_last_10m": 2
  },
  "environment": {
    "destination_domain": null,
    "risk_score": 12
  }
}

With that context, a policy can allow a narrow customer lookup while denying a bulk export or external transfer.

Runtime policy decision flow

The enforcement point belongs between the model and the tool. If the agent can bypass the policy engine and call the API directly with a long-lived secret, the policy is advisory rather than enforceable.

Example policy: support agent CRM access

A support agent should be able to read the customer record for the active ticket. It should not be able to export every customer.

{
  "id": "support-agent-read-active-customer",
  "effect": "allow",
  "when": {
    "agent.role": "support",
    "intent.task": "answer_customer_support_question",
    "tool": "crm.getCustomer",
    "action": "read",
    "parameters.customer_id_matches_ticket": true
  },
  "credential": {
    "scope": "crm.customer.read",
    "ttl_seconds": 300
  },
  "audit": "required"
}

The denial policy should be explicit:

{
  "id": "support-agent-no-bulk-export",
  "effect": "deny",
  "when": {
    "agent.role": "support",
    "tool": "crm.exportCustomers"
  },
  "reason": "Support agents may not export customer records."
}

This is stronger than giving the support agent a permanent crm.read token and hoping the model behaves.

TypeScript tool wrapper

In a TypeScript agent runtime, the policy check can wrap every tool call:

type ToolCall = {
  tool: string;
  action: string;
  resource: string;
  parameters: Record<string, unknown>;
};

type Decision =
  | { outcome: "allow"; token: string; expiresAt: string }
  | { outcome: "deny"; reason: string }
  | { outcome: "approval_required"; approvalUrl: string };

async function decide(call: ToolCall, context: {
  userToken: string;
  agentId: string;
  sessionId: string;
  intent: string;
}): Promise {
  const response = await fetch("https://authz.example.com/tool/decide", {
    method: "POST",
    headers: {
      authorization: `Bearer ${context.userToken}`,
      "content-type": "application/json",
    },
    body: JSON.stringify({
      subject: {
        agent_id: context.agentId,
        session_id: context.sessionId,
      },
      intent: context.intent,
      tool_call: call,
    }),
  });

  if (!response.ok) {
    throw new Error(`policy decision failed: ${response.status}`);
  }

  return response.json() as Promise;
}

export async function executeTool(call: ToolCall, context: {
  userToken: string;
  agentId: string;
  sessionId: string;
  intent: string;
}) {
  const decision = await decide(call, context);

  if (decision.outcome === "deny") {
    throw new Error(decision.reason);
  }

  if (decision.outcome === "approval_required") {
    return { status: "waiting_for_approval", url: decision.approvalUrl };
  }

  return callToolApi(call, decision.token);
}

The important invariant is simple: no sensitive tool execution without a fresh decision.

Policy patterns that work

1. Read narrowly, write carefully

Read actions should still be scoped. A read-only token that can read every customer, file, or repository can be enough for a serious data breach.

Write actions should usually be stricter. A good pattern is draft first, approve second. For example, an agent can draft an email or pull request automatically, but sending the email or merging the pull request requires approval.

2. Bind actions to business context

Policies should use business objects, not just API names. A policy like "support agents can call Salesforce" is too broad. A better policy is "support agents can read one account record when that account matches the active support ticket."

3. Limit volume and destinations

Many agent incidents are not about one API call. They are about scale. A runtime policy should inspect:

number of records requested
number of files downloaded
number of recipients
destination domains
external webhooks
repeated denials
unusual tool sequences

4. Use just-in-time credentials

The policy decision should be tied to credential issuance. If allowed, the system should return the narrowest credential that can complete the action. That credential should expire quickly.

This reduces blast radius because the agent does not start with standing access to everything it might need later.

5. Log every decision

Every policy decision should produce evidence:

agent identity
user identity
organization
tool and action
parameters or safe parameter summary
policy version
decision outcome
credential scope and expiration
approval record, if any

This makes runtime policies useful for security operations, compliance, and incident response.

MCP and runtime policies

The Model Context Protocol creates a natural place for runtime policy enforcement. An MCP tool call has a tool name and arguments. That structure can be sent to a policy engine before execution.

There are several enforcement patterns:

Agent runtime enforcement: the agent client checks policy before calling any MCP server.
MCP server enforcement: the server checks policy inside each tool implementation.
Proxy enforcement: a gateway intercepts MCP calls and applies central policy.
Credential broker enforcement: the MCP server requests a scoped credential only after policy allows the action.

The safest design is defense in depth. A client-side check improves developer ergonomics, but server-side or proxy enforcement prevents bypass. Credential brokering prevents the agent from holding broad secrets.

What to avoid

Avoid these anti-patterns:

long-lived API keys in agent environment variables
one service account shared across all users and sessions
broad OAuth scopes with no action-level policy
generic SQL, shell, or HTTP tools exposed to the model without constraints
approval prompts that reveal sensitive data to the wrong reviewer
logs that store raw secrets or sensitive prompts
policies that cannot explain why an action was denied

FAQ

What is a runtime policy for LLM tool use?

A runtime policy is a rule evaluated immediately before an LLM agent uses a tool. It decides whether to allow, deny, scope, or escalate the action based on identity, intent, tool, resource, parameters, session context, and risk.

Are runtime policies the same as prompt guardrails?

No. Prompt guardrails inspect language. Runtime policies control actions. Guardrails can reduce risky model outputs, but runtime policies determine whether a tool call should execute.

Where should runtime policies be enforced?

They should be enforced at the action boundary: before tool calls, API requests, credential issuance, database access, file export, external sends, deletes, and agent-to-agent delegation.

How do runtime policies help with prompt injection?

They limit the damage of prompt injection by blocking unsafe actions even when the model proposes them. A malicious instruction can still reach the model, but it cannot freely execute high-impact tool calls.

Do runtime policies require a separate policy engine?

Not always, but central policy helps. Small systems may start with application code. Larger systems should externalize policy, log decisions, version rules, and enforce consistently across agents and tools.

Securing LLM Tool Use With Runtime Policies