A trojanised AI skill is a package that presents legitimate functionality while embedding hidden malicious behaviour. In practice, it can install secondary payloads, read sensitive files, or alter runtime behaviour after approval, making it both a software supply-chain risk and an identity governance problem.
Expanded Definition
A trojanised ai skill is not just a malicious plugin or prompt wrapper. It is a packaged capability that appears legitimate at approval time but carries hidden behaviours that activate later, such as file access, covert data exfiltration, privilege escalation, or runtime manipulation. In NHI terms, the risk is that the skill inherits the agent’s execution authority and trusted identity context once installed. That makes it a supply-chain issue and an identity governance issue at the same time.
Definitions vary across vendors, because some products call these skills extensions, actions, tools, or plugins. The security question is the same: does the package do only what it advertises, and can its execution be bounded by policy? Good practice is to evaluate it through the lens of least privilege, signed provenance, and runtime monitoring, aligning with guidance such as NIST Cybersecurity Framework 2.0. The most common misapplication is treating a skill review as a one-time marketplace approval, which occurs when teams ignore post-install behaviour, transitive dependencies, or permission drift.
Examples and Use Cases
Implementing AI skills rigorously often introduces friction in deployment speed, requiring organisations to weigh developer convenience against the cost of deeper inspection and tighter permissioning. That tradeoff is unavoidable when the skill can act on behalf of a high-trust agent.
- A customer-support agent installs a “ticket summariser” that quietly reads mailbox attachments and sends copies to an external endpoint after approval.
- A coding assistant skill requests broad repository access, then modifies build scripts to embed a secondary payload in released artefacts.
- A finance automation skill claims to generate reports, but also enumerates local secrets and forwards tokens into attacker-controlled storage.
- A marketplace tool appears harmless during review, yet its dependency chain reaches a loader that changes behaviour after an update.
- An enterprise agent uses a skill only for document formatting, but the skill later pivots into sensitive-file discovery because its permissions were never constrained.
These patterns are already consistent with incidents and research discussed in DeepSeek breach, where embedded secrets and exposed records showed how hidden risk can sit inside trusted AI workflows. For identity-aware deployment patterns, practitioners also use the SPIFFE model to separate workload identity from opaque package trust.
Why It Matters in NHI Security
Trojanised AI skills matter because they turn trusted automation into a durable attack surface. Once installed, the skill can operate under the identity, permissions, and session context of the agent or user that approved it. That creates exposure to secrets, internal APIs, records, and operational controls that were never meant to be reachable by an unvetted package. In practice, the failure mode is often not immediate compromise but gradual abuse through approved access pathways.
NHIMG research shows how quickly AI-related identity abuse can become operationally real: when exposed credentials are available, attackers may attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs. That urgency is why security teams map skill governance to broader controls in the NIST Cybersecurity Framework 2.0 and identity-centric monitoring guidance from CISA. Organisations typically encounter the true impact only after anomalous data access, secret leakage, or unexplained tool behaviour surfaces in incident response, at which point trojanised AI skill review becomes operationally unavoidable to address.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Addresses agent tool abuse and malicious capability insertion in AI workflows. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and abuse when malicious skills reach credentials or tokens. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access control are central when a skill inherits trusted execution context. |
| NIST Zero Trust (SP 800-207) | Zero trust requires explicit verification of every tool action, not implied trust in packages. | |
| NIST AI RMF | AI risk management includes provenance, misuse, and post-deployment monitoring of AI components. |
Treat each skill invocation as untrusted until authenticated, authorised, and continuously observed.
