AI Security

Never‑Grant List: Permissions to Block on AI Agents for Small Teams

TL;DR: Deny every permission that lets an AI agent read or modify system resources, environment secrets, network endpoints, or external services unless you have a documented business need. Start with a deny‑by‑default baseline, add only the minimum scoped permissions per vendor, enforce runtime guardrails, and review quarterly.

Which permissions are risky for AI agents?

AI agents can be given the same privileges as a human user or a service account. The most common high‑risk permissions include:

Anything that lets the agent affect production state or read data it shouldn’t see belongs on the deny list.

How to apply a deny‑by‑default model in practice?

1. Create a permission manifest. List every capability your AI platform can request (e.g., read_file, run_shell, http_request, env_read).
2. Set the manifest to deny all. In most managed‑agent services this is a simple toggle in the dashboard or a YAML policy file. 3. Add allowances one by one. For each workflow, write a justification, scope the permission (e.g., limit http_request to https://api.stripe.com), and record it in a change‑log. 4. Enforce at runtime. Use the platform’s “guardrails” feature to abort the agent if it attempts an undeclared action. 5. Automate testing. Include a test that tries to request every denied permission and asserts failure.

Vendor‑specific permission baselines

Replit Agent

Replit’s docs recommend denying fs_write, shell, and env_read unless the agent is running in an isolated sandbox. Use the permissions field in replit.yaml to whitelist only fs_read for the project directory.

Claude Managed Agents

Claude’s managed‑agent platform separates “tools” (search, code execution) from “capabilities.” By default, only search and http are enabled. Disable write_file and run_command in the agent settings page. For any needed write access, configure a scoped file bucket and grant the agent a one‑time token.

OpenAI Agents

The OpenAI SDK lets you define a tool list. Omit any tool that performs bash execution or secret retrieval. If you need http calls, wrap them in a proxy that enforces a whitelist of domains. See the official agents guide for the exact JSON schema.

Implementing runtime guardrails

Even with a strict manifest, agents can try to bypass controls. Add these runtime checks:

  1. Input validation. Reject any prompt that contains code‑injection patterns before it reaches the model.
  2. Action audit log. Emit a structured log entry (JSON) for every tool invocation, including user ID, timestamp, and outcome.
  3. Timeouts. Limit execution time for any external request to avoid denial‑of‑service attacks.
  4. Sandboxing. Run code‑execution tools inside containers with read‑only root filesystems.

These guardrails are lightweight enough for small teams but raise the bar against accidental or malicious misuse.

Periodic review and revocation process

Permissions are a moving target. Adopt a quarterly review cycle:

Document the review outcome in a shared wiki so auditors can see the rationale.

By treating AI‑agent permissions as a first‑class security asset, small companies can enjoy the productivity boost of generative AI while keeping the attack surface under control. Need help formalizing these policies? AISecAll offers a lightweight audit service tailored for startups.

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