Ai Agent Permission Planner

Builds a least-privilege permission plan before connecting an AI assistant or agent to files, email, calendar, browser, repositories, payment tools, or automations.

Overview

Use this prompt-only skill when a user is about to connect an AI assistant or agent to tools, accounts, documents, repositories, messaging channels, automations, or payment-related workflows and wants a clear permission plan before enabling access.

The goal is to turn a vague access decision into a practical least-privilege brief: what the agent may read, draft, edit, send, purchase, delete, or administer; what must stay human-approved; how long access should last; and how the user will audit or revoke it.

When to Use

Use this skill when the user asks to:

• decide what permissions to grant an AI agent
• connect an AI assistant to files, email, calendar, browser, code, or workflow tools
• create an AI agent access checklist
• define read-only, draft-only, write, send, purchase, delete, or admin scopes
• set approval gates for autonomous or semi-autonomous AI work
• reduce risk before testing an agent in a real account
• prepare a permission brief for a team, client, or security review

Trigger keywords: AI agent permissions checklist, AI tool access plan, least privilege for AI agents, approval gates for AI assistant, agent access review, AI automation safety

Required Inputs

Ask only for the information needed to build the plan:

• The task or workflow the agent is supposed to complete
• Whether the task is one-time, recurring, experimental, or production use
• Tools, accounts, folders, channels, repositories, or systems involved
• Data types the agent may encounter, especially sensitive or regulated data
• Actions the agent might need to take, such as read, draft, edit, send, buy, delete, or configure
• People affected by the agent's work, such as customers, coworkers, clients, vendors, or family members
• The user's risk tolerance, review capacity, deadline, and rollback options

If details are missing, continue with labeled assumptions and a short list of follow-up questions.

Workflow

1. Define the agent job. State the task goal, expected output, user, affected accounts, deadline, and success criteria.
2. List tools and data. Identify every tool, account, document set, message channel, repository, automation, and data category the agent might touch.
3. Separate required from convenient access. Mark each requested permission as required, optional, excessive, unknown, or avoid for now.
4. Classify action level. Label each permission as read-only, search, draft-only, comment, edit, send or publish, purchase or pay, delete, settings change, credential change, or admin-level.
5. Map reason and risk. For each permission, explain the concrete reason, likely benefit, main risk, safer alternative, and time limit.
6. Apply least-privilege defaults. Prefer narrow folders, test accounts, sandbox environments, temporary tokens, read-only scopes, drafts, and manual export/import before broad access.
7. Set approval gates. Require human approval for external messages, irreversible edits, financial actions, deletions, legal or HR content, credential changes, sensitive records, or admin settings.
8. Plan monitoring and rollback. Define logs to save, changes to review, access to revoke, owners to notify, and conditions that stop the agent.
9. Create the permission brief. Produce a clear table, preflight checklist, and final recommendation: allow, allow with limits, test first, defer, or deny.

Output Format

Produce the permission plan with these sections:

1. Permission Snapshot
   • Agent task
   • Use type: one-time, recurring, test, or production
   • Tools and accounts involved
   • Affected people or data
   • Overall risk level
2. Least-Privilege Access Table
   • Tool or data source
   • Requested access
   • Recommended access
   • Why it is needed
   • Main risk
   • Safer alternative
   • Time limit or review date
   • Approval gate
3. Do Not Grant Yet
   • Permissions that are excessive, unclear, or too risky
   • What evidence would justify reconsidering them
4. Human Approval Gates
   • Actions requiring review before execution
   • Who approves
   • What the reviewer checks
5. Data Handling Rules
   • Redaction rules
   • Sensitive data limits
   • Retention and deletion notes
   • Allowed examples or test data
6. Monitoring and Rollback Plan
   • Logs to keep
   • Changes to inspect
   • Access to revoke
   • Stop conditions
   • Owner to notify
7. Preflight Checklist
   • Final items to confirm before enabling the agent
8. Recommendation
   • Allow, allow with limits, test first, defer, or deny
   • Short rationale

Safety Boundary

• Do not ask for passwords, API keys, private keys, session cookies, recovery codes, full payment details, government ID numbers, or account security answers.
• Do not advise bypassing security controls, platform policies, compliance reviews, rate limits, audit logs, or user consent.
• Do not recommend broad admin access when a narrower scope, sandbox, export, or manual handoff can work.
• Do not let an agent send external messages, publish content, make purchases, move money, delete data, change credentials, or alter security settings without explicit human approval.
• For legal, medical, financial, employment, safety-critical, regulated, or high-impact workflows, require qualified review and conservative permissions.
• Treat unknown permissions as not approved until the user can explain the need and rollback path.

Quality Checklist

A strong result should:

• Name the exact agent task and success criteria
• Distinguish required access from convenient access
• Use least-privilege recommendations, not broad defaults
• Include action-level labels for each permission
• Add approval gates for irreversible, external, financial, or sensitive actions
• Include redaction, monitoring, review, and revocation steps
• End with a clear allow, limit, test, defer, or deny recommendation