Pairing the Agent Framework Harness with the Agent Governance Toolkit

A new sample from Microsoft's .NET agent ecosystem demonstrates how to pair the Agent Framework Harness with the Agent Governance Toolkit (AGT) so that an AI agent's file operations are policed at execution time rather than left to prompt instructions.

The sample, published in the MyAGTSamples repository, builds a file-access agent that operates on a local working directory. The agent can list, read, and search files — but cannot create, overwrite, or delete them. That read-only boundary is enforced by a YAML policy file, not by telling the model to behave.

The two components have distinct jobs. The Agent Framework Harness bundles capabilities: in this case, a FileSystemAgentFileStore that exposes tools like file_access_read, file_access_ls, and file_access_write. AGT's governance kernel then evaluates each tool call against a policy before the tool runs. The connection point is the .WithGovernance() extension method with EnableFunctionMiddleware set to true, which intercepts function calls in the agent's execution pipeline.

Enforcement happens at the tool-call boundary, after the model has decided to call a tool but before the tool executes. If a deny rule matches, the tool never runs. The sample demonstrates this by instructing the agent to write and delete files; both operations are blocked. The author notes the boundary also holds under prompt injection: if an attacker changes the agent's instructions mid-conversation, the write/delete restriction stays intact as long as the policy is loaded.

Harness itself handles the plumbing that long-running, tool-calling agents need — the function-call loop, conversation history persistence, and context compaction against a token budget. In the sample, most other Harness features (todos, web search, file memory) are disabled to keep the demo focused.

The policy file uses a default_action: allow baseline with explicit deny rules for the mutating tools (file_access_write, file_access_replace, file_access_replace_lines, file_access_delete), with deny rules at higher priority and ConflictStrategy.DenyOverrides configured. The author suggests a stricter whitelist — default_action: deny — for production, since a newly introduced tool from a Harness version bump would then fail closed rather than execute by accident.

Every governance decision is emitted as an event; the sample logs these to the console, with Application Insights or OpenTelemetry suggested for production, along with a warning not to log file contents verbatim. The sample also keeps two identifiers separate: the Harness agent name and the AGT audit ID, so renaming the display name doesn't break audit continuity.

Caveats apply: Harness and its companion components were experimental when the sample was written, so API shapes and tool names may change. The sample targets .NET 10 and uses Azure OpenAI with Azure CLI credentials.

The author claims the pattern generalizes beyond file access to any hard-to-reverse agent action — database writes, external API calls, sending email — though the sample itself only demonstrates the file case.