Introduction

I hope you have already found Auditing and Telemetry for the Agent Governance Toolkit - Getting Started with .NET Core. This article demonstrates how you can leverage the Agent Governance Toolkit practically.

This time, I'll take it a step further and combine the Microsoft Agent Framework Harness with AGT. The example is a file-access agent that operates on a local working directory.

As soon as you let an agent touch files, a familiar set of requirements shows up:

• Listing, reading, and searching files should be allowed
• Creating, deleting, and overwriting files should not be
• That decision shouldn't be left entirely to the agent's prompt
• Blocked tool calls need to show up in an audit log

This is exactly the kind of split where Harness answers "what can the agent do" and AGT answers "should this particular call be allowed."

The sample referenced throughout this post is here:

https://github.com/normalian/MyAGTSamples/tree/main/AGTPolicywithMAFApp03

Dividing responsibility between Harness and AGT

Let's start by separating the two components' jobs.

Harness is what shapes an agent's capabilities. In the sample, AsHarnessAgent() is given a FileSystemAgentFileStore, which exposes tools like file_access_ls, file_access_read, and file_access_grep to the agent.

But just because Harness exposes a tool doesn't mean every call to it should execute. Applying AGT's .WithGovernance() afterward inserts a governance check into the pipeline right before the agent actually invokes a tool.

In other words, it's not enough to tell the model "please don't delete anything" in the prompt — you can deny the delete tool at the execution layer even if the agent calls it.

A closer look at the Microsoft Agent Framework Harness

Before going further, it's worth understanding what Harness itself actually does.

Microsoft.Agents.AI.Harness isn't just a package that bolts on some file-operation tools. It's an extension that assembles, as a ready-made pipeline, the pieces that long-running, repeatedly-tool-calling agents tend to need.

A plain Agent Framework AIAgent already lets you configure tools, conversation history, the execution loop, and context management individually. But if every application has to reimplement the following on its own, the code gets complicated fast:

• The loop that executes function calls returned by the model and feeds results back
• Persisting conversation history that includes tool execution
• Compacting context that grows during long-running tasks
• Auxiliary capabilities like todos, file access, and sub-agents
• An approval flow before a tool actually executes

Harness wires these long-task building blocks together, taking you from an IChatClient all the way to an AIAgent.

What's assembled inside HarnessAgent

The reference material describes Harness's core as three layers:

Instead of wiring these together by hand, you call a single extension method:

Given an IChatClient, AsHarnessAgent() is the entry point for building a HarnessAgent designed for long-running tasks. In this sample, that call also takes a FileSystemAgentFileStore plus several additional options.

Microsoft.Agents.AI.Harness and the related AIContextProvider were experimental at the time this reference material was written. API shapes, tool names, and package versions may change, so check the official docs and release notes for the version you're using.

Compacting the context window

In a long-running agent, user instructions, model responses, function calls, and function results all accumulate in history. As that history approaches the model's context limit, there's no room left for new tool calls or results.

Harness computes an input budget from maxContextWindowTokens and maxOutputTokens:

AIAgent agent = chatClient.AsHarnessAgent( maxContextWindowTokens, maxOutputTokens, new HarnessAgentOptions { /* ... */ });

Conceptually, the input budget available for conversation history and tool results is whatever's left of the model's context limit after reserving room for the next response. As history grows, Harness's compaction mechanism compresses older history while trying to preserve what later reasoning still needs.

That removes a lot of the code you'd otherwise write to manually truncate messages or summarize old tool results yourself. That said, compaction isn't "preserve everything perfectly" — if there's state you can't afford to lose, it's worth saving it explicitly through structured mechanisms like todos or file-based memory.

Sample project layout

Here's the shape of the sample:

working is the file store the agent operates against. The project file copies both the policy and this directory into the build output:

Paths are built relative to AppContext.BaseDirectory at runtime, so the sample doesn't depend on the current working directory.

Environment and packages

