Full-schema poisoning is a broader version of tool poisoning that abuses any field in an MCP tool schema. Parameter names, defaults, enums, required arrays, and error messages can all carry hidden instructions. This expands the attack surface beyond descriptions and makes basic review or UI summaries insufficient.
How Full-Schema Poisoning Works
Full-schema poisoning expands tool poisoning beyond human-readable descriptions into the full MCP tool schema. Attackers can hide instructions in parameter names, defaults, enums, required fields, and error messages, which means the malicious content may survive review even when the description looks harmless.
The core issue is that schema fields are often treated as metadata rather than executable guidance. In an agentic workflow, that assumption breaks down because the model may interpret seemingly innocuous schema text as operational instruction, shaping what the tool does, what inputs it expects, or how it reacts to failures.
Why It Is Hard to Spot
Full-schema poisoning is difficult to catch because the malicious payload is distributed across places reviewers do not usually inspect together. A benign-looking parameter list can still steer the model if the names, enum values, or default arguments imply hidden intent, and error strings can reinforce that intent during retries or self-correction.
This makes basic UI summaries, truncated schema views, and casual code review weak defenses. The threat is not limited to one field carrying an obvious prompt, it is the cumulative effect of multiple fields that each appear normal in isolation but become suspicious when read as a whole.
Where the Security Boundary Breaks
Full-schema poisoning matters because MCP schemas are part of the trusted interface between a tool and the model using it. If an attacker can influence that interface, they can shape tool selection, parameter construction, and failure handling without needing direct access to the model prompt or the downstream system.
The boundary is especially fragile when schemas are generated, aggregated, or copied from third-party sources. A poisoned schema can travel through documentation, registries, or integrations and still look legitimate to downstream consumers that assume schema text is inert.
Practical Consequences for Agentic Systems
When the poisoned schema is used by an autonomous agent, the impact can extend beyond a single bad call. The model may repeatedly choose unsafe inputs, overtrust a deceptive enum, mis-handle required parameters, or follow error text that nudges it toward unintended behavior.
That can degrade reliability, create unsafe tool use, or amplify access to data and actions that the developer did not intend. In systems that chain multiple tools, one poisoned schema can also distort later reasoning steps and make the agent harder to audit after the fact.
Risk and Threat Considerations
Full-schema poisoning is risky because it targets the trust relationship between structured tool metadata and model behavior. The attacker does not need to break the tool itself if they can alter the instructions embedded in the schema that the model relies on to use that tool.
Failure mechanism: Hidden instructions in parameter names, defaults, enums, required arrays, or error messages can steer the model during planning, validation, retries, or output construction, even when the descriptive text appears safe.
Impact: The agent may execute unintended actions, select unsafe inputs, or persist a poisoned interpretation across repeated tool calls, which can lead to data exposure, privilege abuse, or unreliable automation.
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 MITRE ATLAS address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Full-schema poisoning steers agent tool selection and parameter use through tool-facing instructions. |
| ASI03 — Identity & Privilege Abuse | Poisoned schemas can redirect authenticated agent actions into unintended privilege use. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Schema poisoning can enter through upstream tool and integration supply chains. | |
| Recommendation — Validate tool schemas for hidden steering before allowing agents to consume them. Constrain agent actions so poisoned tool metadata cannot expand effective privilege. Review third-party tool schemas as supply-chain inputs before trust is granted. | ||
| MITRE ATLAS | Adversarial AI/ML Techniques | The term fits adversarial manipulation of model inputs through poisoned tool schema content. |
| Recommendation — Map poisoned schema patterns to adversarial technique detection in your AI threat model. | ||
| NIST AI RMF | Govern | Schema provenance, validation, and oversight are AI risk governance concerns for agentic tooling. |
| Recommendation — Establish governance for schema provenance, review, and approval before deployment. | ||
Practitioner Guidance
What to watch for: Review the entire schema as model-facing instruction, not just the description field. Pay attention to field names, default values, enum labels, validation text, and error strings, because those are all potential control points for hidden steering.
Governance implication: Treat schema provenance and change control as part of the tool supply chain. A schema that is generated externally, modified by a third party, or copied from an untrusted source should not be assumed safe simply because it validates structurally.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
