Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

AI agent skills and runtime scanning gaps: are your controls enough?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 12212
Topic starter  

TL;DR: AI agent skill marketplaces now carry the same supply chain risk pattern as software packages, but static code checks and LLM-based review both miss malicious behavior that only appears at runtime, according to Permiso Security. Runtime detonation is becoming the deciding control because executable trust cannot be inferred from code alone.

NHIMG editorial — what this means for AI and NHI governance

By the numbers:

Questions worth separating out

Q: How should security teams validate AI agent skills before installation?

A: They should execute each skill in a controlled sandbox with real agent context and inspect actual behaviour, not just source code.

Q: Why do AI agent skills create more risk than ordinary software packages?

A: AI agent skills inherit the permissions of the agent that runs them, so a malicious skill can act inside an existing trust boundary without needing to steal credentials first.

Q: What breaks when AI skills are judged only by static code review?

A: Static review misses behaviours that only appear at runtime, including hidden exfiltration, environment variable access, and unauthorized network calls.

Practitioner guidance

  • Detonate skills before allowing production use Run every downloadable skill in an instrumented sandbox with a live agent context, and require a behavioural verdict before any production installation or registry approval.
  • Separate skill approval from inherited agent privilege Review which IAM roles, API tokens, and service connections an agent already holds, then block skills from reaching those permissions until their behaviour has been verified.
  • Log runtime evidence at the LLM and OS layers Capture tool calls, file access attempts, DNS lookups, outbound requests, and credential access as part of the approval record so reviewers can validate what happened, not what was predicted.

What's in the full announcement

Permiso Security's full blog post covers the operational detail this post intentionally leaves for the source:

  • The four-step submit, detonate, analyze, and decide workflow for validating AI agent skills.
  • The full detection stack, including Sigma, YARA, Nova, and Snort, plus custom rules.
  • How SSL interception inside the sandbox exposes encrypted exfiltration attempts.
  • The cross-framework support details for OpenClaw, Cursor, Codex, and similar skill packages.

👉 Read Permiso Security's analysis of runtime sandboxing for AI agent skills →

AI agent skills and runtime scanning gaps: are your controls enough?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11787
 

AI agent skills are becoming a software supply chain, not a plugin ecosystem. The governance mistake is to treat downloadable skills as harmless add-ons when they are actually executable trust extensions that inherit existing agent permissions. Once that inheritance happens, the relevant control question is no longer whether the code looks safe, but whether the execution path can be verified under runtime conditions. Practitioners should therefore manage skills as governed supply-chain artefacts, not as informal configuration files.

A few things that frame the scale:

  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
  • 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

A question worth separating out:

Q: How can teams reduce the impact of a malicious AI skill?

A: They should limit the permissions an agent can lend to any skill, require sandbox detonation before production use, and keep a record of prior analyses so untrusted skills do not repeatedly reach approval decisions. The goal is to shrink inherited privilege before runtime behaviour can be abused.

👉 Read our full editorial: Static skill scanners miss runtime AI agent risk



   
ReplyQuote
Share: