Published

October 15, 2026

How to Govern Coding Agents as Adoption Expands

Aadhil Majeed

Developer Relations Advocate

Table of Contents

Key Takeaways

Coding agent adoption raises concerns about code quality, review capacity, codebase comprehension, sensitive data exposure, accountability, and cost.
Reviewing the final output alone is insufficient. Organizations also need to record agent actions, model and tool calls, and validation results.
Fiddler brings trace-records, evaluations, guardrails, and usage metrics together to support governance.
Evaluators can check instruction adherence, unsupported claims, test tampering, susceptibility to prompt injection, code quality, unproductive loops, and sensitive information using trace-records.
Introduce governance as coding agents are adopted. Capture agent activity, establish a baseline for usage and performance, and validate evaluators. Use the results to define and test controls before expanding access.

Coding agents can inspect repositories, edit files, run tests and shell commands, create documentation, and interact with connected systems. This lets them handle a wider range of tasks that goes beyond completing code. For business and security stakeholders, this also changes what needs to be monitored, reviewed, and governed as adoption expands.

Evaluating the final output is no longer enough to determine whether an agent completed a task correctly and safely. Let’s look at some of the concerns organizations share as they adopt coding agents.

Code quality and maintainability: In LeadDev's 2026 survey of 600 engineering leaders, maintainability was the most frequently selected concern about AI coding tools and agents at 73%, followed by output quality at 71%. Even when an agent’s code meets the immediate requirements, it can be harder to understand, test, and maintain [1].
Review and testing capacity: As agents generate code faster, teams have more code to review and test before it is ready to ship. In GitLab’s survey of 1,528 developers and technology buyers, 85% said AI had shifted the bottleneck from writing code to reviewing and validating it [2].
Codebase comprehension: Engineers need to understand how an agent’s code fits into the wider system to review it and troubleshoot problems. In Augment’s survey of 219 engineering leaders, most of whom were already adopting AI, 55% named codebase comprehension as a top concern [3, pp. 4 and 12].
Sensitive data and agent permissions: Organizations need to control which information agents can access and which actions they can take. Sonar found that 61% of developers at large enterprises were highly concerned about exposure of company or customer data [4, p. 30]. In Okta's broader enterprise-agent survey, data leakage and excessive privileges were the highest-ranked security concerns [5].
Governance and accountability: GitLab found that 80% of respondents said their organizations adopted AI tools faster than they developed policies to govern them [2].
Cost and return on investment: Organizations need to understand what agents cost, including reviewing their work, managing permissions, and governing their use, and whether they deliver enough value. In GitKraken’s survey of 554 developers and engineering leaders, 39% had no way to measure AI’s impact [6].

Some of these studies cover both AI assistants and coding agents, and they highlight a need for visibility and control. Organizations need to see what agents do, which models and tools they use, the result they produce and the steps they took along the way. This helps teams investigate problems and assess whether agents follow established policies. Runtime guardrails help enforce those policies by checking content sent to and returned by models and tools. Together, observability, evaluation, and guardrails help organizations manage risk and spending as they adopt coding agents.

How Fiddler Addresses Coding Agent Governance

The Fiddler AI Control Plane supports coding agent governance through the following capabilities.

Capturing Coding Agent Activity and Model Traffic: Fiddler captures coding agent telemetry from both the agent harness and LLM gateway. The harness records conversations and tool use, including file edits, shell commands, and other actions that do not pass through a gateway. LLM gateways capture model calls and interaction with other agents and systems.
Monitor and Evaluate Agent Activity: Once agent activity and mode traffic is captured they can be evaluated for quality, safety, and policy adherence, with control over which prompts, responses, and tool data are retained for offline evaluation [7]. Evaluator rules map attributes to checks that are tailored to organization specific requirements. Continuously evaluating coding agents helps track behavior as models, instructions, and tools change.
Enforce Policy During Execution: Fiddler Guardrails checks content during execution and returns allow, block, or redact decisions for the gateway or application to enforce, without storing the submitted content. In a self-hosted deployment, guardrails run within the organization’s infrastructure, so the information processed by these checks does not leave the corporate boundary.
Bring These Capabilities Together for Governance: Consolidating agent activity, evaluation results, and guardrail policy decisions, along with usage and spending metrics, into a centralized view helps organizations review agent behavior, investigate problems, and support audit and accountability. The capabilities also help turn what they learn about agent behavior into a new set of policies and controls.

