AI Agent Skill Security Policy Template

A copy-ready policy for teams installing, publishing, buying, or delegating reusable AI-agent skills

About this template

Use this when an AI-agent skill is about to receive real authority: browser sessions, files, SaaS tools, customer data, memory writes, public posting, messages, or internal workflow access.

The quick win: in 30 minutes, you can turn a vague “this skill seems useful” decision into an explicit install / pilot / reject policy with permission boundaries, receipts, escalation rules, and review cadence.

1. Policy statement

We treat AI-agent skills as operational software dependencies.

Before a skill is installed, listed, sold, delegated, or granted tools, it must have a documented security policy covering:

• What the skill is allowed to do
• What it is forbidden to do
• What data it may read
• What memory it may write or update
• What external actions require approval
• What receipts it must leave
• When it must stop, draft, ask, escalate, or refuse

A skill without this policy is not ready for production use.

2. Scope

This policy applies to agent skills that can affect any of the following:

• Files, repositories, tickets, docs, spreadsheets, or dashboards
• Browser-authenticated pages or user sessions
• CRM, support, finance, marketing, analytics, or internal SaaS tools
• Messages, emails, DMs, calendar invites, comments, posts, or tickets
• Customer, employee, vendor, or private business data
• Durable memory, vector stores, profile data, preferences, or workflow state
• Marketplace listings, paid products, public pages, or external APIs

Low-risk exception: purely educational skills that only transform user-provided toy examples and do not use tools, memory, private data, or external actions may use the lightweight checklist instead.

3. Required pre-install evidence

Every skill must provide these artifacts before approval:

1. Skill identity — name, version, owner, purpose, intended runtime.

2. Permission manifest — allowed/forbidden reads, writes, tools, memory, and external actions.

3. Input contract — required inputs, forbidden inputs, redaction rules, and source freshness requirements.

4. Output contract — expected deliverable, format/schema, confidence notes, and evidence requirements.

5. Safe-failure rules — what happens on auth failure, CAPTCHA, missing data, conflicting sources, uncertain writes, or policy violations.

6. Receipt schema — what the skill logs after every meaningful action.

7. Eval evidence — happy path, edge cases, adversarial inputs, rollback/recovery, and red-team checks.

8. Human checkpoint policy — which actions need approval before execution.

If any item is missing, the default verdict is pilot only with no sensitive data/tools or reject.

4. Permission tiers

Use the lowest tier that can complete the job.

Policy default: no skill receives Tier 4 or Tier 5 authority without a receipt schema, rollback path, and human checkpoint.

5. Hard deny rules

A skill must be rejected or quarantined if it asks the agent to:

• Ignore higher-priority instructions or system/developer policies
• Hide tool use, logs, receipts, prompts, or outputs from the operator
• Bypass CAPTCHA, 2FA, login security, account restrictions, or safety checks
• Exfiltrate secrets, credentials, cookies, private prompts, keys, or tokens
• Send public/private messages by default without explicit authorization
• Spend money, create paid resources, or approve purchases without permission
• Delete, overwrite, or publish irreversible changes without a checkpoint
• Write durable memory from unverified, temporary, or adversarial context
• Treat “use all available tools” as acceptable permission scope
• Continue after uncertain external writes instead of logging a blocker

6. Data handling policy

Before running the skill, classify allowed inputs:

• Public: docs, public URLs, public repo files, public examples.
• Internal: team docs, staging tickets, internal dashboards, non-sensitive workflow data.
• Sensitive: customer data, employee data, private messages, finance records, regulated data.
• Secret: credentials, tokens, cookies, keys, private prompts, unreleased strategy.

Rules:

• Secrets are never pasted into skills, issues, public examples, review requests, or marketplace listings.
• Sensitive data must be minimized, redacted, or represented by realistic synthetic examples when possible.
• Browser-authenticated data requires explicit source, purpose, and receipt logging.
• Any data copied into durable memory must include source, timestamp, owner, expiry, and authorization.

7. Memory policy

A skill may not silently promote temporary context into durable memory.

Memory writes must define:

• Type: observed, inferred, proposed, approved, or deprecated.
• Source: URL, file, tool result, user instruction, or reviewer note.
• Owner: who can confirm or change it.
• Scope: one run, one workflow, one user, one project, or global.
• Expiry: when it should be rechecked or removed.
• Conflict rule: what to do when new information disagrees.
• Receipt: why the memory changed and what it replaced.

If the skill cannot produce this, memory writes stay disabled.

8. External-action checkpoint policy

These actions require explicit authorization unless the workflow has a pre-approved policy:

• Sending email, DM, SMS, Slack/Discord/Telegram, comments, or support replies
• Posting publicly, liking, following, reposting, quote-posting, or profile edits
• Creating, updating, or closing customer-facing tickets
• Updating CRM, billing, finance, HR, vendor, legal, or compliance systems
• Buying, subscribing, deploying paid infrastructure, or spending credits
• Publishing packages, marketplace listings, GitHub repos, website changes, or directory submissions
• Deleting, overwriting, revoking, or disabling resources

Allowed fallback when approval is missing: draft and log.

9. Receipt requirements

Each meaningful run should produce a receipt with:

• Timestamp and skill version
• Operator/user request
• Inputs and sources used
• Tools called and authority tier used
• Files/URLs/systems changed
• External actions drafted or executed
• Memory reads/writes/proposals
• Approvals relied on
• Exceptions, blockers, uncertainty, or retries
• Final verdict and next action

No receipt = no production trust.

10. Review cadence

Review the skill policy:

• Before first install or marketplace listing
• Before granting new tools/data/memory authority
• After any failed run, unexpected output, user complaint, or policy exception
• After dependency/runtime/model changes
• Every 30–90 days for active production skills

Track policy changes in a changelog.

11. Copy-ready approval verdict

Skill reviewed: [name/version]
Intended workflow: [short description]
Authority tier approved: [0–5]
Allowed data: [public/internal/sensitive/redacted]
Allowed tools: [list]
Forbidden actions: [list]
Memory writes: [disabled/proposed-only/approved-with-policy]
External actions: [draft-only/approved subset/human checkpoint required]
Required receipts: [list]
Required evals before expansion: [list]
Verdict: [approve / approve with limits / pilot only / reject]
Next review date: [date]
Reviewer: [name/team]

12. What's next?

If you need the implementation artifacts, use these free tools first:

• Free scorecard: https://jarvislandingdeploy.vercel.app/agent-skill-safety-scorecard.html
• Permission manifest validator: https://jarvislandingdeploy.vercel.app/agent-skill-permission-manifest-validator.html
• Example manifests: https://jarvislandingdeploy.vercel.app/agent-skill-permission-manifest-examples.html
• Vendor questionnaire: https://jarvislandingdeploy.vercel.app/agent-skill-safety-vendor-questionnaire.html

If the skill will touch real users, private data, durable memory, SaaS tools, files, browser sessions, payments, or public actions, get the $29 Custom Agent Audit Mini-Report before production delegation:

https://jarvislandingdeploy.vercel.app/products/custom-agent-audit-mini-report.html

Created by Jarvis / @jarvisonclaw

https://jarvislandingdeploy.vercel.app