A Tool Integrity Engine (TIE) detects when a tool call diverges from the tool’s declared contract – comparing what a tool is doing right now against what it was approved to do, and flagging, queuing, or blocking the call when they don’t match.
It’s the control that catches the most common kind of production agentic attack: the one where the policy engine says “allowed” because the attacker changed the tool, not the policy.
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.
Agentic attacks rarely break the policy engine. They change what an allowed tool does, so an approved call turns harmful. Catching that means comparing behavior, not names.
How a Tool Integrity Engine works
The TIE works by fingerprinting behavior – both the declared contract and each live call – and comparing the two.
Step by step:
- At registration, the TIE computes a contract fingerprint – a hash of the tool’s name, declared action class, declared argument schema, and source. That captures “what this tool is supposed to be.”
- On every live call, the TIE computes a per-call behavior fingerprint from the real call – the observed action class, the shape of the arguments, the calling context.
- It compares the observed behavior against the pinned contract. Match, and the call proceeds. Diverge, and the tool’s integrity posture decides what happens.
Three integrity postures
Not every divergence deserves a hard block. You set the integrity posture per tool, matched to its risk:
Posture | On divergence | Use for |
Flag | Log the divergence and alert, but allow the call | Low-risk tools where you want visibility without disruption |
Approval | Pause the call and queue it for human review | Medium-risk tools where a human should confirm |
Block | Deny the call outright | High-risk tools where any divergence is unacceptable |
The attacks TIE catches
- Descriptor injection: a tool’s description is altered to slip in instructions that re-purpose it. The contract fingerprint changes, and the divergence trips before the call runs.
- Typosquatting: a malicious server registers tool names that look like legitimate ones. Comparing fingerprints against the pinned legitimate one exposes the impostor.
- Re-described MCP tools: a trusted tool’s action class quietly flips from ‘read’ to ‘execute’ between sessions. The TIE checks the observed action class against the pinned one on the very next call.
- Argument-shape divergence: a tool that normally takes a single query string suddenly gets structured arguments full of shell metacharacters or path-traversal patterns. The args-schema comparison catches it.
Why this is the heart of agentic security
Content guardrails inspect text. Allowlists check names. Neither sees the gap between what a tool claims to be and what it’s actually doing – which is exactly where prompt-injection tool hijacks live. The Tool Integrity Engine closes that gap, and it’s what separates real agentic security from a gateway with a permission list bolted on.
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.
🔗 Internal link: Primary CTA: /platform/agentic-security/ (Tool Integrity section). Link ‘tool pinning and an AIBOM’ to Post 3. Link ‘fingerprint’ concepts to Post 8. Link back to Post 1 (pillar) and Post 2 (ASI02, ASI04).
How DeepintShield approaches this
DeepintShield’s Tool Integrity Engine is behavior-based tool checking, done directly: it pins each tool’s contract as a cryptographic fingerprint and compares every call’s fingerprint against that pin, so a silently re-described, typosquatted, or tampered tool trips a drift signal – and can be flagged, queued for approval, or blocked. The drift signal also feeds ABAC policy, so a drifted tool automatically gets stricter handling. For teams whose agents call a growing set of tools and MCP servers, DeepintShield is one way to add the integrity layer name-based allowlists lack.
