IntentKit agent executor lets owner-only tools run without the human-in-the-loop approval gate

Crestal Network (IntentKit project)·IntentKit (open-source AI agent framework, through v2.6.3)Unresolved

IntentKit's executor authorized incoming tool calls against the agent's full tool registry instead of the narrower, per-request tool list that ToolBindingMiddleware had advertised for that caller/channel, so a caller in the WEB, API, Twitter, or Telegram surface could invoke owner-only, state-changing tools (wallet transfer, posting, memory-write, call-agent) by naming the exact de-advertised tool, either via indirect prompt injection or by replaying checkpoint/thread history on a reused conversation.

Blast radius

Not disclosed: the advisory establishes that unauthenticated or public callers could trigger owner-restricted, state-changing actions such as wallet transfers and social posts with no approval step, but no confirmed exploitation, affected-deployment count, or financial loss is reported in the sources reviewed.

Root cause

Authorization was re-checked against the agent's complete tool registry at execution time rather than against the same caller-scoped, narrowed tool list enforced earlier by ToolBindingMiddleware, so tools hidden from a given request remained callable if named directly.

How it was caught

Reported by external researchers (Noy Pearl, Michael Sromin, Ophir Dror) via Lasso Security and assigned CVE-2026-76066 with VulnCheck as the CNA; there is no indication in the sources that IntentKit's own runtime caught the bypass before disclosure.

Take-awayEnforce tool-call authorization at the point of execution using the exact same per-request, per-channel allowlist that was used to advertise tools to the model — never fall back to validating against the full tool registry.