Why do tool descriptors create a security risk in AI systems?

Why This Matters for Security Teams

Tool descriptors are not passive documentation once an AI system ingests them. They shape what the model believes it can do, which means a manipulated description, schema, or discovery feed can become a live instruction channel. That creates a security boundary problem: capability metadata can carry ambient authority, especially when clients merge descriptors into system prompts or tool registries without validation.

This matters because tool exposure often sits at the intersection of AI governance, supply chain trust, and identity control. A compromised descriptor can redirect an agent toward unsafe actions, leak secrets through tool arguments, or make a benign integration behave like an attacker-controlled control plane. Guidance from the NIST Cybersecurity Framework 2.0 still applies, but it must be adapted for AI systems where discovery content is also execution content. NHI Management Group has documented how weak visibility into third-party connections and over-privileged access create predictable failure paths in The State of Non-Human Identity Security and related research such as the OWASP NHI Top 10.

In practice, many security teams encounter descriptor abuse only after a tool has already been trusted, loaded, and executed in production.

How It Works in Practice

The risk appears when an application treats tool descriptors as trusted input instead of untrusted content. In a well-designed system, the model receives a constrained, server-side view of available tools, and the runtime enforces schema, allowlists, and destination checks separately from what the model reads. In a weaker design, the client copies descriptors directly into the prompt, lets remote discovery populate the tools array, or accepts third-party updates without integrity controls.

That weakness creates several attack paths:

• Descriptor injection, where malicious text steers the model toward unsafe tool use or data disclosure.
• Schema poisoning, where altered fields make a tool appear broader or safer than it really is.
• Discovery tampering, where boot-time metadata is replaced before the agent authenticates the source.
• Ambient authority abuse, where the model treats descriptive text as permission rather than context.

Current best practice is to separate what the model can read from what the executor can do. Enforce signed or integrity-checked descriptors, pin tool definitions to a trusted registry, and evaluate every tool call at request time against policy, not just at configuration time. That means validating arguments, destinations, scopes, and session context before execution. NHI Management Group has shown how identity failures and exposed credentials accelerate compromise in cases like the LLMjacking research and the DeepSeek breach, where trust boundaries collapsed around secrets and connected systems. These controls tend to break down when tool catalogs are federated across teams because descriptor ownership, signing, and runtime enforcement are often split across different platforms.

Common Variations and Edge Cases

Tighter descriptor controls often increase integration friction, requiring organisations to balance rapid tool onboarding against stronger trust boundaries. That tradeoff becomes sharper in agentic environments, where teams want dynamic discovery, but dynamic discovery is exactly what expands the attack surface.

There is no universal standard for descriptor security yet, so guidance is evolving. Some environments can safely use static, pre-approved tool manifests. Others need runtime policy checks plus workload identity, especially when agents can chain tools or operate across multiple tenants. In those cases, the descriptor itself should be treated like a supply-chain artifact: versioned, signed, reviewed, and revoked when the source changes.

Edge cases include internal tools that seem low risk but can trigger privileged backends, and vendor-provided plugins that inherit trust from the platform but not from the organisation’s security model. The safest pattern is to assume the descriptor may lie, then confirm authority through cryptographic identity, policy enforcement, and scoped credentials at execution time. That aligns with the Ultimate Guide to NHIs — Why NHI Security Matters Now and the broader identity visibility issues outlined in Top 10 NHI Issues. This guidance breaks down when legacy middleware cannot separate metadata ingestion from execution, because the model’s context window becomes the enforcement surface.

Related resources from NHI Mgmt Group

• Why do agentic AI systems create more security risk than standard chatbots?
• Why do training data changes create security risk in AI systems?
• Why do AI systems create both safety and security risk?
• Why do AI models with tool access create security risk even when they are not autonomous?