AI Security

Critical Permissions to Disallow on AI Agents in Small Business Workflows

Published 2026-08-16 by AISecAll Editorial

TL;DR: Never give an AI agent unrestricted file‑system, shell, or credential access. Start with a universal deny list (file write, exec, environment secrets, admin‑level SaaS scopes), then layer platform‑specific blocks (Claude: no system tool, OpenAI: no file or code tool, Zapier/Make/n8n: disable admin or billing scopes). Document the list, enforce it with IAM policies or platform‑level role bindings, and run a quarterly audit.

Which permissions are universally risky?

Across all AI‑agent platforms the following capabilities enable a malicious or compromised agent to:

• Execute arbitrary shell commands – gives the agent full control of the host OS.
• Write or delete files outside a sandbox – can corrupt data, exfiltrate logs, or install persistence mechanisms.
• Read environment variables that contain secrets – API keys, database passwords, or OAuth tokens become exposed.
• Elevated SaaS scopes (admin, billing, user‑management) – allows the agent to change permissions, add users, or modify billing information.
• Network‑wide outbound access – unrestricted outbound HTTP can be used for data exfiltration or command‑and‑control.

These five categories form the core of a “never‑grant” list for any small‑business AI deployment.

Platform‑specific never‑grant lists

Claude Managed Agents

Claude’s managed‑agent framework lets you enable tools such as search, code, or system. The system tool gives the agent direct shell access. For most business use cases, disable it outright:

{
  "tools": ["search", "code"],
  "deny_tools": ["system"]
}

Also avoid granting the files tool unless the workflow is confined to a temporary directory that is wiped after each session.

OpenAI Agents SDK

When you build an agent with the OpenAI SDK you declare tool objects. The SDK includes file, code, and function tools. To keep the agent from touching the host filesystem, omit the file tool and restrict function calls to read‑only operations:

tools = [
    {"type": "search"},
    {"type": "code", "execution": "sandboxed"}
]

Never enable file or system equivalents unless you have a hardened sandbox.

No‑code platforms (Zapier, Make, n8n)

These platforms expose SaaS connections as “actions”. Each connection is granted a set of OAuth scopes. Review the scopes in the provider’s console and remove any that are not needed for the specific automation.

• Zapier: When adding a Google Workspace connection, deselect admin.directory.user and admin.directory.group unless you truly need to manage users.
• Make: For a HubSpot connection, keep only contacts.read and deals.read. Disable contacts.write and account.manage.
• n8n: Use the “Scope” field on the OAuth2 credential node to list only the required read‑only scopes (e.g., files.metadata.read for Google Drive).

Most platforms also let you set a “run as user” flag. Always run the agent under a low‑privilege service account, never an admin account.

How to build a never‑grant list for your team

1. Inventory every AI agent – note the platform, version, and declared tools.
2. Map required business actions – list the exact API calls or file operations the agent must perform.
3. Derive the deny list – start with the universal risky categories, then add platform‑specific blocks that exceed the required actions.
4. Enforce via configuration – use the platform’s manifest (Claude JSON, OpenAI tools array, or OAuth scope list) to hard‑code the deny list.
5. Document the decision – store a markdown file in your repo that records the why/what for each denied permission.
6. Automate validation – add a CI step that parses the manifest files and fails if a disallowed permission appears.

Auditing and ongoing enforcement

Even with a solid never‑grant list, drift can happen. Implement a lightweight audit pipeline:

• Run a nightly script that extracts the active permissions from each agent’s configuration (most platforms expose an API endpoint).
• Compare the extracted list against the documented deny list. Log any mismatches as a security event.
• Trigger a Slack or Teams alert for immediate review.
• Schedule a quarterly manual review to confirm that business needs haven’t changed.

When an audit finds a violation, revert the configuration, rotate any exposed secrets, and investigate the root cause. Small teams often discover that a developer added an extra scope for testing and forgot to remove it.

For teams that lack dedicated security staff, AISecAll offers a managed “Permission Hardening” service that automates inventory, enforcement, and audit reporting for the platforms listed above.