They often assume platform adoption equals governance coverage. In reality, employees can install skills faster than security teams can review them, and many skills are designed to look benign. Without continuous inventory and instruction scanning, organisations do not know which skills are present, what they can access, or when they should be removed.
Why This Matters for Security Teams
agent skill visibility is not a cataloging problem alone. It is a governance and attack-surface problem, because skills can expand what an agent can read, write, call, or chain without looking suspicious at install time. Security teams often assume that approval workflows, app stores, or platform defaults provide enough coverage, but skills can be added faster than they can be reviewed, and their real effect only appears at runtime.
That gap matters because skills often inherit the agent’s existing access and can quietly turn a low-risk assistant into a workflow executor with broad tool reach. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful proxy for how weak identity inventory tends to be once automation scales. For agent ecosystems, the same visibility problem shows up in instruction sets, connectors, and delegated permissions. Current guidance from the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 points to runtime risk, not just approval-time trust. In practice, many security teams discover risky skills only after data has already moved through them or an agent has already chained them into a broader workflow.
How It Works in Practice
Effective skill visibility starts with treating every skill as a governed capability, not a harmless plugin. The minimum control set is: continuous inventory, instruction and prompt inspection, permission mapping, runtime usage logging, and automated removal when a skill is inactive, duplicated, or over-privileged. Security teams should be able to answer four questions at any moment: what skills exist, which agents can invoke them, what data or tools they can reach, and whether their behaviour matches the intended use case.
In operational terms, that means building a live register of skills and connectors, then enriching each entry with ownership, purpose, data access scope, and expiry. Pair that with policy-as-code so new skills are evaluated against guardrails before and after approval. The CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework both support this shift from static trust to ongoing oversight. At the identity layer, the core question is whether the skill is using a shared credential, a delegated token, or a short-lived workload identity. That distinction matters because long-lived secrets let one overlooked skill remain active far beyond its useful life.
NHI Management Group’s OWASP NHI Top 10 coverage of agentic applications is relevant here because skills frequently act as the bridge between identity sprawl and tool abuse. Mature teams also scan skill instructions for hidden tool invocation patterns, external endpoint use, and escalation hints, then correlate that with actual execution telemetry. These controls tend to break down in self-service environments where non-security teams can install skills directly, because inventory lags behind adoption and reviewers never see the full set of effective permissions.
Common Variations and Edge Cases
Tighter skill control often increases friction for product teams and slows experimentation, so organisations must balance developer autonomy against exposure from unreviewed capabilities. Best practice is evolving, and there is no universal standard for skill risk scoring yet, especially across SaaS copilots, internal agent frameworks, and custom toolchains.
One common edge case is the “benign skill” that only becomes dangerous when combined with another connector, such as email, file storage, or ticketing. Another is preinstalled vendor content that looks trusted but still expands the agent’s effective permissions. Teams also underestimate transitive access: a skill may not hold secrets directly, but it can instruct an agent to use a credential the agent already has. That is why visibility must include both declared permissions and observed behaviour.
For implementation detail, the most reliable pattern is to align skill inventories with zero standing privilege, short-lived tokens, and explicit review triggers for newly added instructions. The Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio illustrate how quickly agent capabilities can be abused once trust is assumed instead of continuously verified. The hard limit is multi-tenant or highly dynamic environments where skills are created, modified, and retired faster than control owners can reconcile inventory with runtime use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Unreviewed skills expand agent attack surface and enable unsafe tool chaining. |
| CSA MAESTRO | M4 | MAESTRO addresses runtime governance for agent capabilities and connected tools. |
| NIST AI RMF | AI RMF emphasizes lifecycle governance, monitoring, and accountability for AI systems. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Skills often hide credential and permission sprawl behind seemingly harmless integrations. |
| NIST CSF 2.0 | PR.AC-4 | Access control must reflect what skills can actually reach at runtime. |
Inventory agent skills continuously and block skills that exceed approved tool and data boundaries.
