Skip to main content

Skill Verification

Ensures agent skills are authentic and haven't been tampered with.

note

This guard is primarily relevant to developers and teams that deploy custom skills. If you only use built-in skills provided by CrabShack, this guard works automatically with no configuration needed.

What It Does​

Skills are code packages that give your agent specific capabilities. Since they execute with your agent's permissions, a tampered skill could do anything — steal data, change behavior, or escalate access. Skill Verification uses cryptographic signatures (a mathematical proof that a file hasn't been changed since it was approved) to confirm that every skill is authentic and unmodified.

Crucially, it doesn't just check skills when they're first loaded — it continuously re-verifies them at runtime to catch tampering that happens after the initial check. This prevents a class of attack where a skill passes verification at load time but gets modified before it's actually used.

Think of it as tamper-evident seals that are checked every time the package is opened, not just when it arrives. If anything has changed since the skill was signed, it's immediately blocked from running.

Why It Matters​

If an attacker can modify a skill between verification and execution, they can run arbitrary code with your agent's full permissions. Continuous verification closes this gap. It's especially important in environments where skills are loaded from shared storage or updated frequently, since those are the moments when tampering is most likely to go unnoticed.

What Gets Caught​

  • Unsigned skills — skills that don't have a valid cryptographic signature
  • Tampered skills — skills whose content has changed since they were last verified (detected both on a schedule and at the moment of execution)
  • Signature verification failures — skills where the signature doesn't match the content

What won't trigger it: Properly signed and unmodified skills. If you're developing skills locally and running into verification failures, you may need to re-sign the skill after making changes.

Example​

Scenario

A skill file is modified on disk after it was originally signed and deployed. The next time the agent attempts to use the skill, Skill Verification re-checks the cryptographic signature (a mathematical proof that the file hasn't been changed since it was approved) and finds the content no longer matches. The skill is immediately blocked from executing, and a critical alert is raised. The audit log shows a signature_mismatch event with the skill name, the expected signature, and a timestamp. If you're developing skills locally, you'll need to re-sign the skill after making changes.

Settings​

SettingWhat It Controls
Require SignaturesWhether skills must be cryptographically signed
Runtime VerificationWhether to re-verify skills each time they're used
Verification IntervalHow often to check skill integrity in the background

How It Responds​

Unsigned or tampered skills are blocked from executing. Tampering detected at runtime triggers a critical alert. All verification failures are logged.

If This Guard Blocks You​

  1. Check the audit log. Navigate to Security > Audit Log in the CrabShack dashboard. Filter by Skill Verification to find the relevant event. Click on the event row to expand it and see details including which skill and channel triggered it, the session key, and additional context.

  2. Understand the detection. The audit log shows the type of verification failure — unsigned_skill (the skill doesn't have a signature), signature_mismatch (the skill's content has changed since it was signed), or verification_error (the signature couldn't be validated). If you're developing skills locally and seeing signature_mismatch, you need to re-sign the skill after each change. If a previously working skill suddenly fails verification, investigate whether the skill file was modified — this could indicate tampering.

  3. Adjust if needed. Re-sign skills after making changes during development. This guard doesn't have a warn-only mode — unsigned or tampered skills are always blocked (fail-closed). See the Configuration page for details.

tip

Prefer creating a targeted exemption for a specific skill or channel over disabling the guard entirely. If you're seeing frequent false positives, a suppression lets you silence a specific detection label temporarily while you refine your settings.

Default Behavior​

Signatures are required. Runtime verification is enabled. Verification errors always fail closed, meaning the skill is blocked rather than allowed to run in an uncertain state.

  • Config Tamper Detection — monitors configuration files for unauthorized changes, complementing Skill Verification's focus on skill code integrity.
  • Filesystem Fence — restricts file access to authorized areas, adding another layer of protection for skill files on disk.