Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: LLM applications that call external tools expand capability, but they also enlarge the attack surface through SSRF, prompt injection, excessive delegation, and credential leakage, according to Flatt Security. The practical lesson is that tool design, context separation, and least privilege must be treated as core security architecture, not post-launch hardening.
NHIMG editorial — based on content published by Flatt Security: Securing LLM Function-Calling: Risks & Mitigations for AI Agents
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when LLMs can call external tools without strict boundaries?
A: The main failure is that the model can convert untrusted text into real action.
Q: Why do tool credentials increase risk in LLM applications?
A: Tool credentials turn model suggestions into authorised operations.
Q: How can security teams tell whether an LLM tool integration is too permissive?
A: A tool integration is too permissive when a mistake or injected instruction could reach unrelated repositories, hidden data, or admin-level actions.
Practitioner guidance
- Separate tool credentials from the LLM context Keep API keys, PATs, and service tokens in trusted application logic rather than passing them through prompts or retrieval flows.
- Constrain each tool to one narrow job Prefer task-specific tools such as a pull-request creator over generic browser or admin interfaces.
- Treat retrieved content as untrusted input Isolate fetched web pages, repository text, and document content from instruction channels, and do not let them silently influence tool selection or credential use.
What's in the full article
Flatt Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Concrete request-flow examples for URL fetching and Git hosting integrations, showing where trust boundaries are crossed.
- Specific countermeasure patterns for SSRF, prompt injection, and indirect prompt injection in tool-calling designs.
- Design guidance for separating credentials from prompts and keeping secrets out of the context window.
- Examples of fine-grained versus overly broad token scopes for Git-based workflows.
👉 Read Flatt Security's analysis of LLM function-calling risks and mitigations →
LLM function-calling risks: are your tool boundaries strong enough?
Explore further
14/09/2026 10:11 am
Function-calling security is really NHI governance in disguise: once an LLM can act through a tool identity, the question is no longer whether the model is fluent, but whether the delegated credential is bounded. The article shows that the security problem sits in the interface between model output and external action, where tokens, APIs, and context boundaries determine what the system can do. That means identity governance, not model quality, becomes the durable control plane for AI-enabled workflows.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations separate browsing, retrieval, and action tools in LLM systems?
A: Yes. Retrieval tools, browsing tools, and action tools should have different trust levels because they do not carry the same risk. Keeping them separate limits how far untrusted content can travel and prevents a read-only task from becoming an unintended write operation through the same identity.
👉 Read our full editorial: LLM function-calling security needs least privilege and boundary separation
