A model integration pattern where the application embeds tool definitions in the request sent to the LLM and executes the chosen function itself. It is simple to implement, but the same process often carries the credentials and permissions for every exposed action.
Expanded Definition
Function calling is an agent and application integration pattern where the model receives a declared set of tools, selects an action, and returns a structured request for the host application to execute. In NHI security, the critical distinction is that the LLM does not perform the action itself; the surrounding application does, using whatever credentials, entitlements, and guardrails have been wired into that execution path.
Definitions vary across vendors on whether function calling is a model capability, an orchestration pattern, or a tool-use interface. NHI Management Group treats it as a governance boundary issue: the model can only choose among exposed functions, but the application still determines what each function can reach. That makes the quality of tool scoping, secret handling, and authorization checks as important as prompt design. The pattern is adjacent to NIST Cybersecurity Framework 2.0 concerns around access control and secure architecture, and it should be evaluated with the same rigor as any privileged integration. The most common misapplication is exposing high-risk actions through a single broad service account, which occurs when every tool inherits the same backend permissions.
Examples and Use Cases
Implementing function calling rigorously often introduces orchestration overhead, requiring organisations to weigh developer speed against tighter authorization design and more complex auditability.
- Customer support assistant: the model can look up ticket status, but the backend action should only read the requested record and never inherit write access to the full support database.
- Infrastructure assistant: a tool may restart a service, but execution should be separated from deployment and secret retrieval functions so one prompt cannot chain into broader control.
- Finance workflow assistant: the model can draft payment instructions, while a second system enforces approval logic before any transaction API is called.
- Incident response agent: the LLM can query logs and open containment tasks, but access to quarantine or credential reset functions should be narrowly scoped and time bound.
- NHI governance review: teams map each exposed function to the underlying service account, then verify whether the same identity can also reach secrets, admin consoles, or unrelated APIs.
For implementation patterns that emphasize identity-bound tool access, the Ultimate Guide to NHIs is useful context, especially when paired with NIST Cybersecurity Framework 2.0 guidance on least privilege and secure system design. In practice, function calling works best when each tool has a sharply bounded purpose and cannot silently inherit broader operator powers.
Why It Matters in NHI Security
Function calling matters because it turns model output into a privileged execution path. If the exposed tools are over-scoped, a harmless prompt can become an access pathway to secrets, APIs, infrastructure, or data the model should never control directly. This is why function calling is not just an LLM feature; it is an NHI governance problem that intersects with credential lifecycle, role design, and audit trails.
NHI Management Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which underscores how quickly tool abuse becomes real when backend identities are over-privileged. The same logic applies to function calling: the blast radius is defined less by the model and more by the service account behind the tools. Practitioners should treat each callable function as a distinct trust boundary, with logging, approval gates, and secret isolation aligned to business risk. Organisations typically encounter the security impact only after an agent triggers an unintended action, at which point function calling becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Function calling can enable unsafe tool use when agent actions are overexposed. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Over-scoped tool identities create NHI privilege exposure and abuse paths. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions for function execution should follow least-privilege principles. |
| NIST Zero Trust (SP 800-207) | SC-2 | Function calls should be treated as verified transactions across trust boundaries. |
| NIST AI RMF | AI risk management covers unsafe tool invocation, governance, and monitoring. |
Define controls for tool use, logging, oversight, and human review of high-risk actions.
