What happens when function calling is enabled without strong authorization controls?

Why Unchecked Tool Access Becomes a Control-Breaker

function calling changes an AI system from a text generator into a system that can initiate actions. That makes authorization the boundary between harmless suggestion and real operational change. Without strong checks, the model may reach data, trigger workflows, or alter records in ways the user is not entitled to request. The security issue is therefore not the model alone, but the path from model output to executed side effect. For control design context, NIST’s control catalogue reinforces that access enforcement must be applied where actions are actually authorised, not only where they are requested from. NIST SP 800-53 Rev 5 Security and Privacy Controls In practice, many teams discover the gap only after a harmless-sounding prompt has already reached a callable action.

How Strong Authorization Changes the Behaviour of Function Calling

strong authorization turns function calling into a controlled execution layer rather than an open command surface. Each tool invocation should be evaluated against the caller’s identity, the model’s allowed role, the target object, and the specific action being requested. That means the system should not rely on a general “logged in” state or on the model’s interpretation of intent. A model may correctly infer that a function exists, but it cannot safely decide whether the caller is permitted to use it.

In practice, this requires separate checks for at least three questions: whether the user may invoke the function at all, whether the function is appropriate for that tenant or workflow, and whether the specific record or resource is in scope. A function that reads a customer profile is not automatically safe just because the user can access the application. The callable layer needs the same discipline as any other privileged interface, especially where the function can send messages, approve transactions, retrieve secrets, or change state.

• Function-level authorization decides whether a tool exists for that caller.
• Object-level authorization decides which record, account, or workflow can be touched.
• Action-level validation decides whether the requested side effect is allowed in the current context.

Where teams get this right, the model becomes a routing layer over pre-approved capability. Where they get it wrong, the AI becomes a convenient path for privilege bypass, because the strongest attacker input is often just a prompt that reaches an unguarded function boundary.

Where the Boundary Conditions Get Messy

Tighter authorization often increases implementation overhead, because every callable tool needs its own policy logic, ownership, and audit trail. That tradeoff is worth making, but it becomes more complex when functions are reused across multiple workflows or when one tool can touch many object types. In those cases, the question is not only “can this user call the function?” but also “under what context, for which record, and with what allowable effect?”

One common edge case is read versus write confusion. Teams sometimes assume read-only tools are low risk, but even a retrieval function can expose sensitive data, internal prompts, or operational metadata that should not be available to every user. Another edge case is delegated or composite actions, where a function triggers downstream systems that are outside the model team’s direct control. If those downstream actions are not separately authorised, the initial tool call becomes a trust bridge into broader privilege.

Guidance is clear on the need for enforcing access at the point of action, but consensus is still weaker on how much policy should sit in the application layer versus a central policy engine. The practical rule is to avoid any design where the model can infer permission from context alone. In high-risk workflows, that shortcut tends to fail first in edge cases, not in the obvious happy path.

Risk and Threat Considerations

The material risk is privilege misuse through an action-capable AI interface. If function calling is exposed without strong authorization, an attacker, malicious insider, or simply an over-permissioned user can turn a benign prompt into an action that changes data, launches workflows, or accesses protected resources.

Failure mechanism: The weakness appears when the application trusts model output or session presence instead of validating each tool call against function-level and object-level permission checks. That allows prompt injection, confused-deputy behaviour, or normal user misuse to reach a privileged action path that should have been blocked.

Impact: Sensitive data can be disclosed, records can be altered, transactions can be approved, and downstream systems can be triggered without proper approval. In shared or automated environments, the same flaw can scale into cross-tenant exposure or broad operational abuse.

Practitioner Guidance

What to prioritise: Treat every callable function as a privileged interface, not as a model feature. The first design question is which actions must require explicit user entitlement, separate object checks, or human approval before the model can invoke them.

What to verify: Confirm that authorization is evaluated at execution time, not inferred from the chat session, the prompt, or the user interface state. The control should fail closed if identity context, target object, or action scope is missing.

Common mistake: Teams often secure the front end and the prompt flow while leaving the tool endpoint too broad. That leaves the most dangerous path unguarded, because the model can still reach the action even when the user interface looks restricted.

Practitioner takeaway: The safest pattern is to make the model request actions and make policy decide whether those actions happen; once the model can directly cause side effects, authorization must be as strict as any other privileged API.

Related resources from NHI Mgmt Group

• What breaks when asynchronous agent workflows are built without strong state, authorization, and audit controls?
• What breaks when MCP integrations are enabled without strong access scoping and audit controls?
• What happens when an API is exposed to third party integrations without strong controls?
• What happens when organisations automate AI security controls without strong governance?