The sample targets .NET 10. Main packages (versions as of when the sample was written):

Set the Azure OpenAI endpoint and sign in with the Azure CLI:

On Windows PowerShell:

Because the sample uses AzureCliCredential, there's no key to embed in the application.

Controlling file operations with policy

policies/default.yaml allows the read-oriented tools and denies the mutating ones:

Anything not explicitly denied is allowed in this sample

default_action: allow

rules:

• name: allow-file-access-read condition: "tool_name == 'file_access_read'" action: allow priority: 10

• name: allow-file-access-ls condition: "tool_name == 'file_access_ls'" action: allow priority: 10

• name: allow-file-access-grep condition: "tool_name == 'file_access_grep'" action: allow priority: 10

• name: deny-file-access-write condition: "tool_name == 'file_access_write'" action: deny priority: 100

• name: deny-file-access-replace condition: "tool_name == 'file_access_replace'" action: deny priority: 100

• name: deny-file-access-replace-lines condition: "tool_name == 'file_access_replace_lines'" action: deny priority: 100

• name: deny-file-access-delete condition: "tool_name == 'file_access_delete'" action: deny priority: 100

The important part here is the combination of default_action and priority.

Because this sample uses default_action: allow, any tool not covered by a rule is allowed by default. Mutating tools then get a higher-priority deny. Since ConflictStrategy.DenyOverrides is also configured, a deny wins whenever an allow and a deny conflict.

For a stricter whitelist approach, switch to default_action: deny and explicitly allow only the tools you need. In production, that's worth considering — a whitelist means a newly added tool (from a Harness version bump, for example) doesn't get executed by accident.

Note that tool_name is the function name Harness exposes. file_access_read and file_access_Read are different names, so the strings in your policy need to match the actual tool names exactly.

Wiring AGT into the Harness agent

The core of Program.cs:

var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT") ?? throw new InvalidOperationException( "AZURE_OPENAI_ENDPOINT is not set."); var deploymentName = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME") ?? "gpt-5-mini"; var workingDirectory = Path.Combine(AppContext.BaseDirectory, "working");

var kernel = new GovernanceKernel(new GovernanceOptions { PolicyPaths = [ Path.Combine(AppContext.BaseDirectory, "policies", "default.yaml") ], ConflictStrategy = ConflictResolutionStrategy.DenyOverrides, });

kernel.OnAllEvents(evt => { Console.WriteLine( $"[Governance] Type: {evt.Type}, " + $"Tool: {evt.PolicyName}, Agent: {evt.AgentId}"); });

AIAgent agent = new AzureOpenAIClient( new Uri(endpoint), new AzureCliCredential()) .GetChatClient(deploymentName) .AsIChatClient() .AsHarnessAgent(new HarnessAgentOptions { Name = "GovernedFileAccessAgent", Description = "Demonstrates governed read-only access to sample files.", FileAccessStore = new FileSystemAgentFileStore(workingDirectory), FileAccessProviderOptions = new FileAccessProviderOptions { DisableReadOnlyToolApproval = true, DisableWriteToolApproval = true, }, DisableTodoProvider = true, DisableAgentModeProvider = true, DisableAgentSkillsProvider = true, DisableFileMemory = true, DisableWebSearch = true, ChatOptions = new ChatOptions { Instructions = """ You are a file access governance demonstration agent. Use the file_access_* tools to inspect the sample files. Read operations are allowed. Write, delete, and replace operations are denied by governance. """, }, }) .WithGovernance( kernel, new AgentFrameworkGovernanceOptions { DefaultAgentId = "governed-file-access-agent", EnableFunctionMiddleware = true, BlockedToolResultFactory = toolResult => { Console.WriteLine( $"[BLOCKED by Governance] " + $"{toolResult.AuditEntry.PolicyName}: " + $"{toolResult.Reason}"); return $"Tool call blocked by governance policy: " + $"{toolResult.Reason}"; }, });

