WritingBooksAboutCommunityContactCommunity

Action Restrictions and Permissions: Controlling What Your AI Agent Can Do

Michael Brenndoerfer•August 14, 2025•16 min read

Learn how to implement action restrictions and permissions for AI agents using the principle of least privilege, confirmation steps, and sandboxing to keep your agent powerful but safe.

Action Restrictions and Permissions

In the previous chapter, you learned how to keep your agent's outputs safe through content moderation. But what about its actions? When your agent can send emails, modify files, or make API calls, filtering text isn't enough. You need to control what it's allowed to do in the first place.

Think about how permissions work on your computer. When you install an app, it asks for specific permissions: access to your camera, your files, your location. The app doesn't get unlimited power. It gets exactly what it needs to do its job, and no more. Your AI agent should work the same way.

This chapter explores how to implement action restrictions and permissions for our personal assistant. You'll learn the principle of least privilege (giving the agent only the access it needs), how to add confirmation steps for risky actions, and how to sandbox the agent's environment. By the end, you'll have an agent that's powerful but constrained, capable but safe.

The Problem with Unrestricted Actions

Let's start by understanding what can go wrong. Imagine you've given your assistant the ability to send emails on your behalf. Here's a simple tool implementation:

In[3]:
Code
## Using Claude Sonnet 4.5 for its strong tool use capabilities
import os
from anthropic import Anthropic
import smtplib
from email.mime.text import MIMEText

def send_email(to_address, subject, body):
    """Send an email via SMTP"""
    msg = MIMEText(body)
    msg['Subject'] = subject
    msg['From'] = 'your.email@example.com'
    msg['To'] = to_address
    
    with smtplib.SMTP('smtp.example.com', 587) as server:
        server.starttls()
        server.login('your.email@example.com', 'PASSWORD')
        server.send_message(msg)
    
    return f"Email sent to {to_address}"

## Define the tool for the agent
tools = [{
    "name": "send_email",
    "description": "Send an email to a specified address",
    "input_schema": {
        "type": "object",
        "properties": {
            "to_address": {"type": "string"},
            "subject": {"type": "string"},
            "body": {"type": "string"}
        },
        "required": ["to_address", "subject", "body"]
    }
}]

This works, but it's dangerous. The agent can now send any email to anyone, at any time, without asking. What if it misunderstands a request? What if a user tries to trick it into spamming someone? What if there's a bug in your code that causes it to send the same email repeatedly?

These aren't hypothetical concerns. When you give an agent the power to take actions in the real world, you need safeguards. Let's explore how to add them.

Principle of Least Privilege

The first rule of action safety is simple: give your agent the minimum permissions it needs to do its job. This is called the principle of least privilege, and it's a fundamental concept in security.

Let's apply this to our email example. Instead of letting the agent email anyone, we might restrict it to only emailing people in your contacts list, or only emailing specific domains. Here's how:

In[4]:
Code
## Using Claude Sonnet 4.5 for agent reasoning with restricted tools
import os
from anthropic import Anthropic

ALLOWED_DOMAINS = ['example.com', 'trusted-partner.com']
ALLOWED_RECIPIENTS = ['alice@example.com', 'bob@example.com']

def send_email_restricted(to_address, subject, body):
    """Send an email with domain and recipient restrictions"""
    # Check if recipient is in allowed list
    if to_address not in ALLOWED_RECIPIENTS:
        # Check if domain is allowed
        domain = to_address.split('@')[1] if '@' in to_address else ''
        if domain not in ALLOWED_DOMAINS:
            return f"Error: Cannot send email to {to_address}. Not in allowed recipients or domains."
    
    # If we get here, the recipient is allowed
    msg = MIMEText(body)
    msg['Subject'] = subject
    msg['From'] = 'your.email@example.com'
    msg['To'] = to_address
    
    with smtplib.SMTP('smtp.example.com', 587) as server:
        server.starttls()
        server.login('your.email@example.com', 'PASSWORD')
        server.send_message(msg)
    
    return f"Email sent to {to_address}"

Now the agent can only email specific people or specific domains. If it tries to email someone else, the function returns an error. This is a hard constraint that the agent can't bypass, no matter what the user asks for.

You can apply the same principle to other tools:

File access: Instead of giving the agent access to your entire filesystem, restrict it to a specific directory:

In[5]:
Code
import os

ALLOWED_DIRECTORY = '/home/user/assistant_workspace'