In the next section, we will look at how to put these capabilities into practice as adoption grows.

A Phased Approach to Coding Agent Governance

Coding agent governance should be rolled out in tandem as the agents are adopted. Start with a pilot to obtain visibility into agent activity and establish an operational baseline. Then evaluate agent behavior against organizational requirements and use the findings to shape policies, guardrails, and review processes. Test and refine these controls before expanding agent access and usage.

1. Establish Visibility into Agent Activity

As mentioned above, coding agent telemetry can be obtained from the agent harness and LLM gateway. In addition, agent-side plugins can capture activity that may not pass through a gateway or are not exposed through native harness traces. Fiddler’s Claude Code plugin is one such example. It uses lifecycle hooks and the local session transcript to export OpenTelemetry traces. Each trace connects the operations associated with a user turn, while individual spans record model calls and tool executions, along with other information, such as permission denials and interrupted turns. A shared conversation identifier groups turns from the same session, and parent relationships connect a subagent’s activity to the tool call that launched it. This gives reviewers a connected view of model and agent activity that gateway or native harness telemetry alone may not provide.

The table below summarizes the records the Claude Code plugin can export and how teams can use them to review agent activity.

Captured activity	Available records	How teams can use them
Requests and responses	Submitted prompt, final response, and reconstructed messages for model calls	Compare the request with the agent’s reported outcome
Model calls and usage	Reported model, finish reason, and input, output, cache read, and cache creation token counts	Track model use and token consumption across calls and turns
Tool calls and results	Tool name, call ID, arguments, results, reported duration, and error or interruption status	Review commands, file targets, check results, and connected tool activity
Permissions and interruptions	Permission mode, executed or rejected attempts, unresolved outcomes, available denial reasons, and estimated waits	Review allowed and denied attempts.
Delegated work	Available subagent IDs and links between captured activity and the launching tool call	Follow work delegated to subagents.
Timing and execution context	Reconstructed timestamps, reported tool durations, estimated permission waits, working directory, and available agent and plugin versions	Follow the approximate sequence and identify the workspace and runtime.
Identity and organization	Available user, account, and organization IDs, plus optional configured names and emails	Attribute activity where identity is available.

Once the traces are exported, it is important to check that they contain the fields and attributes your evaluators require. Missing or inconsistent data can lead to charts and reports that misrepresent agent behavior.

Fiddle’s trace view explorer helps confirm that expected model and tool activity appears under the correct turn and that the fields required for investigation and evaluation are present.

Fiddler trace detail view of a Claude Code session showing nested agent, LLM, and tool spans with durations, alongside span metadata, the captured user prompt input, the agent output, and evaluator scores.

2. Establish an Operational Baseline

After confirming that traces capture the expected activity, establish an operational baseline for the pilot by tracking and trending metrics such as:

Total traffic
Model and tool calls
Token usage
Cache hits
Cost
Latency
Error rates

When attribution is available, break these metrics down by team or use-case. These metrics show how coding agents are being used. We will look at evaluating agent behavior in the next step.

The example dashboard below brings several of these measures together. It shows total traffic and token volume alongside trends in daily traffic, input and output tokens, cache utilization, and time to first token. These measures can show how expanding adoption affects demand, model usage, cache utilization, and cost.

Fiddler Claude Code coding agent analytics dashboard showing total traffic, input token count, and cached tokens, with charts for daily traffic, input versus output token usage, cache hit rate, average and P95 time to first token, and cache read versus cache creation tokens.

In addition to standard metrics, organizations also need to ask questions specific to their workflows. A query language lets teams filter captured activity, group related records, and calculate metrics using conditions they define.

