Govern coding agents by making the authorized development workflow testable: identify who and what can act, configure policy at available control points, verify behavior on bounded operations, and give operators evidence they can use. A rollout is ready to expand only when its owner can identify which paths were evaluated, what each control actually did, and who handles exceptions or missing evidence.
The coding agent governance pillar defines the requirements for delegated development work. This guide turns those requirements into a pilot with explicit acceptance criteria. It uses a hypothetical test design throughout, not a completed experiment or a KonaSense integration recipe.
Inventory the coding-agent surface
Choose one team, a disposable test repository, and a narrow task: generate a documentation note from synthetic source files and submit it to a simulated receiver running locally. The proposed receiver would only record tagged fixture notes locally, with no external publication or business action. No real credentials or sensitive repository content are needed for this design.
List how the team could perform that task. Inspect the enabled editor tools, terminal agent, and any remote execution path separately. For each path, record the implementation and version, where it runs, how it is configured, the operations it exposes, and the person responsible for its installation. Include tools reached indirectly, such as a build request that starts work under another identity.
Choose which paths the pilot will exercise. If an editor integration is included but a remote runner is only known to exist, label the runner as outside the pilot. If its permissions or observations are unavailable, record that uncertainty too. An inventory entry is not proof of monitoring or control; an unlisted surface is not evidence that no one uses it.
The output of this step is a bounded inventory that the team lead and platform owner can reconcile against the actual configuration. Resolve differences before using it as the denominator for a coverage claim.
Identify users, environments, and accountable owners
Associate the human requester, agent session, and execution identity for each selected path. Use test identities where the pilot needs authenticated behavior. Record which repository revision, workspace, runner configuration, and local receiver belong to the case. Avoid identifying an environment only by a reusable display name.
Assign decisions to people who can act on them. The development lead owns the permitted task and whether the workflow remains useful. The platform owner controls the executor and environment restrictions. Security Engineering owns policy expectations and validation evidence. A designated reviewer owns approval decisions, and the SOC lead owns the receiving queue and triage procedure. One person may hold several roles; no required decision should lack an owner.
Give these owners a concrete stop condition. For example, if the pilot reaches a resource excluded by policy, the platform owner should be able to pause the affected test path while Security Engineering investigates. Agree who can authorize that pause and how the team will verify it. A contact name without an available action is an incomplete operational handoff.
Establish the permissions the task actually receives
For each executor, inspect file access, mounted resources, available programs, network destinations, and credential mechanisms. Compare those permissions with the synthetic documentation task. Its need to read fixture source and write a note does not justify access to an unrelated repository, release credential, or external publishing destination.
Use the environment's own configuration and appropriate read-only inspection to establish effective permissions. A prompt that says “use only this directory” documents an instruction; it does not establish a process restriction. Resolve any mismatch by narrowing the environment or explicitly changing the pilot's approved scope before proceeding.
Record configuration references alongside the permitted operation. If a script, tool server, identity, or runner changes, the previous result may no longer describe the path being tested. This record gives the platform owner a way to identify which validation needs to be repeated, without rebuilding the entire pilot after every unrelated edit.
Observe prompts and sessions where technically possible
Determine which session signals the selected implementation can provide. A task request, session start, prompt reference, and completion message may come from different mechanisms or may be unavailable. Test the available observations with the synthetic task before describing them as part of the pilot's visibility.
Choose what the pilot needs to retain. A reference to the fixed fixture input may establish the test context without storing every prompt or source file. If full synthetic content is necessary to debug a case, give that capture an explicit purpose, access policy, and retention period. Do not let a successful fixture exercise silently authorize collecting equivalent content from real developer sessions.
The evidence owner should be able to distinguish an observed session, an unsupported signal, a collection failure, and a path that was not assessed. An empty activity view cannot resolve those states. Keep the missing observation attached to its surface and owner so it remains actionable.
Track tool requests through the selected execution path
Before testing a policy, make the benign path observable. For the local receiver design, attach a unique case and attempt identifier to the synthetic note. Arrange observations at the proposed tool request, the executor's dispatch point, and the receiver. Establish which source records each event and whether its record describes a request, a dispatch, or a receipt.
Exercise an allowed fixture case to check that the observation path can capture the identifiers and the receiver's local result. If those records cannot be joined reliably, fix the pilot instrumentation before drawing conclusions from a denied case.
Document any transformation between the request and dispatch, including changed arguments or a remote executor. The architecture guide provides the component model for this mapping. The pilot needs the actual path for its installed tools, not a diagram assumed to represent every IDE or runner.
Define policy in terms the pilot can evaluate
Write policy expectations before running the cases. In this hypothetical design, the receiver has three fixture destinations: a draft area permitted for the task, a review area requiring designated approval, and an excluded area that must not receive the note through the controlled path. All three remain harmless local fixtures. They stand in for different authorization conditions without exercising a real sensitive operation.
For each rule, name the acting identity, operation, destination, and evidence of task scope it depends on. Separate routine permission from an exception. The developer should be able to complete the approved draft workflow without a new manual decision for every edit; a request to use the review area should make the additional condition explicit.
Write down what happens when required context or the evaluator is unavailable. The organization might require the affected request to remain held, or accept a bounded period of observation with continued execution. Those are different policies. If the installed mechanism cannot implement the required behavior, change the mechanism, reduce the pilot's scope, or record an approved limitation. Do not label continued execution as a demonstrated block.
Keep the case definitions, fixture inputs, configuration, and evaluation method together. NIST AI RMF Playbook MEASURE 2.1 calls for documenting test sets, metrics, and the tools used in testing, evaluation, validation, and verification. That record helps another reviewer repeat the evaluation and understand the limits of its result. NIST MEASURE 2.1.
Validate pre-execution controls where they are supported
Identify the point that can prevent the selected request from being dispatched. Confirm how the installed host receives and applies its response. A policy entry in an administration interface does not establish that the editor, terminal agent, or remote worker consults it.
Use the following as a validation plan for the synthetic receiver. It contains expected behavior and evidence to seek, not measured outcomes. Choose the failure policy before testing it.
| Case | Expected behavior in the pilot | Evidence needed to assess it |
|---|---|---|
| Permitted draft destination | The authorized request may be dispatched | Matched request, decision, dispatch, and receiver result |
| Excluded fixture destination | The controlled path stops before dispatch | Applied denial, executor observation, and complete receiver observation for that attempt |
| Approval required, none granted | The request remains pending | Pending state and no dispatch for the pending request |
| Evaluator unavailable | The preselected failure policy applies | Simulated failure, actual executor behavior, and any resulting receiver activity |
| Known path outside the control | Its behavior is assessed separately | Path identity and receiver observation; no inference that the selected control governed it |
For a denied case, verify the observer as well as the decision. Use a fresh attempt identifier, establish that collection is active, and define when that attempt has finished or can no longer dispatch. Account for queues, retries, and delayed records before closing the observation window. Combine the executor's evidence that dispatch was prevented with the receiver's complete observation for that bounded case.
No receipt, by itself, is only silence. If the observer stopped, correlation is missing, or the request may still be queued, mark the result unknown. Even a well-instrumented case establishes a conclusion about that path and observation window, not the absence of any effect elsewhere in the environment.
For evaluator failure, use a local stub or a supported test mechanism in the disposable environment. Do not disrupt a shared service to simulate the condition. For the path outside the control, use a declared benign test route; its purpose is to reveal the coverage boundary, not demonstrate an exploit.
OWASP's authorization guidance recommends testing authorization logic and verifying behavior under failures. Its emphasis supports checking both normal and abnormal conditions, while a small pilot still leaves untested behavior. OWASP Authorization Cheat Sheet. Keep the more detailed decision and failure contracts in runtime AI governance as a reference when interpreting discrepancies.
Make approval a testable operating step
Use the review fixture to test the handoff to an authorized person. The reviewer should see the proposed operation, destination, relevant content reference, acting identity, and reason it exceeds the routine draft permission. An agent's statement that approval was granted is not a substitute for the approval mechanism's record.
Start with no approval and confirm the pending behavior. Then plan separate cases for rejection and an applicable approval. Before a held request proceeds, verify that the approval still applies to its identity, target, arguments, and conditions. Changing the fixture destination should not silently reuse the decision for the earlier request.
Define what happens when the reviewer is unavailable. The work can remain pending or move through an explicitly authorized exception process; waiting is not itself an approval. In the pilot, keep these outcomes local and benign. Higher-impact production operations need their own risk assessment and authorization rather than being used as convenient test cases.
Record evidence that a reviewer can reconcile
For each case, preserve the expected behavior separately from what was observed. Link the approved task and configuration to the attempt, decision, applied response, and receiver observation. If the case diverges from expectation, record the discrepancy and its owner instead of converting the expected result into a passed status.
OWASP's logging guidance emphasizes purposeful event attributes, interaction correlation, exclusion of sensitive values, and verification of the logging mechanism itself. Use that guidance to make the record interpretable without collecting unrestricted content. OWASP Logging Cheat Sheet.
For this pilot, the reviewer needs the fixture destination and note reference, not a real credential or developer's private source file. Preserve the original meaning of each status when combining records. An evaluator's Allow is not the receiver's success, and a receipt does not establish that a requested external business action occurred. The simulated receiver has no such business action to report.
Ask a reviewer who did not configure the case to reconstruct it from the record. Can they identify which installed path was tested, what was expected, what actually happened, and what remains unresolved? If answering requires the implementer's memory, improve the evidence package before expanding the rollout.
Hand the evidence to SOC and SIEM operations
Agree on the operational event contract with the SOC team before adding an alert. For the pilot, the event should identify the case or task, execution path, relevant identity, policy decision, observed result, and unresolved evidence. Decide where it will be delivered, who can access it, and how the analyst reaches the underlying record. The transport and integration must be selected and verified for the actual systems involved.
Send a synthetic event through that approved test route and compare the source record with what the receiving system displays. Confirm that normalization preserves distinctions such as denied, pending, evaluation unavailable, and result unknown. Receipt in a SIEM proves delivery to that receiving path; it does not prove enforcement by the agent host.
Give the receiving team separate responses for different findings. A routine denied fixture case can be retained as validation evidence. An unexpected receiver result requires the control owner to investigate. A missing observation needs the telemetry owner. If an operational incident warrants containment, identify the authorized action and how its effect will be confirmed; delivery of an alert is not containment.
Also plan for an interrupted evidence feed. The SOC lead and platform owner should agree how to recognize missing expected test events, identify the affected paths, and decide whether those paths may continue under the approved operating policy. A quiet dashboard should not be the only indication that collection stopped.
Before adding another team or executor, have the owners review the completed case records, unresolved gaps, developer impact, and triage readiness. State exactly which configuration and workflow they are accepting. A new tool, runner identity, or destination requires assessing the changed conditions; the first team's results do not establish enterprise-wide coverage.
Assess the KonaSense integration within this pilot
The reviewed Claude Code PreToolUse adapter for Kona for Agents provides a specific path to evaluate a proposed tool operation and construct a denial, user-approval request, or updated arguments. Evaluation errors fall back to Allow. The installed host's handling of that response must be verified separately.
That path can be an object of the pilot's assessment. It does not establish the hypothetical receiver, a SOC/SIEM connector, process isolation, or control of every subprocess and remote runner. Select validation cases that match the integration and its actual failure behavior, and keep unverified paths visible in the rollout decision.