def read_file_restricted(filename):
    """Read a file only from the allowed directory"""
    # Construct the full path
    full_path = os.path.join(ALLOWED_DIRECTORY, filename)
    
    # Make sure the path is actually inside the allowed directory
    # (prevents tricks like "../../../etc/passwd")
    real_path = os.path.realpath(full_path)
    if not real_path.startswith(os.path.realpath(ALLOWED_DIRECTORY)):
        return "Error: Access denied. File is outside allowed directory."
    
    # Check if file exists
    if not os.path.exists(real_path):
        return f"Error: File {filename} not found."
    
    # Read and return the file
    with open(real_path, 'r') as f:
        return f.read()

API calls: Limit which APIs the agent can call and what operations it can perform:

In[6]:
Code
ALLOWED_API_ENDPOINTS = [
    'https://api.weather.com/current',
    'https://api.calendar.com/events'
]

def make_api_call(endpoint, method='GET', data=None):
    """Make an API call to allowed endpoints only"""
    if endpoint not in ALLOWED_API_ENDPOINTS:
        return f"Error: API endpoint {endpoint} is not allowed."
    
    if method not in ['GET', 'POST']:
        return f"Error: HTTP method {method} is not allowed."
    
    # Make the actual API call
    # ... implementation ...

The pattern is consistent: before the tool does anything, it checks whether the action is allowed. If not, it returns an error. The agent sees the error and can explain to the user why the action wasn't possible.

Confirmation Steps for Risky Actions

Some actions are too risky to perform automatically, even if they're technically allowed. For these, you want the agent to ask for confirmation first.

Think about how your smartphone handles this. When an app wants to access your camera, it doesn't just do it. It asks: "Allow this app to access your camera?" You have to explicitly approve.

Your agent should do the same for high-stakes actions. Here's how to implement confirmation for email sending:

In[7]:
Code
## Using Claude Sonnet 4.5 for multi-turn confirmation flows
import os
from anthropic import Anthropic

class AgentWithConfirmation:
    def __init__(self):
        self.client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))
        self.pending_actions = {}
        
    def run(self, user_message, conversation_history=None):
        """Run the agent with confirmation support"""
        if conversation_history is None:
            conversation_history = []
        
        # Add user message to history
        conversation_history.append({
            "role": "user",
            "content": user_message
        })
        
        # Define tools with confirmation requirement
        tools = [{
            "name": "send_email",
            "description": "Send an email. Requires user confirmation before sending.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to_address": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to_address", "subject", "body"]
            }
        }]
        
        # Call the model
        response = self.client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=2048,
            messages=conversation_history,
            tools=tools
        )
        
        # Check if agent wants to use a tool
        if response.stop_reason == "tool_use":
            tool_use = next(block for block in response.content if block.type == "tool_use")
            
            if tool_use.name == "send_email":
                # Store the pending action
                action_id = "email_001"
                self.pending_actions[action_id] = tool_use.input
                
                # Ask user for confirmation
                confirmation_message = f"""I'm ready to send this email:

To: {tool_use.input['to_address']}
Subject: {tool_use.input['subject']}
Body: {tool_use.input['body']}

Do you want me to send this email? (Reply 'yes' to confirm or 'no' to cancel)"""
                
                return confirmation_message, conversation_history
        
        # Return normal response
        return response.content[0].text, conversation_history
    
    def confirm_action(self, action_id, confirmed):
        """Execute or cancel a pending action based on user confirmation"""
        if action_id not in self.pending_actions:
            return "No pending action found."
        
        action = self.pending_actions[action_id]
        
        if confirmed:
            # Execute the action
            result = send_email_restricted(
                action['to_address'],
                action['subject'],
                action['body']
            )
            del self.pending_actions[action_id]
            return f"Confirmed. {result}"
        else:
            # Cancel the action
            del self.pending_actions[action_id]
            return "Action cancelled."

Let's see this in action:

User: Send an email to alice@example.com with subject "Meeting Tomorrow" 
      and body "Let's meet at 2pm"

Agent: I'm ready to send this email:

To: alice@example.com
Subject: Meeting Tomorrow
Body: Let's meet at 2pm

Do you want me to send this email? (Reply 'yes' to confirm or 'no' to cancel)

User: yes

Agent: Confirmed. Email sent to alice@example.com

The agent prepares the action but doesn't execute it. It shows you exactly what it's about to do and waits for your approval. Only when you say "yes" does the email actually get sent.

This pattern works for any risky action:

  • Deleting files: Show which files will be deleted
  • Making purchases: Show the item and price
  • Posting to social media: Show the exact content to be posted
  • Modifying data: Show what will change

