Request Approval

Use Preloop's request_approval tool to get human approval before risky operations like deletions, production changes, or external modifications

Security Scan

The skill's documentation and runtime instructions are coherent with its stated purpose (using a Preloop request_approval MCP tool); it requests no unrelated credentials or installs and is instruction-only.

Purpose & Capability

The name/description (requesting human approval before risky operations) matches the instructions and examples. Required resources (a configured Preloop MCP server and an API token in agent configuration) are exactly what this capability needs; there are no unrelated environment variables, binaries, or config paths requested.

Instruction Scope

SKILL.md limits its behavior to: gather context about intended risky operations, call the request_approval tool, wait for human decision, then act (or not) based on approval. Example commands (ls, rm -rf, gh pr create, npm install, run migrations) are shown only as the operations that would be gated by approval. The instructions do not ask the agent to collect or exfiltrate data outside this approval flow.

Install Mechanism

There is no install spec (instruction-only), which is low risk. One setup example includes configuring the agent to run an `npx` command ("npx -y @modelcontextprotocol/server-everything") to provide MCP transport; that step would cause runtime download and execution of npm package code if followed, so administrators should review/approve that action in environments that disallow remote code installs.

Credentials

The skill declares no required env vars and does not demand unrelated credentials. Setup docs explain storing a Preloop API token in the agent's MCP configuration (Authorization header), which is proportional for a tool that communicates with an external approval service. The skill itself does not attempt to read or exfiltrate other environment variables or secrets.

Persistence & Privilege

The skill is not always-enabled (always:false) and does not request elevated or system-wide persistence. It does not instruct modifying other skills' configs. Model invocation is allowed (default) which is normal for a skill designed to be called by agents.

Assessment

This skill appears to be what it says: an instruction-only policy for using a Preloop approval tool. Before installing, verify you trust the Preloop endpoint (https://preloop.ai or your self-hosted URL) and the skill author. Note the setup guidance may suggest running `npx` to provide MCP transport — avoid running that in locked-down environments without review because it downloads and executes code. Ensure an appropriate approval policy and approvers are configured in Preloop, and confirm any API token used is stored only in your agent's MCP config (not copied into public places). If you want higher assurance, ask the skill author for: (1) a canonical source repository or homepage, (2) a maintainer identity you trust, and (3) confirmation that the agent configuration steps are optional (i.e., you can use an existing, vetted MCP transport instead of running npx).

Request Approval Skill

Use Preloop's request_approval MCP tool to get human approval before executing risky operations. Preloop will notify the user (via Slack, email, mobile apps, etc.) and wait for their response.

Setup

Preloop must be configured as an MCP server. See references/SETUP.md for configuration details.

When to Request Approval

ALWAYS Request Approval For:

• Deleting anything (files, directories, database records, cloud resources)
• Production changes (deployments, config changes, environment variables)
• Database operations (schema changes, migrations, bulk deletions/updates)
• External modifications (creating/merging PRs, posting to APIs, sending emails)
• Security changes (permissions, access controls, API keys)
• Financial operations (purchases, charges, refunds)
• System modifications (installing packages, changing system settings, CI/CD changes)

Usually Request Approval For:

• Creating pull requests or issues (unless explicitly requested)
• Pushing commits to main/master branches
• Modifying critical files (package.json, requirements.txt, docker-compose.yml, etc.)
• Running commands that modify system state
• Making bulk changes (affecting many files/records)

DON'T Request Approval For:

• Reading files or data
• Searching or querying
• Creating feature branches
• Running tests (in isolated environments)
• Making commits to feature branches

How to Use

Call the request_approval tool BEFORE executing the risky operation.

Parameters

Required:

• operation (string): Clear, specific description of what you'll do

  • ✅ Good: "Delete the logs/2024-01/ directory containing 1,234 log files (2.3GB)"
  • ❌ Bad: "Delete some logs"

• context (string): Additional details about what will be affected

  • ✅ Good: "This directory contains archived application logs from January 2024. The logs have been backed up to S3. Deleting will free up 2.3GB."
  • ❌ Bad: "Old logs"

• reasoning (string): Why this operation is necessary

  • ✅ Good: "Disk usage is at 92% capacity. These logs are archived in S3 and no longer needed locally."
  • ❌ Bad: "Need more space"

Optional:

• caller (string): Auto-populated by Preloop
• approval_policy (string): Specific approval policy name (uses account default if omitted)

Response

The tool returns a string:

• Approved: Success message → proceed with the operation
• Denied: "Approval denied" or "Approval denied: {reason}" → STOP, don't execute
• Error: Error message → check configuration or try again

Quick Example

Task: User asks to delete old cache files

Your workflow:

1. Check what exists: 3,421 cache files, 1.8GB, from last week
2. Call request_approval:
   • operation: "Delete the temp-cache/ directory"
   • context: "Contains 3,421 cache files totaling 1.8GB from batch jobs that ran last week. All jobs completed successfully."
   • reasoning: "Cache is no longer needed and is consuming disk space. Results are in the database."
3. Wait for response
4. If "denied" in response → tell user it's cancelled, ask for alternatives
5. If approved → proceed with deletion

See references/EXAMPLES.md for more examples.

Decision Framework

When unsure:

1. Can this be undone easily? NO → Request approval
2. Could this cause harm or data loss? YES → Request approval
3. Is this modifying production or external systems? YES → Request approval
4. Would a human want to review this first? YES → Request approval
5. Am I uncertain about the safety? YES → Request approval

Golden Rule: When in doubt, request approval. Better to ask unnecessarily than to cause harm.

If Approval is Denied

1. Stop immediately - do NOT proceed
2. Check for comments - denial may include reasoning
3. Inform the user - explain why it was cancelled
4. Look for alternatives - can you accomplish the goal differently?
5. Don't retry - don't ask again unless circumstances change

Best Practices

DO:

• ✅ Request approval BEFORE executing
• ✅ Be specific and detailed
• ✅ Include numbers (file count, size, affected records)
• ✅ Explain the impact
• ✅ Respect denials

DON'T:

• ❌ Execute first, then ask
• ❌ Be vague
• ❌ Bundle multiple operations
• ❌ Proceed if denied
• ❌ Skip approval because you think it's "probably fine"

Additional Resources

• references/SETUP.md - Configuration and MCP server setup
• references/EXAMPLES.md - Detailed examples and workflows
• references/TROUBLESHOOTING.md - Common errors and solutions

---

Remember: Safety first! Trust is earned by being cautious and respectful of the user's systems and data.