The AI Operating Model in Practice - Enforce agent permissions before a tool runs - Part 1

Enforce agent permissions before a tool runs

An AI agent can ask an application to run tools, such as looking up an order or issuing a refund. A tool is a function the application exposes to the agent. The agent's request does not grant permission. Before that function runs, the application must check who is signed in, which order they can access and whether the exact action is approved.

This article shows where to place that check and why it must also live in the refund service. We use fictional customer accounts and a proposed refund to show what gets blocked, what is allowed and what the local tests actually prove.

The refund is proposed, not approved

In this fictional example, a refund assistant proposes USD 42.00 for Blue order B-104. Its signed-in user, Ana, belongs to Green. The application must deny the read and the refund. The model's reason for the request does not change who owns the order.

Check access before running either agent tool. Repeat the check in the business service so a direct caller cannot bypass it. The agent proposes an action. Application policy decides whether it can happen.

Green and Blue are fictional tenants, meaning separate customer accounts. The order IDs and amounts are sample values. The local checks below use fixed test data, not a live payment provider.

Give the agent one tool that reads orders and one that requests a refund. A tool is a function the agent asks the application to call. A read needs a check too: order details can expose private customer data.

Keep the caller outside the tool arguments

The application host gets the user and tenant from its trusted login context. The model can propose an order ID, amount and currency. It cannot choose the user's identity or tenant. Pass that identity into both tools outside the proposed arguments.

In the source, RefundAgent.Create captures a host-provided Caller when it creates the two functions. AIFunctionFactory.Create exposes read_order and refund_order to the agent. Their delegates pass the captured Caller to RefundService.

For the allowed example, Ana can read Green order G-217. Green policy marks it refundable. A reviewer has approved Ana's refund of USD 42.00 for that order. The approval applies to this action, not every refund on G-217.

If the caller requests B-104, the service queries the order store under Green. It also checks the tenant and allowed reader on the returned order. It gives the same denial when an order is absent or unavailable. This avoids revealing Blue's order through the read result.

Where the checks happen

The two checks have different jobs. Microsoft Agent Framework middleware can inspect a proposed function call before the function runs. RefundAgent.Create installs that callback with AsBuilder().Use(...). The callback checks reads or calls RefundService.AuthorizeRefundAsync for refunds.

The service is the authoritative boundary: it checks access again during a tool call and during any direct call. The middleware improves the agent path. It is not a replacement for authorization in the service.

The application owns the policy and the order records. The framework provides function invocation and the point where a callback can intercept it. The framework does not decide which tenant or refund Ana may access.

Approve one exact refund

The approval record names the tenant, actor, operation and order. It also stores the exact amount in minor units and the currency. A minor unit is the smallest currency unit used for the amount. In USD, 4200 cents means USD 42.00.

Approval has an expiry and a revocation flag. At the time of a refund request, RefundService.AuthorizeRefundAsync checks both. It also checks whether the current order policy still permits refunds. Approval from yesterday cannot override today's policy.

USD 45.00 does not match the approval for 4200 cents. EUR 42.00 does not match either. A different actor, tenant, order or operation also fails. Reading G-217 can still be allowed after its refund approval expires because reading and refunding have separate requirements.

The check uses an exact currency string comparison. The host and order system must agree on currency format before storing or comparing values. For this small sample, the fixed records use consistent values. Do not assume this comparison solves currency validation for a payment system.

Put the main rule in the service

RefundService.ReadOrderAsync loads an order within Caller.TenantId and checks its tenant and reader. It rejects missing and inaccessible orders the same way. A direct caller gets no special route around this check.

RefundService.AuthorizeRefundAsync starts by calling the read rule. It then loads the current approval for this tenant, actor and order. The service checks the order policy, exact approved arguments, expiry and revocation before any write attempt.

RefundService.RefundAsync calls AuthorizeRefundAsync again before it calls IRefundWriter.AttemptAsync. This keeps the service in charge even if a request never passes through the agent. The store and writer remain application services, not built-in Agent Framework authorization.

The call to the writer is an attempt, not evidence that money reached the customer. The test writer records local state. A live payment system needs its own way to confirm the business result.

1    public async Task AuthorizeRefundAsync(
2        Caller caller, RefundRequest request, CancellationToken cancellationToken = default)
3    {
4        Order order = await ReadOrderAsync(caller, request.OrderId, cancellationToken);
5        Approval? approval = await records.FindApprovalAsync(
6            caller.TenantId, caller.UserId, request.OrderId, cancellationToken);
7

8        if (!order.Refundable || request.MinorUnits <= 0 ||
9            approval is null || approval.TenantId != caller.TenantId ||
10            approval.ActorId != caller.UserId || approval.Operation != "refund" ||
11            approval.OrderId != request.OrderId || approval.MinorUnits != request.MinorUnits ||
12            approval.Currency != request.Currency || approval.Revoked ||
13            approval.ExpiresAt <= clock.GetUtcNow())
14        {
15            throw new UnauthorizedAccessException("Refund not permitted.");
16        }
17    }
18