The key is to make the confirmation specific. Don't just ask "Is this okay?" Show exactly what will happen so the user can make an informed decision.

Sandboxing the Agent's Environment

Even with restrictions and confirmations, you might want an extra layer of protection: running the agent in a sandbox. A sandbox is a restricted environment where the agent can operate without affecting the rest of your system.

Think of it like a playground with a fence. The agent can do whatever it wants inside the sandbox, but it can't get out and affect anything beyond the fence.

Here's a simple example using Docker to sandbox file operations:

In[14]:
Code
## Using Claude Sonnet 4.5 with sandboxed file operations
import docker
import tempfile
import os

class SandboxedAgent:
    def __init__(self):
        self.client = docker.from_env()
        # Create a temporary directory for the sandbox
        self.sandbox_dir = tempfile.mkdtemp()
        
    def execute_file_operation(self, code):
        """Execute Python code in a sandboxed Docker container"""
        # Create a Python script with the code
        script_path = os.path.join(self.sandbox_dir, 'script.py')
        with open(script_path, 'w') as f:
            f.write(code)
        
        # Run the code in a Docker container with limited permissions
        container = self.client.containers.run(
            'python:3.9-slim',
            f'python /sandbox/script.py',
            volumes={
                self.sandbox_dir: {'bind': '/sandbox', 'mode': 'rw'}
            },
            network_disabled=True,  # No network access
            mem_limit='256m',  # Limited memory
            cpu_period=100000,
            cpu_quota=50000,  # Limited CPU
            remove=True,
            detach=False
        )
        
        return container.decode('utf-8')
    
    def cleanup(self):
        """Clean up the sandbox directory"""
        import shutil
        shutil.rmtree(self.sandbox_dir)

This sandbox provides several protections:

Isolated filesystem: The agent can only access files in the sandbox directory. It can't read or modify anything else on your system.

No network access: The agent can't make network requests, preventing it from sending data to external servers.

Resource limits: The agent gets limited CPU and memory, preventing it from consuming all your system resources.

Automatic cleanup: When you're done, you can delete the entire sandbox, removing any files the agent created.

For most personal assistants, full Docker sandboxing might be overkill. But the principle is valuable: isolate risky operations so they can't affect the rest of your system.

A lighter-weight approach is to use Python's built-in restrictions:

In[8]:
Code
import os
import sys

def run_restricted_code(code):
    """Run Python code with restricted built-ins"""
    # Create a restricted environment
    restricted_globals = {
        '__builtins__': {
            'print': print,
            'len': len,
            'range': range,
            'str': str,
            'int': int,
            'float': float,
            'list': list,
            'dict': dict,
            # Add only safe built-ins
        }
    }
    
    # Execute the code in the restricted environment
    try:
        exec(code, restricted_globals)
        return "Code executed successfully"
    except Exception as e:
        return f"Error: {str(e)}"

## Example: This will work
result = run_restricted_code("print('Hello, world!')")
print(result)  # "Code executed successfully"

## Example: This will fail (no file access)
result = run_restricted_code("open('/etc/passwd', 'r')")
print(result)  # "Error: name 'open' is not defined"
Out[8]:
Console
Hello, world!
Code executed successfully
Error: name 'open' is not defined

This approach removes dangerous built-ins like open, eval, and __import__, preventing the agent from accessing files or importing modules. It's not as secure as Docker, but it's much simpler and works for many use cases.

Designing a Permission System

As your agent grows more capable, you'll want a more structured approach to permissions. Instead of hardcoding restrictions in each tool, you can create a permission system that manages what the agent can do.

Here's a simple permission system:

In[9]:
Code
## Using Claude Sonnet 4.5 with a structured permission system
from enum import Enum
from typing import Set, Dict, Any

class Permission(Enum):
    READ_FILES = "read_files"
    WRITE_FILES = "write_files"
    SEND_EMAIL = "send_email"
    MAKE_API_CALLS = "make_api_calls"
    DELETE_DATA = "delete_data"

class PermissionManager:
    def __init__(self, granted_permissions: Set[Permission]):
        self.granted_permissions = granted_permissions
        self.permission_log = []
    
    def check_permission(self, permission: Permission, action_details: str) -> bool:
        """Check if a permission is granted and log the check"""
        has_permission = permission in self.granted_permissions
        
        self.permission_log.append({
            'permission': permission.value,
            'action': action_details,
            'granted': has_permission
        })
        
        return has_permission
    
    def require_permission(self, permission: Permission, action_details: str):
        """Raise an error if permission is not granted"""
        if not self.check_permission(permission, action_details):
            raise PermissionError(
                f"Action requires {permission.value} permission: {action_details}"
            )

