Background and motivation
ApprovalRequiredAIFunctions mean that a tool is either always requires approval or never does. However, most coding agents have a more fine grained permission than that. They allow the functions to be approved based on the arguments passed. For example, a "Read" tool might need permission for /etc/passwd but not for /tmp/x.
API Proposal
The goal is to use middleware for this purpose so that a permissioning system could be injected into a middleware to ensure backwards compatibility and allow the most flexibility.
In FunctionInvocationContext simply add two fields:
public bool ApprovalRequired { get; set; }
The ApprovalRequired would be set at the beginning of the function invocation to whether the target function is an ApprovalRequiredAIFunction.
public string ApprovalRequiredMessage { get; set; }
This allows a dynamic message to be sent to the client.
API Usage
An example of how the a policy could be injected to a middleware to affect the approval required dynamically with the new field.
public sealed class PolicyPermissionMiddleware
{
private readonly IToolPermissionPolicy _policy;
public PolicyPermissionMiddleware(IToolPermissionPolicy policy)
{
_policy = policy;
}
public async Task InvokeAsync(
FunctionInvocationContext context,
Func<FunctionInvocationContext, Task> next)
{
PermissionDecision decision = _policy.Evaluate(context);
if (decision.ApprovalRequired)
{
context.ApprovalRequired = true;
context.ApprovalRequiredMessage = decision.Message;
// Do not invoke the tool. The framework/client should surface
// the approval request and only continue if approval is granted.
return;
}
await next(context);
}
}
public sealed record PermissionDecision(
bool ApprovalRequired,
string? Message = null);
public interface IToolPermissionPolicy
{
PermissionDecision Evaluate(FunctionInvocationContext context);
}
Alternative Designs
No response
Risks
No response
Background and motivation
ApprovalRequiredAIFunctions mean that a tool is either always requires approval or never does. However, most coding agents have a more fine grained permission than that. They allow the functions to be approved based on the arguments passed. For example, a "Read" tool might need permission for
/etc/passwdbut not for/tmp/x.API Proposal
The goal is to use middleware for this purpose so that a permissioning system could be injected into a middleware to ensure backwards compatibility and allow the most flexibility.
In
FunctionInvocationContextsimply add two fields:public bool ApprovalRequired { get; set; }The ApprovalRequired would be set at the beginning of the function invocation to whether the target function is an
ApprovalRequiredAIFunction.public string ApprovalRequiredMessage { get; set; }This allows a dynamic message to be sent to the client.
API Usage
An example of how the a policy could be injected to a middleware to affect the approval required dynamically with the new field.
Alternative Designs
No response
Risks
No response