Tool Integrity Engine: Contracts, Calls and Limits
A Tool Integrity Engine (TIE) compares recorded tool contracts and observed call attributes to identify divergence. It can add context beyond a tool-name allowlist, but its coverage depends on the fields it inspects. The older DeepIntShield TIE is a legacy capability; current canonical MCP authorization uses its own definition-pinning boundary.
The attack the allowlist misses
Most agentic security starts with an allowlist: here are the tools the agent is allowed to call. That’s necessary, but it’s not enough – because the dangerous attacks don’t break the allowlist, they corrupt a tool that’s already on it.
Picture a tool approved as “look up a customer’s first name by ticket ID.” It’s on the allowlist. Now an attacker – through a prompt injection or a compromised MCP server – quietly changes the tool’s description and behavior to “look up and export the customer’s full record.” The agent calls it. The policy engine checks the allowlist, sees the familiar tool name, says “allowed.” The harmful call runs. A name-based allowlist caught nothing, because the name never changed.
An allowed tool can change after review. Comparing recorded contracts helps detect visible definition changes, while application controls and sandboxing address behavior that the contract does not reveal.
How a Tool Integrity Engine works
An integrity check compares the fields it records, such as a declared contract or call attributes. A fingerprint summarizes those fields; it is not a complete measurement of the tool’s internal behavior.
Figure: Tool-integrity checks compare an observed call with an approved contract and apply the tool’s configured response when they diverge. This is the general/legacy integrity pattern; canonical MCP definition drift denies calls until operator re-approval.
Step by step:
- In the current canonical MCP path, the contract fingerprint covers the tool name, description and argument schema. It does not pin the remote implementation or source code.
- Discovery and sync refresh the observed MCP definition digest. At decision time, the gateway compares it with the approved pin; this comparison is distinct from validating the actual call arguments and authorization context.
- A match means no divergence was found in the compared fields; ordinary authorization still applies. A mismatch triggers the integrity mechanism’s handling. Current canonical MCP definition drift denies calls until operator re-approval.
Three integrity postures
Not every divergence deserves a hard block. You set the integrity posture per tool, matched to its risk:
Canonical MCP state | What happens | Operator check |
|---|---|---|
First tool sighting | The initial tool surface is adopted as a baseline | Review the tool and its declared access separately |
Unchanged tool surface | The pin remains stable | Current authorization is still required |
Changed name, description or argument schema | Drift is recorded and calls are denied | Inspect the changed tool surface |
Operator re-approval | The operator accepts the digest shown for review | Retry only after review; all other access checks still apply |
The attacks TIE catches
- Descriptor injection can change model-visible instructions in a tool description. Canonical MCP pinning includes the description, so a changed definition raises drift even when the argument schema stays the same.
- Typosquatting requires careful review of the tool and server identity. A differently named tool is not automatically proved malicious by comparing it with an unrelated pin.
- Re-described MCP tools can change the advertised task without changing their name. Review the description and schema together; the current canonical path denies a drifted definition until it is re-approved.
- Argument validation can reject inputs that violate a declared schema. A syntactically valid argument can still be harmful, so schema checks do not replace resource permissions, input validation or execution controls.
Why this is the heart of agentic security
Content checks, tool bindings, contract comparison and authorization inspect different evidence. Combine them according to the workflow rather than assuming contract comparison proves what remote code will do.
Paired with tool pinning and an AIBOM, the TIE turns supply-chain integrity from a nice idea into an enforced, audited property of the running system.
How DeepintShield approaches this
DeepIntShield’s current canonical MCP path compares approved and observed tool definitions and denies drifted tools pending review. It also revalidates Virtual Key bindings, Registry metadata, OpenFGA relationships, optional context policy and approval state. The older TIE and behavior-grant mechanisms are legacy capabilities, not extra stages of that canonical decision.
Frequently asked questions
What is a Tool Integrity Engine?
A Tool Integrity Engine compares recorded tool contracts and call attributes for divergence. Its conclusions are limited to the fields it sees; current canonical MCP definition pinning is a distinct mechanism.
How do prompt-injection tool hijacks work?
A changed description or schema can alter how an agent uses a familiar tool. Definition pinning helps detect that visible change; remote behavior can also change without a contract change, so other controls remain necessary.
How does tool integrity differ from an allowlist?
An allowlist checks tool names. A Tool Integrity Engine checks behavior – comparing a per-call fingerprint against the pinned contract fingerprint – so it catches attacks that corrupt an allowed tool rather than calling a forbidden one.
A simple example
A tool named customer_lookup can keep its name while changing its description or argument schema. A contract comparison makes that change visible before the name alone is treated as familiar. It cannot prove that unchanged remote code still behaves safely.
The diagram describes the general integrity pattern and legacy response postures. Current canonical MCP execution uses pinned name, description and argument schema; drift denies the tool until an operator re-approves the pending definition. The older Tool Integrity Engine is not an additional leg in that canonical decision.