class PermissionedAgent:
    def __init__(self, permissions: Set[Permission]):
        self.permissions = PermissionManager(permissions)
        self.client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))
    
    def read_file(self, filename: str) -> str:
        """Read a file if permission is granted"""
        self.permissions.require_permission(
            Permission.READ_FILES,
            f"Reading file: {filename}"
        )
        
        # Permission granted, proceed with reading
        with open(filename, 'r') as f:
            return f.read()
    
    def send_email(self, to_address: str, subject: str, body: str) -> str:
        """Send an email if permission is granted"""
        self.permissions.require_permission(
            Permission.SEND_EMAIL,
            f"Sending email to: {to_address}"
        )
        
        # Permission granted, proceed with sending
        return send_email_restricted(to_address, subject, body)
    
    def get_permission_log(self) -> list:
        """Get a log of all permission checks"""
        return self.permissions.permission_log

Now you can create agents with different permission levels:

In[10]:
Code
## Create a read-only agent
read_only_agent = PermissionedAgent({
    Permission.READ_FILES,
    Permission.MAKE_API_CALLS
})

## Create a full-access agent
full_agent = PermissionedAgent({
    Permission.READ_FILES,
    Permission.WRITE_FILES,
    Permission.SEND_EMAIL,
    Permission.MAKE_API_CALLS
})

## Try to send an email with the read-only agent
try:
    read_only_agent.send_email('alice@example.com', 'Test', 'Hello')
except PermissionError as e:
    print(f"Permission denied: {e}")
    # Output: Permission denied: Action requires send_email permission: 
    #         Sending email to: alice@example.com
Out[10]:
Console
Permission denied: Action requires send_email permission: Sending email to: alice@example.com

This system gives you several benefits:

Centralized control: All permission logic is in one place, making it easy to audit and modify.

Clear permissions: You can see at a glance what each agent is allowed to do.

Audit trail: The permission log shows every action the agent attempted and whether it was allowed.

Flexible configuration: You can easily create agents with different permission levels for different use cases.

Combining Restrictions, Confirmations, and Permissions

The most robust approach combines all three techniques:

  1. Permissions define what the agent is allowed to do in principle
  2. Restrictions limit the scope of allowed actions (which files, which recipients, etc.)
  3. Confirmations require user approval for high-stakes actions

Here's how they work together:

In[11]:
Code
## Using Claude Sonnet 4.5 for comprehensive action safety
class SafeAgent:
    def __init__(self, permissions: Set[Permission]):
        self.permissions = PermissionManager(permissions)
        self.client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))
        self.pending_confirmations = {}
    
    def send_email(self, to_address: str, subject: str, body: str) -> str:
        """Send an email with permission check, restriction, and confirmation"""
        # Step 1: Check permission
        self.permissions.require_permission(
            Permission.SEND_EMAIL,
            f"Sending email to: {to_address}"
        )
        
        # Step 2: Check restrictions
        if to_address not in ALLOWED_RECIPIENTS:
            domain = to_address.split('@')[1] if '@' in to_address else ''
            if domain not in ALLOWED_DOMAINS:
                return f"Error: Cannot send email to {to_address}. Not in allowed recipients."
        
        # Step 3: Request confirmation
        confirmation_id = f"email_{len(self.pending_confirmations)}"
        self.pending_confirmations[confirmation_id] = {
            'action': 'send_email',
            'params': {
                'to_address': to_address,
                'subject': subject,
                'body': body
            }
        }
        
        return f"""Ready to send email:

To: {to_address}
Subject: {subject}
Body: {body}

Confirm with: agent.confirm('{confirmation_id}')
Cancel with: agent.cancel('{confirmation_id}')"""
    
    def confirm(self, confirmation_id: str) -> str:
        """Execute a pending action after confirmation"""
        if confirmation_id not in self.pending_confirmations:
            return "No pending action with that ID."
        
        action_data = self.pending_confirmations[confirmation_id]
        
        if action_data['action'] == 'send_email':
            params = action_data['params']
            result = send_email_restricted(
                params['to_address'],
                params['subject'],
                params['body']
            )
            del self.pending_confirmations[confirmation_id]
            return f"Confirmed. {result}"
    
    def cancel(self, confirmation_id: str) -> str:
        """Cancel a pending action"""
        if confirmation_id not in self.pending_confirmations:
            return "No pending action with that ID."
        
        del self.pending_confirmations[confirmation_id]
        return "Action cancelled."

