AI agents increasingly require system-level access to perform their tasks effectively. Whether executing shell commands, manipulating files, or calling external APIs, these capabilities create a broad attack surface that adversaries actively exploit. If you cannot articulate precisely which commands your agent is permitted to execute and under what conditions, you have not defined a security boundary—you have granted a shell with natural language access.
This article provides a practical framework for establishing command boundaries that contain compromise without crippling functionality. The approach applies to any agent architecture, from LangChain-based systems to custom implementations.
The Implicit Permission Problem
Many agent deployments suffer from implicit permission models where capabilities are granted through tool availability rather than explicit authorization. When you provide an agent with a shell execution tool or file write capability, the default assumption often becomes "permitted unless blocked." This creates two critical vulnerabilities.
First, prompt injection attacks can reframe benign user requests into malicious commands. An attacker who controls part of the input—through a compromised data source, malicious document, or crafted conversation—can direct the agent to execute arbitrary operations. Second, the agent itself may misinterpret ambiguous instructions, generating destructive commands through alignment failures rather than adversarial action.
The fundamental question every operator must answer: Can you produce a documented list of every command your agent executed in the past 24 hours, classified by risk level and business justification? If not, your agent operates outside observable boundaries.
Implementing Command Allowlisting
The most robust defense is a strict allowlist model where the agent may only execute pre-defined commands with constrained parameters. This shifts security from runtime detection to configuration-time validation.
Consider a coding agent that needs to run tests and manage dependencies. Rather than granting general shell access, define specific safe operations:
from dataclasses import dataclass
from typing import List, Optional, Pattern
import re
@dataclass
class AllowedCommand:
name: str
pattern: Pattern
max_args: int
allowed_paths: List[str]
requires_approval: bool
# Define safe operations explicitly
ALLOWED_COMMANDS = [
AllowedCommand(
name="pytest",
pattern=re.compile(r"^pytest\s+(--[a-z-]+\s+)*[a-zA-Z0-9_./-]*$"),
max_args=10,
allowed_paths=["/workspace/tests/", "/workspace/src/"],
requires_approval=False
),
AllowedCommand(
name="pip_install",
pattern=re.compile(r"^pip\s+install\s+(--[a-z-]+\s+)*[a-zA-Z0-9_-]+(==[\d.]+)?$"),
max_args=5,
allowed_paths=["/workspace/"],
requires_approval=True # New packages need review
),
AllowedCommand(
name="git_status",
pattern=re.compile(r"^git\s+(status|log|diff|show)\s*(--[a-z-]+\s*)*$"),
max_args=3,
allowed_paths=["/workspace/"],
requires_approval=False
)
]
def validate_command(cmd: str, cwd: str) -> Optional[str]:
"""Returns None if valid, error message if rejected."""
for allowed in ALLOWED_COMMANDS:
if allowed.pattern.match(cmd):
if not any(cwd.startswith(p) for p in allowed.allowed_paths):
return f"Command not allowed in path: {cwd}"
return None # Valid
return f"Command not in allowlist: {cmd.split()[0]}"
This pattern prevents entire categories of attacks. An injected prompt requesting rm -rf / fails at validation because the command name is not in the allowlist. A request to pip install malicious-package triggers the approval requirement. The agent cannot escape these constraints through prompt engineering because the validation occurs outside the model's reasoning loop.
Layering Runtime Controls
Allowlisting provides strong prevention, but additional runtime controls catch edge cases and provide defense in depth. These mechanisms operate at execution time rather than configuration time.
Command sandboxing isolates agent operations within restricted environments. Container-based execution with read-only filesystems, network policies, and resource limits ensures that even if a command escapes allowlist validation, its blast radius remains contained. Consider running agent commands in ephemeral containers with no access to host credentials, limited network egress, and filesystem restrictions preventing writes outside designated working directories.
Execution logging and monitoring create observability into agent behavior. Every command should be logged with full context: the prompt that generated it, the user session, timestamp, and result. Anomaly detection on this log stream can identify patterns indicating compromise—unusual command frequencies, attempts to access sensitive paths, or sequences suggesting reconnaissance activity.
Human-in-the-loop approval provides final protection for high-risk operations. Any command matching patterns for data exfiltration, privilege escalation, or system modification should pause execution and request operator confirmation. This creates friction but prevents automated exploitation of high-impact vulnerabilities.
Measuring Boundary Effectiveness
Security boundaries must be tested to be trusted. Red team exercises should attempt to escape command constraints through various techniques: direct prompt injection, indirect injection through file contents, multi-turn conversation manipulation, and tool output poisoning.
Track metrics that indicate boundary health: - Command rejection rate: What percentage of generated commands fail validation? Sudden spikes suggest attack attempts or model degradation. - Approval request patterns: Are high-risk commands clustered around specific users or data sources? - Sandbox escape attempts: Has any command attempted to access paths outside allowed boundaries? - Mean time to boundary violation detection: How quickly does your monitoring identify constraint failures?
Regular boundary audits—reviewing the actual commands executed against the documented allowlist—prevent configuration drift where permissions expand gradually without security review.
Conclusion
Command boundaries are not a feature to add after deployment; they are foundational architecture decisions that determine your agent's security posture. Start with explicit allowlists, layer runtime controls, and continuously validate that boundaries hold against real attack patterns. The organizations that treat agent capabilities as privileges to be granted—rather than defaults to be restricted—will operate safely as autonomous systems become increasingly powerful.