AI Security
Building a Platform‑Agnostic Never‑Grant Permission List for AI Agents
TL;DR: Start with a short list of high‑risk capabilities (file‑system write, shell execution, unrestricted network access, admin‑level SaaS scopes). Map each capability to the permission model of the AI platform you use (Claude Managed Agents, OpenAI Agents, Replit, Zapier, Make, n8n). Create a deny‑list policy file, enforce it via platform‑specific configuration or wrapper code, and review the list quarterly.
Why a Never‑Grant List Matters for Small Teams
Small companies often adopt AI agents to automate repetitive tasks. Because budgets are tight, they may grant broad permissions to get things working quickly. That convenience creates a large attack surface: a compromised or misbehaving agent can delete files, exfiltrate data, or modify production settings. A never‑grant list (sometimes called a “never‑grant” or “deny‑by‑default” list) flips the default from “allow everything” to “deny the dangerous actions unless you explicitly approve them”.
Step 1: Identify High‑Risk Capabilities
Consult the OWASP GenAI Security Project and NIST AI Risk Management Framework for the categories of actions that most often lead to security incidents. The following capabilities are universally high‑risk:
- File‑system write/delete – ability to create, modify, or erase files on the host.
- Shell/command execution – any API that runs arbitrary commands (e.g.,
os.system,subprocess). - Unrestricted network access – outbound HTTP/HTTPS to arbitrary domains.
- Admin‑level SaaS scopes – e.g.,
crm:admin,drive:full_control. - Environment‑variable read – especially variables that contain secrets.
These five categories form the core of your never‑grant list.
Step 2: Map Platform Permission Models
Each AI‑agent platform expresses permissions differently. Create a simple table that maps the high‑risk capabilities to the platform’s terminology.
| Capability | Claude Managed Agents | OpenAI Agents | Replit Agent | Zapier / Make |
|---|---|---|---|---|
| File‑system write/delete | file_write (must be disabled) | file_access (set to read_only) | filesystem (deny write) | Not applicable – use sandboxed steps only |
| Shell execution | shell (disallow) | tool_use with bash (remove) | exec (disable) | Not available in native steps |
| Unrestricted network | network (allow list only) | http (restrict domains) | network (whitelist) | Use Webhooks with domain filters |
| Admin SaaS scopes | Scope to read only | OAuth scopes limited to read | Use fine‑grained tokens | Set Zapier app permissions to read |
| Env‑var read | Disallow env access | Do not expose OPENAI_API_KEY to the agent | Remove process.env exposure | Never pass secret variables into step inputs |
Document this mapping in a markdown file (e.g., never‑grant‑list.md**) so every team member can see which flags to toggle.
Step 3: Create a Policy File or Wrapper
Most platforms let you inject a configuration object when you instantiate the agent. Use that hook to enforce the deny list.
const agent = new ClaudeAgent({
permissions: {
file_write: false,
shell: false,
network: { allowList: ["api.mycompany.com"] },
scopes: ["crm:read", "drive:read"]
}
});
For platforms without a built‑in permission model (e.g., Zapier), wrap the agent call in a small Node.js or Python shim that validates the request against the deny list before forwarding it.
Step 4: Enforce at Deployment Time
Integrate the policy file into your CI/CD pipeline. A simple grep or JSON schema validation step can abort a build if a prohibited permission appears.
# Example GitHub Action step
- name: Verify never‑grant list
run: |
jq -e '.permissions | select(.shell == true or .file_write == true)' agent-config.json && exit 1 || echo "No forbidden permissions"
Because the check runs on every push, accidental permission creep is caught early.
Step 5: Review and Update Quarterly
Business needs evolve. Schedule a 30‑minute quarterly review where the team:
- Checks new platform features (e.g., a new “code‑interpreter” tool).
- Validates that existing deny entries still make sense.
- Adds any newly discovered high‑risk capabilities.
Document the outcome in a changelog attached to the policy file.
Putting It All Together
When you combine a concise never‑grant list, platform‑specific mapping, automated enforcement, and a regular review cadence, you get a lightweight yet robust guardrail that fits the resource constraints of a small business. The approach is vendor‑agnostic, so you can adopt Claude Managed Agents today and switch to OpenAI Agents tomorrow without rewriting the policy.
FAQ
- Q: Do I need to deny every permission that isn’t on the list?
A: No. The never‑grant list is a “deny‑by‑default” for high‑risk actions. Normal read‑only permissions (e.g., fetching a document) can stay allowed. - Q: What if a platform doesn’t expose a permission flag?
A: Use a wrapper or sandbox the agent in a container that enforces OS‑level restrictions (e.g., Docker with--read‑onlymounts). - Q: How do I handle third‑party SaaS integrations that require admin scopes?
A: Create a separate service account with the minimal scopes needed, and never give the agent the master token. - Q: Can I automate testing of the deny list?
A: Yes. Write unit tests that attempt prohibited actions and assert they fail. Run these tests in your CI pipeline. - Q: Does this replace other security controls?
A: No. It complements network firewalls, secret management, and incident‑response plans.
Implementing a never‑grant list is a practical first step that delivers immediate risk reduction without slowing down development. If you need help tailoring the policy to your specific stack, AISecAll can assist with a quick security review.
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.