This gives you defense in depth. If one layer fails, the others provide backup protection:

  • If the agent somehow bypasses the permission check, the restriction will still block unauthorized recipients
  • If the restriction is misconfigured, the confirmation gives the user a chance to catch the error
  • If the user accidentally confirms, the permission log provides an audit trail

Practical Guidelines for Action Safety

As you implement action restrictions for your own agent, keep these guidelines in mind:

Start with the minimum: When adding a new tool, give it the most restrictive permissions possible. You can always loosen restrictions later, but it's harder to tighten them once users expect certain capabilities.

Make restrictions visible: When the agent can't do something, make sure it explains why. A message like "I don't have permission to delete files" is much better than a generic error.

Log everything: Keep a record of what actions the agent attempted, which were allowed, and which were blocked. This helps you understand how the agent is being used and whether your restrictions are too tight or too loose.

Test adversarially: Try to trick your agent into doing things it shouldn't. Ask it to email someone outside the allowed list. Try to make it access files outside its sandbox. See where the weaknesses are.

Layer your defenses: Don't rely on a single protection mechanism. Use permissions, restrictions, confirmations, and sandboxing together.

Consider the context: A personal assistant running on your laptop might need different restrictions than one deployed as a service for multiple users. Adjust your safety measures to match the risk level.

When to Use Each Technique

Different situations call for different approaches:

Use permissions when you want to completely disable certain capabilities. If your agent should never send emails, don't give it the permission.

Use restrictions when you want to limit the scope of allowed actions. The agent can send emails, but only to certain people.

Use confirmations when actions are risky but sometimes necessary. The agent can delete files, but only after you approve each deletion.

Use sandboxing when you need strong isolation. If your agent runs untrusted code or processes user-uploaded files, put it in a sandbox.

For our personal assistant, here's a reasonable configuration:

  • Permissions: Read files, send emails, make API calls (no delete, no system commands)
  • Restrictions: Only read from designated folders, only email known contacts
  • Confirmations: Required for sending emails, making purchases, posting publicly
  • Sandboxing: Not needed for basic assistant tasks, but useful if adding code execution

This gives the agent enough power to be useful while keeping risks manageable.

Glossary

Action Restriction: A limit on what an agent can do with a given capability, such as restricting file access to a specific directory or email sending to approved recipients.

Confirmation Step: A safety mechanism where the agent requests explicit user approval before executing a potentially risky action, showing exactly what will happen.

Least Privilege: The security principle of granting an agent only the minimum permissions necessary to perform its intended function, reducing potential harm from errors or misuse.

Permission: An authorization that determines whether an agent is allowed to perform a specific type of action, such as reading files or sending emails.

Permission System: A structured framework for managing and checking what actions an agent is allowed to perform, typically including permission definitions, checks, and audit logging.

Sandbox: An isolated environment where an agent can operate without affecting the broader system, typically with restricted access to files, network, and system resources.

Quiz

Ready to test your understanding? Take this quick quiz to reinforce what you've learned about action restrictions and permissions for AI agents.

Loading component...

Reference

BIBTEXAcademic
@misc{actionrestrictionsandpermissionscontrollingwhatyouraiagentcando, author = {Michael Brenndoerfer}, title = {Action Restrictions and Permissions: Controlling What Your AI Agent Can Do}, year = {2025}, url = {https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents}, organization = {mbrenndoerfer.com}, note = {Accessed: 2025-12-25} }
APAAcademic
Michael Brenndoerfer (2025). Action Restrictions and Permissions: Controlling What Your AI Agent Can Do. Retrieved from https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents
MLAAcademic
Michael Brenndoerfer. "Action Restrictions and Permissions: Controlling What Your AI Agent Can Do." 2025. Web. 12/25/2025. <https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents>.
CHICAGOAcademic
Michael Brenndoerfer. "Action Restrictions and Permissions: Controlling What Your AI Agent Can Do." Accessed 12/25/2025. https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents.
HARVARDAcademic
Michael Brenndoerfer (2025) 'Action Restrictions and Permissions: Controlling What Your AI Agent Can Do'. Available at: https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents (Accessed: 12/25/2025).
SimpleBasic
Michael Brenndoerfer (2025). Action Restrictions and Permissions: Controlling What Your AI Agent Can Do. https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents
Direct link:
https://mbrenndoerfer.com/writing/action-restrictions-and-permissions-ai-agents