What AsHarnessAgent() provides

Configuring AsHarnessAgent() with a FileSystemAgentFileStore gives the agent access to the file-operation tools.

This sample turns off everything else Harness offers:

That's just to keep the demo focused on file access. In a real application, enable only the capabilities you need, and write a policy for each corresponding tool — the more capabilities you turn on, the more surface area your policy and audit log need to cover.

FileAccessProviderOptions vs. AGT

DisableReadOnlyToolApproval and DisableWriteToolApproval control Harness's own approval flow. Turning them off does not disable AGT's policy evaluation.

Harness answers "how is the tool exposed," AGT answers "should this call to it execute." An approval UI or human-in-the-loop check and a policy-enforced deny aren't alternatives to each other — they're two separate layers of defense you can combine.

.WithGovernance() is the boundary

This is the part that actually joins the two together:

With EnableFunctionMiddleware = true, AGT intercepts the agent's function calls. Even if the model's reasoning concludes "write this file," the policy is consulted before the tool actually runs — and if that's a deny, it doesn't run.

BlockedToolResultFactory lets the application control what gets returned to the agent on a deny — useful for surfacing a user-facing explanation or attaching an audit ID.

Two agent IDs, on purpose

The sample deliberately uses two different identifiers.

This is the Harness / Agent Framework side's agent name.

This is the identifier AGT uses for policy evaluation and audit events.

They don't need to match. In fact, keeping the framework-level display name separate from a stable governance/audit ID means you can rename the display name without losing continuity in your audit trail. If you're running multiple agents, it's worth deciding on a unique ID scheme up front that accounts for tenant and environment.

Running it

The sample walks through read, write, and delete in sequence:

Console.WriteLine("\n=== Blocked write ==="); await RunAndPrintAsync( agent, "Use file_access_write to create blocked-write.txt " + "with the text 'this write must be denied'.");

Console.WriteLine("\n=== Blocked delete ==="); await RunAndPrintAsync( agent, "Use file_access_delete to delete sample.txt. " + "This operation must be denied by governance.");

Run it with:

Expected results:

On a denial, BlockedToolResultFactory returns something like:

What matters isn't just that the agent gets an explanation — it's that the denied tool never actually executes. Even if a prompt injection or similar attack changes the agent's instructions mid-conversation, the write/delete boundary stays enforced at the execution layer as long as the policy is in place.

Using governance events for auditing

The sample writes every event to the console:

That's fine for local development, but in production you'd want to send these to Application Insights or OpenTelemetry. At minimum, it's worth capturing:

• Agent ID
• Tool name
• The policy that applied
• The allow/deny outcome
• The reason for denial
• A correlation ID for the originating request

Also design your logging so file contents and other sensitive arguments aren't written verbatim — separate what you need for auditing from data you shouldn't be persisting at all.

Choosing between default_action: allow and deny

The sample uses default_action: allow to keep the walkthrough simple: allow everything Harness's read/write/delete/replace tools expose, and deny only the dangerous ones explicitly.

In a real deployment, though, the two modes serve different purposes:

Deny-list approach

Broadly permissive, with specific dangerous operations explicitly blocked. Easy to adopt, but a newly introduced tool could end up allowed by default.

Allow-list approach

Every permitted tool has to be listed explicitly. More setup up front, but unknown tools fail safe.

If the agent is going to operate against production data, default_action: deny is the safer baseline — start from nothing allowed and grant read access (with path conditions) incrementally. Combine that with per-agent IDs, per-environment policies, rate limiting, and circuit breakers for a stronger boundary overall.

Why this combination is worth it

Pairing Harness with AGT gives you four main benefits:

1. Capability and permission are separated. You can change what's executable through YAML policy alone, without touching the Harness configuration.
2. Denial happens at the execution layer, not the prompt. Deny rules apply at the tool-call boundary regardless of how the agent's instructions or conversation history change.
3. Decisions are auditable. Which agent, which tool call, which rule it matched, and why it was denied — all available as events.
4. Approval flows and enforced policy can coexist. Use Harness's approval features for UX, and AGT as the safety boundary that can't be crossed.