Fiddler supports this through Fiddler Query Language (FQL), which can aggregate trace attributes and apply conditional logic to create custom metrics. Custom metrics can be displayed alongside standard measures in the dashboard. It is also possible to zoom in on a data point to examine the underlying traces and understand which sessions are contributing to a specific trend.

3. Configure Evaluators for Organizational Requirements

Operational metrics show how coding agents are being used, but they do not determine whether an agent behaved as expected. LLM-as-a-judge evaluators can analyze agent activity to assess behavior that requires contextual interpretation.

The image below shows the anatomy of an LLM-as-a-judge evaluator. The evaluator converts coding-agent activity into a structured classification. It takes the user request and final response as input, applies a rubric and asks an LLM-judge to select a label classifying the type of work. The output includes the classification label, an assessment status, and a short rationale supporting the LLM’s judgment.

Diagram of an LLM-as-a-judge evaluator in four stages: untrusted inputs (user request and final answer), a rubric prompt template with system prompt, evidence status rules, and user prompt, an LLM judge that classifies the work, and a structured judgment output with a work type label, evidence status, and evidence citation.

Evaluator results are meaningful only when the evaluator reflects the organization’s policies and has been validated against relevant, human-reviewed examples. Teams should examine disagreements, false positives, and false negatives while allowing an “unknown” result when the available input is insufficient. Re-validate the evaluator whenever its prompt, model, input mapping, or governing policies change. Otherwise, dashboards may amplify its errors.

4. Review Agent Behavior and Evaluation Results

Once evaluators are configured and validated, they can be applied across sessions to review how agents behave in practice. This could include checks such as:

Did agents access sensitive files
Exposed confidential information in prompts or tool results
Attempted actions beyond their permissions, or
Made changes without appropriate validation

Reviewing these patterns alongside usage and cost helps teams assess the broader impact of coding-agent adoption. These findings show where existing controls are sufficient and where stronger review, policy enforcement, or runtime guardrails are needed before the rollout expands.

The table below provides some additional evaluator examples that may be useful depending on what an organization needs to evaluate and monitor.

Evaluator	Question	What it checks
Instruction adherence	Did the agent follow the user’s instructions?	Recorded actions against explicit constraints on scope, tools, and files. Flags deviations such as editing a forbidden file or pushing code when only a local fix was requested.
Claims versus facts	Does the final summary match what happened?	Claims about tests, code properties, or measurements against recorded results. Flags overstated or contradicted claims, such as reporting that all tests passed when the output shows failures.
Test tampering	Did the agent weaken tests to get them passing?	Test diffs alongside the request and code changes. Distinguishes legitimate fixes from weakened assertions, skipped tests, or deleted tests that hide a problem.
Susceptibility to prompt injection	Did the agent follow instructions embedded in the content it read?	Potentially malicious instructions in files, pages, or tool results against subsequent actions. Distinguishes encountering an injection from carrying it out.
Code quality	How maintainable is the final code?	Final source files against a rubric for readability, structure, duplication, and complexity. Identifies the lowest-scoring file for closer review.
Thrash	Did the agent get stuck in unproductive loops?	Tool calls, edits, and results for repeated failing checks, rewrites, or retries without progress. Distinguishes useful iteration from attempts that do not address the underlying problem.
Sensitive information exposure	Was sensitive information included in model or tool content?	Captured prompts, responses, and tool arguments or results for credentials, personal information, or confidential data. Assesses whether their inclusion was permitted by the organization’s data-handling policy.

The example below shows evaluator results alongside an agent’s trace. In this example, the evaluators classify the task as complex, identify a test edit as a legitimate fix, and flag repeated failing checks and file edits as thrash. Each result includes reasoning to help reviewers assess the findings.

Fiddler trace detail of a coding agent session with evaluator results for task complexity (complex), test tampering (legitimate fix), and thrash (severe), each with its reasoning.

