[et_pb_section fb_built=”1″ _builder_version=”4.16″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_row _builder_version=”4.16″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.16″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||” theme_builder_area=”post_content”][et_pb_text _builder_version=”4.27.8″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n
Before invoking a tool via MCP or performing several steps independently, an agent relies on a fundamental mechanism: the function calling<\/strong><\/em> . Function calling<\/em> allows an LLM to translate a natural-language request into a structured instruction (JSON format) that can be directly used by code or an API. In other words, the model no longer simply responds with text; it prepares the technical action and extracts the parameters. <\/p>\n <\/p>\n By evolving from a simple text generator to a system capable of triggering real-world actions (database queries, third-party APIs, business tools), the LLM moves to a whole new level. It is precisely this transition that introduces a new set of risks, at the very moment that language becomes structured data. <\/p>\n <\/p>\n <\/p>\n The technical principle has remained consistent since its widespread adoption in 2023: a model receives a description of one or more available functions, in the form of a schema that specifies their names, their purposes, and the expected type of each parameter. When faced with a user request, the model decides whether to invoke a function, which one, and with which arguments\u2014all extracted from the conversation. <\/p>\n <\/p>\n This JSON structure, validated against a schema, eliminated the unreliable parsing and errors of the early integrations. But while schema validation ensures the format is correct, it in no way guarantees the intent or security of the transmitted data. <\/p>\n <\/p>\n <\/p>\n This is the risk most specific to function calling, distinct from general prompt injection\u2014which has already been covered in the dedicated article\u2014although it shares the same underlying logic. When a model extracts a parameter from natural language (an amount, a date, an identifier) to match the expected schema, it performs a type coercion operation that can be exploited. <\/p>\n <\/p>\n A recent security research on function-calling agents<\/u><\/a> documents how this step can be bypassed: text containing an explicit type indication, written in natural language, can influence the value that the model extracts and passes to the target function, without any conventional safeguards detecting it, since the result remains, on the surface, a valid parameter in the expected format.<\/p>\n <\/p>\n The risk is exacerbated in multi-agent architectures, where the parameter extracted by a first agent directly feeds into a call made by a second agent. In this type of chain, each extraction point provides an additional opportunity for a corrupted value to slip through the cracks at an intermediate stage, before propagating all the way to the final call. <\/p>\n <\/p>\n <\/p>\n Function calling<\/em> in and of itself does not pose any intrinsic risk: a function that retrieves business hours or calculates a route does not expose any sensitive information, even in the event of a successful attack. The risk arises fromthe discrepancy<\/strong> between the functions exposed to the model and those actually necessary for its task<\/strong>: an email-sending function exposed to an assistant who is supposed to only view data, write access granted where read-only access would suffice, or a delete function made available without intermediate validation. <\/p>\n <\/p>\n In each of these cases, model manipulation via injection directly inherits this excess capacity, regardless of the robustness of the parameter extraction mechanism itself. Every<\/strong> function exposed to a model should be treated as an extension of its scope<\/strong> , with the same rigorous review as a new access granted to a service account.<\/p>\n <\/p>\n <\/p>\n [\/et_pb_text][et_pb_accordion _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_accordion_item title=”What Is Function Calling? ” open=”on” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n Function calling is the ability of an AI model to convert a natural language request into a structured instruction (e.g., JSON) that can be processed by an API.<\/p>\n [\/et_pb_accordion_item][et_pb_accordion_item title=”How can you verify that an AI agent does not have excessive privileges?” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content” open=”off”]<\/p>\n Start by taking inventory of the functions, APIs, technical accounts, and data accessible to each agent<\/b>. Remove unnecessary permissions, separate read and write access, and limit each permission to a specific resource, time frame, and environment. This approach applies the principle of least privilege to AI agents. <\/p>\n [\/et_pb_accordion_item][et_pb_accordion_item title=”Which function calls must be subject to human validation?” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content” open=”off”]<\/p>\n Require explicit confirmation before any data deletion, financial transaction, external communication, change in permissions, or production intervention. The confirmation request must specify the tool being used, the target, and the exact parameters to enable an informed decision. <\/p>\n [\/et_pb_accordion_item][et_pb_accordion_item title=”How can we document and audit these controls for our auditors, insurers, and regulators?” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content” open=”off”]<\/p>\n By maintaining structured records: function diagrams, catalogs organized by agent, call logs (function, parameters, result), model decisions (if available), and human validations. These elements help demonstrate compliance with the principles of least privilege, validation, and traceability required by compliance frameworks (GDPR, AI Act, security standards). <\/p>\n [\/et_pb_accordion_item][\/et_pb_accordion][et_pb_text _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n Our experts assess the actual scope of the functions available to your models and agents and test their resistance to manipulation as part of our <\/span>AI penetration testing<\/u><\/a>service.<\/p>\nHow Function Calling Works: From Natural Language to API Calls<\/h2>\n
Type Confusion and Prompt Injection: Vulnerabilities in Function Calling<\/h2>\n
AI Permissions Management: Preventing Excessive API Access<\/h2>\n
Best Practices for Securing Function Calls at the Source<\/h2>\n
\n
\n
FAQ: Security of Function Calling and AI Agents<\/h2>\n
Audit the functions exposed to your AI systems<\/h2>\n