AI Security

Building a Permission‑Baseline for AI Agents: Which Access Rights Must Be Denied by Default?

TL;DR: Start with a simple never‑grant list (no shell, no network, no file‑system write), map each permission to a concrete risk, encode the list in your platform’s policy file, and automate a weekly audit. Use OWASP GenAI and NIST AI RMF guidance to justify every denial.

Why a Never‑Grant List Matters for Small Teams

Small companies often grant AI agents the same privileges they would give a human operator because the default settings of managed platforms are permissive. A single over‑privileged agent can exfiltrate data, modify production configuration, or launch unwanted network calls. By defining a baseline of permissions that are never granted, you apply the principle of least privilege from day one and reduce the attack surface without adding operational overhead.

Core Permission Categories to Review

System‑Level Access

Agents that can read environment variables, access the host OS, or invoke system commands are a red flag. Even read‑only access to PATH or HOME can reveal secrets stored in the environment.

Network and API Access

Unrestricted outbound networking lets an agent call any external endpoint. For a small business, the safest default is to block all outbound traffic and whitelist only the APIs the workflow truly needs (e.g., a CRM endpoint).

File System and Execution Rights

Write access to shared directories, the ability to create or delete files, or the permission to execute binaries should be denied unless the agent is explicitly a code‑generation worker.

Building a Permission Matrix for Your AI Agent

Translate the categories above into a concrete table that you can copy into your platform’s policy file (Claude Managed Agents, OpenAI Agents, Zapier, etc.).

Permission Reason to Deny by Default Typical Platform Flag
Shell / exec Can run arbitrary commands, leading to ransomware or data exfiltration. allow_shell: false
Network outbound Uncontrolled calls to malicious services. network_access: [] (empty whitelist)
File write Potential to corrupt logs, inject malicious scripts. file_write: false
Environment read May expose API keys, DB passwords. env_read: false
Code deployment Agent could push untested code to production. deploy: false

Practical Steps to Enforce the Baseline

  1. Document the baseline. Store the table in a version‑controlled permissions.yml file.
  2. Apply platform‑specific policies. For Claude Managed Agents, set allow_shell: false in the agent config; for OpenAI Agents, use the tool whitelist feature.
  3. Automate validation. Add a CI step that parses permissions.yml and fails if any true flag appears for the categories above.
  4. Test with a sandbox. Run the agent in a disposable environment (e.g., Cloudflare Workers AI sandbox) and attempt prohibited actions; confirm they are blocked.
  5. Educate the team. Share the never‑grant list in onboarding docs so developers understand why a request for extra permission must be justified.

Auditing and Ongoing Review

Permissions drift over time as new features are added. Schedule a weekly audit that:

If a denied permission is legitimately needed, create a documented exception, add a temporary override, and set a reminder to revisit the request after 30 days.

FAQ

Implementing a never‑grant baseline is a low‑cost, high‑impact step that lets small teams adopt AI agents with confidence. If you need help tailoring policies to your stack, AISecAll can run a quick security review and set up automated enforcement.

Need a practical AI security review?

AISecAll reviews prompts, tool permissions, document flows, and agent behavior so small teams can use AI without guessing where the risk sits.

Book a call Discuss a project