# Policy Gen

> Generate the policy agent YAML security policies for agent sandboxing. Inspects a project's structure and produces deny-by-default policies for filesystem, network, and process capabilities. Use when the user says "the policy agent policy", "agent sandbox", "generate security policy", "sandbox config", "the policy agent yaml", or wants to create agent security boundaries for a project.

- Skill: `m2ai-portfolio/policy-gen` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add m2ai-portfolio/policy-gen`
- Raw SKILL.md: https://api.skillmd.com/api/skills/m2ai-portfolio/policy-gen/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: m2ai-portfolio (https://skillmd.com/u/m2ai-portfolio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/m2ai-portfolio/policy-gen

---


# the policy agent Policy Generator — Agent Sandbox Configuration

Inspect a project and generate starter the policy agent YAML policies with sensible deny-by-default rules for filesystem access, network egress, and process capabilities.

## Prerequisites

- Target project must be locally accessible
- the policy agent is Nvidia's open-source agent security stack (released GTC 2026)
- No the policy agent installation required for policy generation (policies are declarative YAML)

## Phase 1: Project Analysis

1. Identify the project root and primary language/framework.
2. Scan for:
   - **File access patterns**: Which directories the code reads/writes (src/, data/, logs/, tmp/, config/)
   - **Network dependencies**: API endpoints, database connections, external services (from env vars, config files, import statements)
   - **Process spawning**: Subprocess calls, shell exec, child process patterns
   - **Secrets locations**: .env files, credential paths, key references
3. Catalog all discovered patterns into three categories: filesystem, network, process.

## Phase 2: Policy Template Selection

Based on project type, select the appropriate base template:

### Web Application (Next.js, FastAPI, Express, etc.)
- Filesystem: read src/, write logs/ and tmp/ only
- Network: allow outbound to declared API hosts, deny all else
- Process: allow build tools (node, python, npm), deny shell exec

### CLI Tool / Agent
- Filesystem: read project root, write output dir only
- Network: allow declared endpoints only
- Process: allow language runtime, deny all else

### MCP Server
- Filesystem: read project root + MCP data dir, write MCP data dir only
- Network: stdio transport only (deny all network by default)
- Process: allow node/python runtime only

### Library / Package
- Filesystem: read src/ and tests/ only, write nothing
- Network: deny all (libraries shouldn't make network calls)
- Process: allow test runner only

## Phase 3: Policy Generation

Generate the the policy agent YAML policy file:

```yaml
# the policy agent-policy.yaml
# Generated by policy-gen skill
# Project: [project-name]
# Date: [date]

version: "1.0"
agent: "[project-name]"

filesystem:
  default: deny
  rules:
    - path: "./src/**"
      access: read
      reason: "Source code access"
    - path: "./config/**"
      access: read
      reason: "Configuration files"
    - path: "./logs/**"
      access: [read, write, create]
      reason: "Application logging"
    - path: "/tmp/[project-name]/**"
      access: [read, write, create, delete]
      reason: "Temporary working directory"
    # [additional rules based on analysis]

network:
  default: deny
  rules:
    - host: "[discovered-api-host]"
      ports: [443]
      protocol: https
      reason: "[service name] API access"
    # [additional rules based on analysis]

process:
  default: deny
  rules:
    - command: "[runtime]"  # node, python3, etc.
      args_pattern: "**"
      reason: "Language runtime"
    - command: "[package-manager]"  # npm, pip, etc.
      args_pattern: "install *"
      reason: "Dependency installation"
    # [additional rules based on analysis]

# Secrets: these paths should NEVER be accessible to agents
secrets_deny:
  - "~/.env*"
  - "**/.env"
  - "**/credentials*"
  - "**/*secret*"
  - "~/.ssh/**"
  - "~/.aws/**"
```

## Phase 4: Policy Hardening

Review generated policy for common mistakes:

1. **Overly broad filesystem rules**: `/` or `~/**` should never appear in allow rules
2. **Wildcard network access**: `*:*` defeats the purpose; every host must be named
3. **Missing secrets deny**: Verify all known secret paths are in the deny list
4. **Process escape hatches**: `bash`, `sh`, `cmd` should only be allowed if explicitly needed with constrained args
5. **Write access scope**: Write rules should be as narrow as possible (specific dirs, not project root)

Flag any concerns to the user before finalizing.

## Phase 5: Output & Integration

1. Write the policy to `the policy agent-policy.yaml` in the project root.
2. Generate a companion `the policy agent-policy.md` with:
   - Summary of what the policy allows/denies
   - Rationale for each rule
   - Instructions for testing the policy
   - How to extend it when new dependencies are added
3. Suggest adding `the policy agent-policy.yaml` to the project's CI validation.

## Verification

- [ ] Every filesystem rule has a specific path (no root-level wildcards)
- [ ] Every network rule has a named host and port
- [ ] Secrets paths are explicitly denied
- [ ] Default for all three categories is "deny"
- [ ] Policy is valid YAML (syntax check)
- [ ] User reviewed and approved before writing to project

## When NOT to Use This

- Project already has a the policy agent policy (offer to audit instead)
- Project is a pure library with no runtime component (may still benefit from test-time policy)
- User wants runtime enforcement setup (this skill generates config only, not the policy agent installation)

## Source Attribution

Based on Nvidia's the policy agent agent security stack (open-sourced at GTC 2026).
Via Nate's Newsletter (2026-03-24): "Accenture booked $2.2 billion in AI consulting last quarter."