ai agent security/tool security

16 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Tool security: least privilege principle

Grant agents the minimum tools required for their specific task. Implement per-tool permission scoping (read-only vs. write, specific resources). Use separate tool sets for different trust levels (internal vs. user-facing agents). Require explicit tool authorization for sensitive operations.

Tool configuration: allowlist vs wildcard

Bad practice: tool configuration with 'allowed_commands': '*' grants unrestricted shell access. Good practice: restrict to specific safe commands with 'allowed_paths' listing permitted directories (e.g., '/app/reports/*'), 'allowed_operations' defining allowed actions ('read' only), and 'blocked_patterns' excluding sensitive files (e.g., '*.env', '*.key', '*.pem', '*secret*'). Use explicit allowlists rather than wildcards.

Tool authorization middleware: require_confirmation decorator pattern

Implement decorator-based authorization for sensitive tools. Define SENSITIVE_TOOLS list including operations like 'send_email', 'execute_code', 'database_write', 'file_delete'. Before execution, check if context.get('user_confirmed') is true for tools in the sensitive list. If not confirmed, return status 'pending_confirmation' with sanitized parameters for display, requiring user approval before proceeding.

Pin all GitHub Actions and reusable workflow versions with commit hash

Always pin all action and reusable workflow versions with a commit hash, not tags or branch names. Verify that the used commit belongs to the specified organization/repository to prevent dependency confusion attacks. GitHub resolves commit SHA, finds a matching object and executes it regardless of which fork it originated from. The Zizmor 'impostor-commit' rule can automate this check.

Minimize third-party GitHub Actions usage

Minimize third-party actions usage. Use the GitHub API in workflows when possible to implement required logic. When using third-party actions, verify the origin, check that the author is trusted and active with multiple active contributors, ensure the code is stable and safe, and verify the action does not require unnecessary permissions.

Automated dependency update tools for GitHub Actions

Use tools such as Dependabot or Renovate to keep third-party GitHub Actions up to date. Configure a delay between a dependency release and adoption (e.g., a few days) to avoid immediately pulling in newly published malicious or compromised versions. Dependabot has a 'cooldown' flag; Renovate has a 'minimumReleaseAge' flag for this configuration.

Agent tool call validation for prompt injection defense

For LLM agents with tool access, implement validation: validate tool calls against user permissions and session context, implement tool-specific parameter validation, monitor agent reasoning patterns for anomalies, restrict tool access based on principle of least privilege.

Action screening guardrail placement for agent systems

For agent systems, evaluate each proposed tool call against the original user intent. A guardrail that sees only the user's task and the action the agent wants to take, without the untrusted intermediate context, will refuse actions that drifted because of an injected instruction.

mcp-scan tool for detecting poisoned tools

mcp-scan is a security scanner that automatically detects poisoned tool descriptions and cross-server shadowing in MCP server installations. It is recommended for automatically analyzing and monitoring installed servers for malicious behavior or changes.

User Confirmation for High-Risk Tool Invocation

Require explicit user confirmation for high-risk actions triggered by RAG-influenced model output such as payments, data deletion, and external API calls.

Tool-Level Authorization Independent of Model

Enforce tool-level authorization checks independently of model decisions. The model deciding to call a tool is not the same as the user being authorized to use that tool.

Tool Allowlist per Context

Maintain an allowlist of permitted tools per context. A customer support RAG agent should not have access to payment tools.

Circuit Breakers for Anomalous Tool Execution

Implement circuit breakers that halt tool execution if anomalous patterns are detected such as unusually high volume of tool calls or tool calls to endpoints not previously used.

MCP servers present supply chain risks to development environments

Malicious or compromised MCP servers can poison tool descriptions, shadow legitimate tool names with malicious versions, exfiltrate credentials through tool arguments, or update tool definitions after initial approval (rug-pull attacks). Agents connect to MCP servers to access tools for file operations, database queries, API calls, and more.

Do: Audit and control MCP server connections

Audit all MCP servers connected to the development environment. Maintain an allowlist of approved servers and tools. Pin tool definitions and detect changes using snapshot-and-diff mechanisms to catch rug-pull updates where tool behavior changes after initial approval. Review tool descriptions for hidden instructions that can contain prompt injection payloads. Restrict which tools the agent can invoke by applying least privilege—coding agents do not need access to email, payment, or administrative tools. Monitor for tool name shadowing where a malicious MCP server registers a tool with the same name as a legitimate one. Validate tool arguments before execution to prevent agents from passing sensitive data as arguments.

Don't: Connect untrusted MCP servers or allow auto-discovery

Do not connect to MCP servers from untrusted sources without security review. Do not allow agents to discover and connect to MCP servers automatically without approval. Do not trust tool descriptions as benign—they are an injection surface. Do not allow MCP tools unrestricted filesystem, network, or credential access on the developer's machine.

Give your agent this brain