None of this is specific to file access. The same pattern applies anywhere an agent is delegated a hard-to-reverse action — database writes, external API calls, closing a ticket, sending an email.

Summary

This sample built a read-only file-access agent through the following steps:

1. Expose file-operation tools through Harness's FileAccessProvider
2. Allow reads and deny write/delete/replace in AGT's YAML policy
3. Insert the policy check into tool calls via .WithGovernance() and function middleware
4. Use governance events and blocked-call results for auditing and user-facing feedback

Harness gives an agent capability; the Agent Governance Toolkit draws the boundary around that capability. Getting an AI agent closer to production isn't just about adding useful tools — it's equally about being able to control, from outside the agent's own code, when, by whom, and under what conditions each tool can actually run.

Sample code for this post:

https://github.com/normalian/MyAGTSamples/tree/main/AGTPolicywithMAFApp03

References

• Previous post — Putting a "gatekeeper" in front of an AI agent
• MyAGTSamples — AGTPolicywithMAFApp03
• Microsoft Agent Governance Toolkit
• Microsoft Agent Framework
• Tutorial 43 — .NET MAF Hook Integration

There are a lot of ways to build with AI right now: chat frontends, copilots, greenfield agent apps, orchestration frameworks. All of them have their place, and some customers are building entirely new applications this way. But across customer engagements, a consistent pattern has emerged: the most successful and most cost-effective AI projects are not rewrites. They are existing, deterministic, event-driven business workflows (queue processing, message handling, scheduled jobs) with AI added at exactly the one step that was never deterministic to begin with. This enables the parts that are battle hardened to remain as before, adding AI where non-deterministic smarts are needed. This creates a more robust application along with spending costs for tokens only where beneficial.

That pattern has a natural home in Azure Function and Serverless Agents runtime now support non-Http triggers.

This post walks through the pattern in three layers: the app you already have, what it takes to add AI processing onto it yourself, and what it looks like with Serverless Agents. Learn and try it here: Build serverless agents using Azure Functions | Microsoft Learn

The scenario: expense processing

Picture an expense approval pipeline. Expense and purchase-order requests arrive as messages on a queue: some as quick notes, some as forwarded emails, some as key-value text or JSON from intake tools. Most of the piping around the decision is deterministic and should stay that way: queueing, retries, policy storage, output queues, identity, and the audit trail. You do not want a language model reimplementing any of that.

But one step in the middle has always resisted automation: understanding the request, choosing the policy that governs it, and applying a natural-language rulebook. "Booked a $450 round-trip flight to Denver for the customer onsite next week. — Albert" Turning that into a structured decision (amount, currency, vendor, category, policy applied, destination queue, reason) is exactly the kind of fuzzy, judgment-shaped work that used to mean either a human in the loop or a brittle pile of regexes and keyword lists.

That one step is the AI part of the equation. Everything else stays as code.

Layer 1: the app you already have

If you're running message-based workloads on Azure Functions today, your expense processor looks something like this, using the standard Python v2 programming model with a queue trigger:

@app.queue_trigger(arg_name="msg", queue_name="expense-requests", connection="AzureWebJobsStorage") def process_expense(msg: func.QueueMessage): expense = json.loads(msg.get_body()) validate_expense(expense) if is_duplicate(expense): return decision = apply_expense_policy(expense) route_decision(decision) write_audit_record(expense, decision)

This is good architecture, and nothing in this post asks you to change it. You get scale-out per message, retries with a poison queue after repeated failures, and scale to zero between messages. On the Flex Consumption plan you pay for execution, not for idle. The queue itself is doing real architectural work: it buffers spikes, absorbs backpressure, and decouples producers from processing.

