.NET: Feature Request: Built-in Security & Validation Middleware for AI Function Tools

[mokarchi]

Summary

The current Agent Framework provides a clean mechanism for defining and registering AIFunction tools using AIFunctionFactory.Create().
However, there is no built-in security or validation pipeline to intercept, inspect, or reject tool inputs before execution.

This creates real security risks when exposing tools that interact with:

• File systems
• HTTP requests
• SQL databases
• External services
• Any sensitive action the model may trigger

I am proposing a Tool Security Middleware Layer similar to middlewares in ASP.NET Core or OpenAI Function Call Interceptors.

Problem

When an LLM runs a tool, the input arguments are passed directly to the underlying .NET function without:

• Sanitization
• Validation
• Policy checks
• Security restrictions
• Usage auditing
• Role-based access

Therefore, if a user prompt successfully triggers a tool call, the agent may execute unsafe behavior, e.g.:
1. FileSystemTool
A user could attempt:
"Delete everything under C:\ or read system32 files"

2. HttpTool (SSRF)
"Call http://127.0.0.1:5000/admin/shutdown"

3. SQL Tool (SQL Injection)
"Run: SELECT * FROM Users; DROP TABLE Users"

4. Prompt Injection
If an LLM is manipulated into calling a tool unintentionally, the framework cannot block it.

Proposed Solution

Introduce a Tool Execution Middleware Pipeline:

• Similar to ASP.NET Core's middleware model
• Intercepts before tool execution
• Allows validating, modifying, or rejecting input
• Allows logging/auditing
• Allows policy-based access control

Proposed API
Validation Hook on AIFunctionFactory

AIFunctionFactory.Create(
    method: SqlTool.Query,
    validator: SqlValidator.ValidateQuery);

Where validator returns:

• null ⇒ valid
• string ⇒ error message

[stephentoub]

This is already possible. You can create a pipeline of AIFunctions, such as with DelegatingAIFunction:

class ValidateQueryFunction(AIFunction innerFunction) : DelegatingAIFunction(innerFunction)
{
    protected override ValueTask<object?> InvokeCoreAsync(AIFunctionArguments arguments, CancellationToken cancellationToken)
    {
        ... // do your validation work here
        return base.InvokeCoreAsync(arguments, cancellationToken);
    }
}
...
AIFunction f = AIFunctionFactory.Create(...);
f = new ValidateQueryFunction(f);

You can see that's how the function invocation middleware intercepts all function invocations as part of the agent pipeline:

agent-framework/dotnet/src/Microsoft.Agents.AI/AIAgentBuilderExtensions.cs

Lines 37 to 51 in 45dba6b

	public static AIAgentBuilder Use(this AIAgentBuilder builder, Func<AIAgent, FunctionInvocationContext, Func<FunctionInvocationContext, CancellationToken, ValueTask<object?>>, CancellationToken, ValueTask<object?>> callback)
	{
	_ = Throw.IfNull(builder);
	_ = Throw.IfNull(callback);
	return builder.Use((innerAgent, _) =>
	{
	// Function calling requires a ChatClientAgent inner agent.
	if (innerAgent.GetService<FunctionInvokingChatClient>() is null)
	{
	throw new InvalidOperationException($"The function invocation middleware can only be used with decorations of a {nameof(AIAgent)} that support usage of FunctionInvokingChatClient decorated chat clients.");
	}
	return new FunctionInvocationDelegatingAgent(innerAgent, callback);
	});
	}

[mokarchi]

@stephentoub Thanks for the clarification!
I understand that DelegatingAIFunction and the agent-level Use(...) pipeline make interception technically possible today.

However, my proposal is focused on developer experience and first-class API support, not just technical possibility.

My proposal is to elevate this from “possible via low-level extension points” to a supported, discoverable feature with a clean API and best practices.

[stephentoub]

What do you believe that looks like? I don't think having that in AIFunctionFactory.Create itself is desirable, for a variety of reasons, including that it means you need to know all of the extensions at the time of creation. I'm unclear what would you believe would make it more "first-class". Thanks.

[mokarchi]

I agree that tool validation should not live inside AIFunctionFactory.Create(...).

Something like:

builder.AddToolSecurity(options =>
{
    options.GlobalValidators.Add(new SqlInjectionValidator());
    options.GlobalValidators.Add(new FileSystemPathValidator());

    options.ApprovalMode = ApprovalMode.RequiredForSensitiveTools;
});