Skill Signing and Review

Skill signing and review is a security feature that enforces approval gates on custom skills. Before any agent can use a skill, it must be reviewed and approved by a workspace admin or reviewer. Each skill is cryptographically signed with a checksum to detect tampering.

Why skills need review

Custom skills are powerful — they give agents new capabilities and often access to external systems. Without review:

• Malicious code — a rogue skill could exfiltrate data or cause damage
• Unintended behavior — a developer might accidentally introduce bugs or anti-patterns
• Compliance gaps — regulated teams need to audit what code runs in production
• Supply chain risk — if a skill is imported from a registry, you need to verify its contents

How skill review works

1. Author creates or edits a skill — starts in draft state
2. Author submits for review — status changes to pending_review
3. Reviewer inspects — sees the code, file attachments, and a diff if it's an update
4. Reviewer decides — approve (agents can use it) or reject (with feedback)
5. If approved — skill is now active; agents can load it into tasks
6. If edited later — approval is cleared and re-review is required

Skill lifecycle

draft

A new skill or an unapproved edit. Agents cannot use it. Only the author and workspace admins can see it in full.

pending_review

The skill is awaiting reviewer decision. It appears in the Skills → Pending Review queue. Agents still cannot use it.

approved

Reviewer has signed off. The skill is active and agents can load it into tasks. The approval is cryptographically bound to the exact content via a checksum.

rejected

Reviewer denied the skill with feedback. Author can edit and re-submit, or abandon. Agents cannot use it.

revoked

A skill's content was tampered with after approval (checksum mismatch). The skill is immediately disabled and agents cannot load it. This is a security signal to investigate.

Versioning and checksums

Each time you create or edit a skill, AACWorkflow:

1. Computes a checksum (SHA256) of the skill content and any attached files
2. Stores the checksum with the approval so approval is bound to exact content
3. Keeps a version history so reviewers can diff changes

When an agent tries to use the skill at task time:

• AACWorkflow verifies the stored checksum matches the current content
• If checksums don't match (content was edited or tampered), the skill is marked revoked
• The agent cannot load it and is notified of the security issue

Creating and submitting skills for review

Create a skill

1. Go to Skills → Create Skill
2. Fill in name, description, and content
3. Attach files if needed (Python scripts, data files, etc.)
4. Click Create

The skill starts in draft state. Only you and workspace admins can see it.

Submit for review

1. Open the skill
2. Review the content one more time
3. Click Submit for Review
4. Optionally add a message to the reviewer

The skill moves to pending_review and appears in the reviewer queue.

Edit before review

If you're in draft or rejected state, you can edit freely. Click Edit, make your changes, and save.

If the skill is approved and you need to make changes:

1. Click Edit
2. Make your changes and save
3. The skill automatically moves back to pending_review
4. A new version is created and reviewers can see a diff of what changed

Reviewing skills

View pending skills

1. Go to Skills → Pending Review
2. See a list of skills waiting for approval

Review a skill

1. Open the pending skill
2. Read the description and inspect the code
3. If it's an update (version > 1), click View Diff to see what changed
4. Decide:
   • Approve — the code is safe and fits your standards; agents can use it
   • Reject — the code has issues; provide feedback for the author

Diff view

When reviewing an update, the diff view shows:

• Lines removed (red) — code the author took out
• Lines added (green) — new code
• Context — a few lines before and after each change

Use this to spot:

• Unexpected changes to critical sections
• New external calls or dependencies
• Scope creep or feature drift

Approve a skill

1. Open the skill in pending_review
2. Click Approve
3. Optionally add reviewer notes (these are visible to the author and appear in audit logs)
4. Click Confirm

The skill moves to approved and agents can immediately start using it.

Reject a skill

1. Open the skill in pending_review
2. Click Reject
3. Add required feedback — explain what needs to change
4. Click Confirm

The skill moves to rejected. The author sees your feedback and can edit and re-submit.

Tool restrictions

When reviewing, a reviewer can optionally set allowed_tools — a whitelist of external tools the skill is permitted to use. For example:

• Skill github-pr-reviewer might be restricted to github_api only
• Skill aws-cost-checker might be restricted to aws_api only

If the skill tries to use a tool outside this whitelist:

• The restriction is enforced at task runtime
• The agent receives an error and cannot proceed
• The attempt is logged in audit trails

This lets reviewers limit blast radius even if the skill is later found to be problematic.

Auditing and compliance

Every skill action is logged:

• Skill creation, edits, and deletions
• Submissions for review
• Approvals, rejections, and revocations
• When agents load and use skills
• Checksum mismatches and tampering attempts

Access the audit log in Settings → Audit Logs and filter by "Skills" to:

• Track who approved which code
• See when skills were edited
• Investigate security incidents (revoked skills, checksum failures)

Best practices

• Review thoroughly — skills run on behalf of agents; treat them like code reviews
• Expect questions — ask authors to explain critical sections
• Use tool restrictions — limit each skill to the minimum tools it needs
• Rotate reviewers — don't let one person approve everything
• Check for updates — review diffs carefully when skills are edited
• Revoke if suspicious — if a skill behaves unexpectedly, revoke it and investigate

Bulk actions

Enterprise admins can:

• Revoke a skill — immediately disable it workspace-wide (if tampering is suspected)
• Require re-approval — force all approved skills into pending_review (after a policy change, for example)
• Audit all versions — view the complete version history and diffs

Use Settings → Skills → Governance to perform these bulk actions.

Next steps

• Private skill registry — host internal skills in a private registry
• Runtime capability registry — declare which tools and APIs your runtimes support
• Skills — learn how to create and use skills