# Scope Governance Controls for Agent Skill Sandboxing: A Multi-Layered Security Model

> Discover the multi-layered security model for agent skill sandboxing in rohitg00/ai-engineering-from-scratch. Learn about explicit sandbox policies and action review scripts for deterministic scope governance.

- Repository: [Rohit Ghumare/ai-engineering-from-scratch](https://github.com/rohitg00/ai-engineering-from-scratch)
- Tags: security
- Published: 2026-08-29

---

**The rohitg00/ai-engineering-from-scratch repository implements deterministic scope governance controls through an explicit sandbox policy JSON, an action review script that returns allow/deny/gate decisions without executing code, and a four-layer architecture separating instruction, permission, sandbox enforcement, and verification.**

This system provides a production-ready framework for constraining AI agent capabilities through rigorous scope governance controls. The implementation ensures that agent skills operate within strictly predefined boundaries by validating every requested action against declarative policies prior to execution. Located within the skill-safety-reviewer module, this approach demonstrates how to enforce least-privilege principles for autonomous agents using deterministic, policy-driven validation rather than runtime interpretation.

## Explicit Sandbox Policy Configuration

The foundation of the governance model rests on **sandbox-policy.json**, a declarative JSON document that explicitly enumerates all permissible resources. This policy defines precise filesystem paths, allowed shell commands, whitelisted network destinations, permitted environment variables, and other system resources that a skill may access.

According to the source code analysis, any resource request not explicitly listed in [`phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/sandbox-policy.json`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/sandbox-policy.json) is automatically denied or escalated to a "gate" status for additional review. This **default-deny posture** ensures that agent skills cannot access unintended system capabilities through implicit permissions or ambient authority.

## Deterministic Action Review Pipeline

The [`review_action.py`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/review_action.py) script serves as the deterministic enforcement engine for scope governance controls. Located at [`phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/scripts/review_action.py`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/scripts/review_action.py), this script consumes a skill-generated action request and evaluates it against the sandbox policy without executing any code.

The script returns one of three deterministic outcomes:

- **allow** – The requested action falls within explicitly defined policy boundaries.
- **deny** – The requested action violates explicit prohibitions or falls outside all allowed scopes.
- **gate** – The request requires additional human or automated review before proceeding.

This validation occurs entirely during the analysis phase, providing security decisions based on static policy evaluation rather than runtime behavior monitoring. The script accepts two command-line parameters: `--policy` pointing to the JSON configuration and `--request` containing the skill's intended action.

## Four-Layer Policy Architecture

As documented in [`SKILL.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/SKILL.md), the scope governance controls separate concerns across four distinct architectural layers:

### Instruction Layer

This layer captures what the skill *asks* for, representing the raw intent of the agent before any policy evaluation occurs. It defines the action request structure that skills must submit for review.

### Permission Layer

This layer grants a narrow, immutable record of the request after approval. It creates an auditable trail of specifically what was authorized, distinct from what was requested or what was blocked.

### Sandbox Layer

The sandbox layer enforces OS-level containment mechanisms such as OCI containers, read-only filesystem mounts, and network namespaces. This layer operates independently from the permission system, ensuring that even approved actions execute within hardware-enforced boundaries.

### Verification Layer

This final layer records the result of policy evaluation for auditability and compliance. It maintains immutable logs of allow/deny/gate decisions to support forensic analysis and policy refinement over time.

The documentation emphasizes that the **sandbox is a boundary, not a trust verdict**, and that approval and sandboxing function as independent checks within this architecture.

## Practical Implementation and Testing

The repository includes [`example-request.json`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/example-request.json) at [`phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/example-request.json`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/example-request.json) to demonstrate how skills describe intended actions. You can evaluate the governance decision flow by running the review script against this sample request:

```bash

# Inspect the sandbox policy configuration

cat phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/sandbox-policy.json

# Examine the example skill request structure

cat phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/example-request.json

# Execute the policy review (no code is executed)

python3 phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/scripts/review_action.py \
  --policy assets/sandbox-policy.json \
  --request assets/example-request.json

```

When evaluating a request to access `/tmp/input` within allowed read-only mounts, the script returns:

```json
{
  "decision": "allow",
  "reason": "Requested path /tmp/input is within allowed read‑only mount."
}

```

Conversely, requests attempting to write to `/etc/passwd` or reach non-whitelisted external URLs trigger `deny` or `gate` responses with explanatory reasoning.

## Summary

- **Explicit JSON Policy** – [`sandbox-policy.json`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/sandbox-policy.json) defines the complete scope of permissible actions through declarative allow-lists.
- **Deterministic Review** – [`review_action.py`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/review_action.py) evaluates requests without code execution, returning allow/deny/gate decisions based on static analysis.
- **Layered Architecture** – The system separates instruction capture, permission granting, OS-level sandboxing, and verification logging into distinct, auditable layers.
- **Default-Deny Posture** – Any action not explicitly permitted by policy is automatically denied or escalated for review.
- **Repository Location** – All components reside within `phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/`.

## Frequently Asked Questions

### What distinguishes "deny" from "gate" decisions in the scope governance controls?

A **deny** decision indicates that the requested action explicitly violates the sandbox policy or falls outside all defined permission scopes, resulting in immediate rejection without further review. A **gate** decision indicates that the request requires additional scrutiny—either human approval or automated secondary validation—before granting execution rights, typically used for actions that might be permissible under specific contextual constraints not captured by the static policy.

### How does the action review script prevent code execution during validation?

The [`review_action.py`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/review_action.py) script performs static analysis of the JSON request structure against the declarative policy rules without spawning subprocesses, importing modules, or evaluating the actual code payload intended for execution. This design ensures that malicious or malformed skill requests cannot compromise the review system itself, as the validator examines only the action metadata and resource descriptors rather than executing the skill's logic.

### Where is the sandbox boundary definition stored in the repository?

The primary sandbox boundary definition resides in [`phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/sandbox-policy.json`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/13-tools-and-protocols/26-skill-permissions-sandboxes-and-trust/outputs/skill-safety-reviewer/assets/sandbox-policy.json). Additionally, the [`site/data.js`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/site/data.js) file contains a glossary entry linking the term "sandbox" to its governance description, providing a centralized index of security terminology used throughout the codebase.

### Why does the architecture treat approval and sandboxing as independent checks?

The **SKILL.md** documentation clarifies that approval represents a policy decision about *what* a skill is permitted to do, while sandboxing represents an enforcement mechanism about *where* and *how* execution occurs. Separating these concerns prevents privilege escalation—an approved skill still cannot escape its containerized environment, and a compromised sandbox does not automatically grant permissions beyond those explicitly approved in the policy layer.