The limitation is only that process_expense can read only the schema for which it was written. Free text, email-shaped messages, and inconsistent key-value input require a parser before the deterministic policy code can use them, and selecting among category-specific policy documents means encoding more rules in code.

Layer 2: the do-it-yourself middle step

The obvious next move is to call a model from inside the function. The first version is deceptively short:

The problem isn't the first version. It's everything the first version turns into. Model SDK and auth wiring. Prompt templates living in Python strings. Retry and backoff logic for rate limits, on top of the queue's own retry semantics. Output parsing and re-prompting when the model returns almost-JSON. Then the requests start arriving: "can it look up the current policy documents?" (now you are building tool-calling), "can it run a calculation?" (now you need somewhere safe to execute generated code), "why did it say that?" (now you are building telemetry for model and tool activity). None of this is your expense pipeline. All of it becomes your code to own, patch, and secure.

This is the middle step where a lot of AI-in-the-workflow projects stall, not because the idea was wrong, but because the glue outgrew the feature.

Layer 3: the same trigger, with the Serverless Agents runtime

The Serverless Agents runtime, collapses that middle layer. An agent is a markdown file, with instructions in the body and the trigger in YAML front matter, and it runs on the same Azure Functions triggers you already use. Here is the complete agent from the expense processor sample, expense_processor.agent.md:

{ "expenseId": "EXP-1001", "vendor": "United Airlines", "category": "travel", "amount": 450.0, "currency": "USD", "policyApplied": "travel-policy.md", "decision": "approve", "routedTo": "expense-approved", "reason": "Travel expense of 450 USD is at or below the travel policy's 1,000 auto-approve threshold." }

Note what the front matter is: the same queue_trigger configuration you would pass to the Functions decorator: queue name, connection setting, and string data type. If you know Azure Functions triggers, you already know how to trigger an agent.

The entire function_app.py is bootstrap:

And app-wide defaults live in agents.config.yaml:

When a message lands on expense-requests, the runtime invokes the agent once for that one item. The trigger's data_type: string and the host's messageEncoding: "none" keep the raw text human-readable, while the runtime serializes the queue message body and metadata before adding them to the agent prompt. The agent's instructions do fuzzy work; the results show up in your Function App logs and Application Insights like any other execution.

For the expense scenario, the pattern points directly at the intake queue: the agent extracts the amount, currency, vendor, category, and expense ID; calls list_expense_policies and get_expense_policy to choose and read the current policy from Blob Storage; applies the rules; and calls route_expense_decision to send the result to expense-approved, expense-review, or expense-flagged. Queueing, policy storage, identity, and routing stay deterministic; the agent gets responsibility for the part that needs judgment.

What changed between layer 2 and layer 3

The economics follow from the architecture. On Flex Consumption, the app scales to zero between messages, so you pay when expense requests arrive, and the AI spend is confined to the single step that needs a model, instead of being architected into every request the way a chat-first design tends to force. This is a large part of why the augment-don't-rewrite engagements are the cost-effective ones: the deterministic 90% of the workload keeps running at deterministic-workload prices.

Use all Event Driven triggers

Queue Trigger is one row in a much longer table. The runtime supports the breadth of the Functions trigger model in .agent.md front matter: Service Bus queues and topics, Event Hubs, Event Grid, Blob Storage, Cosmos DB, Azure SQL, Kafka, timers, Dapr bindings, and connector triggers, alongside HTTP

when you do want a chat endpoint. Wherever your events are already flowing, an agent can meet them there.

Try it

The sample deploys with the Azure Developer CLI:

Then send one of the bundled requests to the provisioned expense-requests queue and read the decision queues:

The travel request is a $450 flight. Swap samples/travel.txt for samples/client-dinner.txt or samples/equipment.txt to see the same amount, select a different policy and route differently. The sample's README also covers running locally with Azurite and Core Tools.

We are working on many more features to make it really easy for you to take your existing apps and make them intelligent, including Hybrid AI apps (your code + AI markdown binding), dynamic workflows and so on.