AI Security

Zero‑Trust Permission Baseline: Which Rights to Deny for Every AI Agent in Small Teams

Published 2026-09-01 by AISecAll Editorial

TL;DR: Start every AI‑agent deployment with a deny‑by‑default permission set. Block file‑system write, arbitrary shell execution, network egress, and unrestricted access to secret stores. Grant only the minimal API scopes your workflow truly needs, and lock down the remaining capabilities with runtime sandboxes. Review the list regularly as the agent’s responsibilities evolve.

Which permissions are the most dangerous for an AI agent?

AI agents can be instructed to act like a user, a script, or even a system administrator. The following capabilities have repeatedly caused data loss, credential exposure, or service disruption in real‑world incidents:

• File‑system write or delete – Allows the agent to modify code, configuration files, or logs.
• Arbitrary shell / command execution – Gives the agent the ability to run rm -rf / or install malicious binaries.
• Unrestricted network egress – Lets the agent call any external API, potentially exfiltrating data.
• Read access to secret stores – Direct exposure of API keys, database passwords, or OAuth tokens.
• Broad repository access – Full read/write rights to private Git repositories can leak proprietary code.

These are the permissions you should never enable by default. Any need for them must be justified, scoped, and audited.

How do I build a deny‑by‑default baseline?

Follow these three steps:

1. Identify the minimal functional surface. List the exact API calls, file paths, or cloud resources the agent must touch to complete its task.
2. Map each requirement to a concrete permission. For example, if the agent only needs to read a CSV in an S3 bucket, grant s3:GetObject on that bucket and deny all other S3 actions.
3. Apply a default‑deny policy. Use the platform’s permission model (Claude Managed Agents overview, OpenAI Agents guides) to set the baseline, then add explicit allow rules for the items from step 2.

When a new capability is required, repeat the process instead of toggling a global “allow all”.

What concrete permission examples should I start with?

Below is a starter matrix you can copy into your agent configuration files. Adjust the resource identifiers to match your environment.

# Example for Claude Managed Agents (YAML syntax)
permissions:
  # Deny everything by default (implicit in Claude)
  allow:
    - type: http
      method: GET
      url: https://api.salesforce.com/vXX/contacts/*
    - type: storage
      action: read
      bucket: my‑customer‑docs
      prefix: inbound/
    - type: secret
      name: OPENAI_API_KEY
      access: read
  # Explicit denies (override any allow)
  deny:
    - type: file
      action: write
    - type: shell
      action: execute
    - type: network
      destination: "*"
    - type: secret
      access: write

For OpenAI Agents, the same principle applies using the tool manifest. Only expose the functions you need and omit any code_interpreter or retrieval tools unless required.

How can I enforce the baseline at runtime?

Static policies are only half the story. Add these runtime guardrails:

• Sandbox execution. Run the agent inside a container with read‑only file‑system mounts and network policies that block outbound traffic except whitelisted domains.
• API‑gateway throttling. Place a proxy (e.g., Cloudflare Workers) in front of external APIs and enforce per‑agent rate limits.
• Audit logs. Log every permission check and reject event. Include the agent ID, requested action, resource, and decision outcome.

These controls let you detect accidental over‑reach before it becomes a breach.

When should I revisit the permission list?

Permissions are not “set‑and‑forget”. Review them at least:

1. After each major workflow change.
2. Quarterly, as part of your security health check.
3. Whenever a new vulnerability is disclosed in the underlying LLM or platform (see the OWASP GenAI project for alerts).

Document any changes in a version‑controlled policy file so you can roll back if a new permission causes unexpected behavior.

What if I need temporary elevated rights?

Implement a “just‑in‑time” approval flow:

• The agent requests the extra scope via a structured prompt.
• A human reviewer receives a concise approval card (e.g., in Slack) showing the exact permission requested and the reason.
• Upon approval, the platform issues a short‑lived token (minutes to hours) that the agent can use, after which the token expires automatically.

This pattern keeps speed for routine tasks while preserving a strong audit trail for privileged actions.

FAQ

• Q: Do I need to block read‑only access to secret stores?
  A: No. Read‑only access is often required for API calls. However, ensure the secret is scoped to the minimal service (e.g., a single OpenAI key) and rotate it regularly.
• Q: Can I rely on the AI provider’s default permissions?
  A: Providers usually start with an “allow‑all” stance for convenience. You must explicitly restrict permissions to meet zero‑trust goals.
• Q: How do I test that my deny list works?
  A: Write unit tests that attempt prohibited actions (file write, shell exec) and assert they are rejected. Run these tests in your CI pipeline.
• Q: What if an agent needs to call a new third‑party API?
  A: Add a single allow rule for that API’s endpoint and domain, then re‑run your security review before deploying.
• Q: Is there a standard checklist I can copy?
  A: The OWASP GenAI Security Project publishes a “Permission Hardening” checklist that aligns with the steps described here.

By starting with a strict deny‑by‑default baseline and adding permissions only after a documented risk assessment, small teams can keep AI agents productive without opening a backdoor to their data and infrastructure.

Need help tailoring a permission matrix for your specific AI tools? AISecAll can work with you to design, implement, and audit a zero‑trust guardrail strategy that fits your budget and timeline.