AI Security

Never‑Grant Permissions: A Small‑Business Guide to What AI Agents Should Never Get by Default

Published 2026-10-04 by AISecAll Editorial

TL;DR: Small teams should start every AI‑agent deployment with a “never‑grant” list that blocks system‑level execution, unrestricted file writes, outbound network access, secret‑reading environment variables, and admin‑level database actions. Enforce the list via scoped API keys, sandboxed runtimes, and runtime policy checks, then log any denied attempts for audit.

Why a “never‑grant” list matters for small teams

AI agents can be given powerful tool‑calling abilities that look convenient but also open a direct path to data exfiltration, ransomware‑style file manipulation, or credential theft. For a solo founder or a five‑person startup, a single compromised agent can expose customer contracts, financial spreadsheets, or source code. A static deny‑list gives you a baseline of least‑privilege that works even before you fully understand the agent’s workload.

Core permissions that should always be denied

System‑level execution (shell, subprocess, runtime commands)

Never allow an agent to invoke bash, sh, cmd, or any language‑level exec APIs. Even if the agent is meant to run code snippets, sandbox the execution and expose only a controlled function interface.

File‑system write/delete outside a sandbox

Agents should never have write or delete rights on the host file system. Limit them to a temporary directory that is wiped after each session. This prevents ransomware‑style wiping of logs or configuration files.

Unrestricted outbound network access

Block any arbitrary http/https calls that are not whitelisted. Allow only the specific SaaS endpoints the workflow needs (e.g., api.salesforce.com, api.stripe.com).

Reading environment variables that contain secrets

Never expose OPENAI_API_KEY, AWS_SECRET_ACCESS_KEY, or similar variables to the agent. Use a secret‑injection mechanism that the agent can request via a vetted API call, not direct env access.

Direct database admin operations

Denies any DROP, TRUNCATE, or ALTER statements. If the agent needs to query data, give it a read‑only view or a stored‑procedure wrapper.

Platform‑specific permission checks

Each AI‑agent platform exposes its own set of tool‑calling capabilities. Map the generic deny‑list to those concrete settings.

OpenAI Agents

• Do not enable the functions feature that allows arbitrary code execution unless wrapped in a server‑side validator.
• Set file_handling to none unless you provide a sandboxed file‑service endpoint.
• Restrict the tools array to vetted HTTP request tools that enforce a whitelist.

Claude Managed Agents

• Disable the browser tool unless you proxy requests through a safe‑list filter.
• Turn off file_edit and file_write unless you provide a sandboxed storage API.
• Use the platform’s tool_permissions field to explicitly deny shell access.

Zapier, Make, n8n (no‑code automation)

• When creating an “AI Action”, uncheck any “Run JavaScript” or “Run Python” steps unless they are isolated in a separate worker.
• Limit webhook URLs to your domain and enforce HMAC verification.
• Set the “Allowed Apps” list to only the SaaS services you have vetted.

How to enforce the never‑grant list

• Scoped API keys: Generate short‑lived tokens with the minimum read/write scopes required for the workflow. Both OpenAI and Claude support fine‑grained scopes.
• Runtime guardrails: Wrap the agent’s request handler in a policy engine (e.g., Open Policy Agent) that checks each tool call against the deny‑list before forwarding it.
• Sandboxed execution: Use container‑based sandboxes (Docker, Firecracker) or the platform’s built‑in sandbox (Cloudflare Workers AI) to isolate file system and network.
• Environment isolation: Store secrets in a vault (e.g., HashiCorp Vault, AWS Secrets Manager) and expose them via a short‑lived API that validates the caller’s identity.

Auditing and monitoring denied‑permission attempts

Log every rejected tool call with the following fields:

{
  "timestamp": "2024-10-04T12:34:56Z",
  "agent_id": "sales‑assistant‑01",
  "requested_tool": "shell_exec",
  "reason": "tool disabled by never‑grant policy",
  "requester_ip": "10.2.3.45"
}

Send these logs to a centralized SIEM or a simple CloudWatch Log Group. Set up alerts for repeated denials, which often indicate a mis‑configured prompt or an attempted jailbreak.

Quick launch checklist

1. Define the deny‑list (system exec, file write, outbound network, env secrets, DB admin).
2. Map deny items to each platform’s permission model.
3. Create scoped API keys and store them in a vault.
4. Deploy a policy‑engine wrapper around the agent endpoint.
5. Enable audit logging for all denied calls.
6. Run a test prompt that tries each forbidden action and verify it is blocked.
7. Document the list in a shared wiki for future audits.

Following this process gives you a concrete security baseline without slowing down development. If you need a hands‑on implementation, AISecAll can help you integrate policy enforcement into your existing AI‑automation stack.