Evaluation results can also be aggregated across agent sessions and displayed in dashboards to reveal patterns over time. As another example, the dashboard below summarizes shell-command activity over the last 30 days. The left chart groups commands by action type, including read-only operations, local or remote writes, and destructive filesystem actions. The right chart classifies the same activity by risk level, from low to critical. These views show the overall command mix and highlight higher-risk activity that may require investigation.

Two Fiddler dashboard charts of coding agent shell commands over the last 30 days, one grouped by command category such as read-only, local write, remote write, and destructive filesystem actions, and one grouped by risk level from low to critical.

This video walkthrough demonstrates how custom evaluators can classify shell-command categories and risk levels [8].

5. Introduce Policies and Guardrails

Findings from the steps above can help teams turn recurring issues into policies and controls. Fiddler Guardrails can check prompts, responses, and tool results for exposed credentials, personal information, prompt injection attempts, or prohibited content. It returns an allow, block, or redact decision for the gateway or application to enforce. Other requirements, such as model selection, approval before pushing code, or restrictions on force pushes, need controls in the gateway, coding agent, or repository. Teams should test these controls across the rollout to confirm what they enforce and identify gaps.

This video walkthrough demonstrates how to configure inline guardrails with Fiddler Guardrails and the LiteLLM gateway to redact sensitive data in real time before it leaves the organization’s corporate boundary [9].

6. Expand With Review Checkpoints

Finally, organizations can expand coding-agent use across teams and repositories based on evaluation results and operational experience. Start with limited permissions and outputs that engineers can review, then allow agents to push code, update dependencies, change infrastructure, or deploy software as the controls prove effective.

Each rollout should define repository access, permitted tools and commands, required approvals, and the activity captured for review. Re-check affected evaluations and controls when models, tools, instructions, or permissions change.

Putting Coding-Agent Governance Into Practice

Coding-agent governance starts with capturing agent activity, evaluating results, and enforcing policies through guardrails and access controls. Together, these measures help teams assess code quality and review effort, preserve engineers’ understanding of the codebase, protect sensitive data, establish accountability, and track costs as adoption expands.

Organizations can begin with a focused workflow, validate their telemetry and evaluators, and refine policies as coding agents take on more responsibility. This creates a repeatable process for expanding access while maintaining appropriate oversight.

Ready to build a governed coding-agent rollout? Request a demo to see how Fiddler can help.

References

[1] LeadDev, “The Engineering Leadership Report 2026.” [Online]. Available: https://zporigin.leaddev.com/the-engineering-leadership-report-2026

[2] GitLab, “GitLab research reveals organizations are generating AI code faster than they can control it,” June 23, 2026. [Online]. Available: https://about.gitlab.com/press/releases/2026-06-23-gitlab-research-reveals-organizations-are-generating-ai-code-faster-than-they-can-control-it/

[3] Augment Code, “State of AI-Native Engineering 2026.” [Online]. Available: https://www.augmentcode.com/downloads/state-of-ai-native-engineering-2026.pdf

[4] Sonar, “State of Code Developer Survey Report.” [Online]. Available: https://www.sonarsource.com/state-of-code-developer-survey-report.pdf

[5] Okta, “Enterprise buyer survey on AI agent security.” [Online]. Available: https://www.okta.com/en-sg/newsroom/articles/enterprise-buyer-survey-ai-agent-security/

[6] GitKraken, “Everyone feels faster. Almost nobody can prove it.” [Online]. Available: https://gitkraken.com/blog/everyone-feels-faster-almost-nobody-can-prove-it

[7] Anthropic, “Monitoring usage and costs.” Claude Code Documentation. [Online]. Available: https://code.claude.com/docs/en/monitoring-usage

[8] Fiddler AI, “Analyzing Coding Agent Behavior with Custom Evaluators,” YouTube video. [Online]. Available: https://www.youtube.com/watch?v=I4tGEWdSVa4

[9] Fiddler AI, “How to Prevent AI Agents from Leaking Sensitive Data with Fiddler Guardrails and LiteLLM,” YouTube video. [Online]. Available: https://www.youtube.com/watch?v=UkBgEthu9TA