19    /// <summary>Repeat the rule at the service boundary before a write attempt.</summary>
20    public async Task RefundAsync(
21        Caller caller, RefundRequest request, CancellationToken cancellationToken = default)
22    {
23        await AuthorizeRefundAsync(caller, request, cancellationToken);
24        await writer.AttemptAsync(caller, request, cancellationToken);
25    }

Stop the agent tool before it runs

The agent uses the pinned Microsoft.Agents.AI package in the .NET sample. ChatClientAgent has a reading tool and a writing tool. Its AsBuilder().Use(...) callback sees the proposed function name and arguments.

For read_order, the callback calls RefundService.ReadOrderAsync. For refund_order, it parses the amount and calls RefundService.AuthorizeRefundAsync. It rejects other function names. Only after a check passes does next(context, cancellationToken) allow the function to run.

The callback does not accept tenant or actor from tool arguments. Caller was captured when the application created the agent. The tool delegate still calls the service, so the rule runs again at the business boundary.

An early check and the later check may see different records if policy or approval changes between calls. The later service check must use current records. For strict control across a real payment write, the application also needs a durable plan for the gap between authorization and execution.

1        return agent.AsBuilder().Use(async (inner, context, next, cancellationToken) =>
2        {
3            string orderId = Required(context, "orderId");
4

5            if (context.Function.Name == "read_order")
6            {
7                await service.ReadOrderAsync(caller, orderId, cancellationToken);
8            }
9            else if (context.Function.Name == "refund_order")
10            {
11                string amount = Required(context, "minorUnits");
12

13                if (!long.TryParse(amount, NumberStyles.Integer, CultureInfo.InvariantCulture, out long minorUnits))
14                {
15                    throw new UnauthorizedAccessException("Invalid refund amount.");
16                }
17

18                RefundRequest request = new(orderId, minorUnits, Required(context, "currency"));
19                await service.AuthorizeRefundAsync(caller, request, cancellationToken);
20            }
21            else
22            {
23                throw new UnauthorizedAccessException("Unregistered tool.");
24            }
25

26            return await next(context, cancellationToken);
27        }).Build();

What the local checks establish

The local sample uses a scripted chat client, fixed fictional orders and approvals and a fake writer. A scripted chat client returns predetermined tool requests. It is useful for forcing a particular path but says nothing about what a live model will propose.

In the scripted fixture, 10 of 10 Release tests passed.

The allowed test checks that the fake writer records the intended local refund state. That control matters: a rule that blocks every call would pass only negative tests. Denied cases check no write attempt for missing approval, changed amount or currency, expiry and revocation.

Cross-tenant cases check reads as well as refund attempts. Direct calls to the service exercise its own rule without going through the agent. The tests inspect fake writer calls and local records, not settlement at a payment provider.

Run the following commands from the root of the sample with the .NET SDK. The tests use fixed data and need no provider credentials. The project keeps its Agent Framework dependency pinned in its central package versions. Run the complete test project in Release mode after restore and build.

$ dotnet restore tests/ContextWindow.AI.AgentPermissions.Tests/ContextWindow.AI.AgentPermissions.Tests.csproj
$ dotnet build tests/ContextWindow.AI.AgentPermissions.Tests/ContextWindow.AI.AgentPermissions.Tests.csproj --configuration Release --no-restore
$ dotnet test tests/ContextWindow.AI.AgentPermissions.Tests/ContextWindow.AI.AgentPermissions.Tests.csproj --configuration Release --no-build

A permission decision is not a refund result

Keep four records distinct: what the agent proposed, what the policy allowed, whether a write was attempted and whether the order and payment records show completion. A request ID can link them. A successful tool return does not settle a payment.

A timeout leaves the downstream result uncertain. Do not assume a new attempt is safe because the approval still exists. Preventing duplicate refunds needs a stable operation ID and retry controls at the writer and payment boundary. This sample tests authorization, not recovery from an unknown outcome.

A service that records a refund attempt should keep an uncertain result pending until business records resolve it. It should also record denials for audit without leaking another tenant's order details. An audit record lets an owner inspect a decision later. It is not permission for that decision.

Decide who can approve before adding tools

The product owner should say which refund requests need human approval and who may give it. The refund service owner should choose the expiry, revocation rule and storage for attempts. Give the agent an accountable owner who knows its tool list and can review denied calls.

LangChain's The Agentic Operating Model describes tool access checks, limited credentials, human review and execution records in sections 5 to 7. Those control areas help explain why a refund needs checks. The tenant and approval rules here belong to this application, not to that paper.

A label such as 'read only' cannot grant access to another tenant's order. Revisit access when the agent gets a new tool or a tool gains a new action. Keep credentials limited to the work the service needs.

Start with the order read check and the service's exact refund rule. Add the early function-call check so bad proposals stop sooner. Keep an allowed test beside every denial and inspect the local state. That is how the rule can block B-104 without blocking an approved refund for G-217.

Source

The complete sample is available at github.com/alex-janjic/ContextWindow.AI.Agentpermissions.