Coding-agent governance: decisions before automation
Define owners, boundaries and evidence for agents that change software. Policy should guide the work rather than sit apart from it.
An agent can be capable of an action without that action belonging to its assignment. This distinction is the starting point for governance. The goal is not to approve every file read manually, but to define permitted effects, the environment in which they may occur and who is responsible.
The NIST AI Risk Management Framework provides a voluntary risk-management reference. OWASP describes excessive agency in relation to functions, permissions and autonomy. These references help frame questions; they do not automatically certify a team’s particular configuration.
Describe boundaries through effects
“AI may be used on this project” is too broad to guide an integration. Specify whether the agent may read code, edit a working copy, prepare a proposed change, publish an application or modify data. These actions have different consequences and do not need identical authorization.
Identify the environment as well. A test credential should not silently target production. Use understandable names, matching permissions and a way to verify the destination before acting. The responsible person should be able to identify the affected system without relying on the agent to interpret an ambiguous connection or account name.
Match tools to the policy
If the assignment is to check a delivery’s status, a read-only tool may suffice. Exposing a general administrative function unnecessarily expands the range of possible effects. Describe inputs, consequences and errors so the tool does not have to guess what an identifier or parameter means.
Consider a hypothetical agent investigating registration failures. It receives reduced logs and access to a validation environment. Changing customer permissions or deleting records does not belong to that investigation. If a correction requires either effect, the task should present the concrete operation and its reason before it is performed.
Assign responsibility for outcomes
Each automation needs an owner who reviews configuration changes, follows up failures and decides when to suspend the workflow. Responsibility does not disappear because the tool promises to review its own output. The record should identify who receives a problem and what information must be available to investigate it.
Keep the task identifier, environment, important actions, results and approval decisions. Avoid storing secrets in logs. The purpose is to reconstruct what happened, not indiscriminately collect everything the agent can access. Observability data also needs a defined purpose and access policy, including a clear understanding of who can inspect it.
Exercise failure before expanding use
Test an unavailable tool, an ambiguous response, an exceeded limit and a change rejected during review. Observe whether the agent stops appropriately, preserves valid work and communicates what remains. Automation that works only on the ideal path leaves the operation without an answer to foreseeable failures.
Repeat relevant cases after a model or connector changes. The distinction between prompt engineering and agent engineering explains why instructions are only one layer. The business adoption checklist organizes the move from trial to recurring use. Useful governance appears in decisions people and tools can actually follow during ordinary work, with ownership that remains clear when something goes wrong.
Review this record when access changes, not only when an incident forces an investigation.
About the author
Tiago F SantiagoComments
No comments yet
Share a question or an experience related to the article.
Related articles
