AI coding agents can inspect files, change code and run development tools. For enterprise use, the resources an agent can access and the actions it can perform matter just as much as the model it uses.
Even when starting with a small pilot, define the following five controls in advance. For each control, identify where it is enforced and how you will verify it—not just what the rule says.
1. Authorised project and repository access
Question: Who can use an agent on which project?
Permission to use an agent should not imply access to every repository in the organisation. Each session should be associated with a verified user identity and an explicitly authorised project context.
Assess project access separately from model access. Permission to read a repository does not automatically permit sending its contents to any model provider.
Initial check: Identify the pilot users and repositories explicitly. Verify that an attempt to start a session for an unauthorised project is rejected. Define how removing access affects active sessions.
2. An isolated execution environment
Question: Where is the access boundary for the agent and its child processes?
The agent should be restricted to the workspace authorised for its task. The developer’s personal files, other projects and host credentials should not automatically fall within that scope.
Consider filesystem and network access together. A process restricted to project files could still send their contents elsewhere if it has unrestricted network access. Child processes and development tools must also be considered within these boundaries.
Initial check: Attempt to access a file outside the workspace and connect to a destination that is not permitted. Verify that technical controls in the execution environment block these actions, rather than relying on model instructions.
3. Central, enforceable policies
Question: Which actions are permitted, require approval or are prohibited?
Define clear rules for file changes, command execution, package downloads, model selection and usage limits.
Mandatory organisation rules should not be weakened at project or repository level. Instructions supplied to an agent can guide its behaviour, but they do not replace security boundaries.
Define what happens when a policy cannot be applied. Missing configuration must not silently become unrestricted access.
Initial check: Select one permitted action, one requiring approval and one prohibited action. Verify that each is handled as expected and that the applicable policy version can be identified.
4. Meaningful human review
Question: What decision is the person making, and what information supports it?
Approval before execution and review of generated code are different controls. Permission to run a command is not confirmation that the resulting change is correct or secure.
Approval requests should clearly describe the action and its scope. Developers should also be able to inspect file changes, executed tests and anything that remains unverified.
Build a workflow that allows routine actions within clear boundaries and makes consequential decisions visible, rather than relying on constant, ambiguous approval prompts.
Initial check: Follow a change from start to finish. Verify that the developer can distinguish what they approved, which changes they reviewed and which tests actually ran.
5. Audit and operational visibility
Question: Why did an action happen—or why was it blocked?
It should be possible to connect the session, user, project, policy decision, approval and execution outcome. Model usage and cost information should be associated with this context where available.
This does not require centrally retaining all source code or conversations. Separate necessary metadata from content recording, and define access permissions, retention periods and sensitive-data redaction.
Requesting, approving and completing an action are distinct events. Audit records should preserve that distinction.
Initial check: Trace one permitted action and one blocked action through the records. Check that you can identify who acted, on which project and under which rule, without exposing secrets in the logs.
These controls should work together
Authorisation establishes scope. Isolation enforces its technical boundaries. Policies define permitted behaviour. Human review evaluates important decisions and outputs. Audit records allow you to examine what happened.
For each control in your pilot, assign an owner, a validation scenario and an expected outcome. Keep unresolved gaps visible and assess them before expanding the scope.
BatonX’s approach is to bring these controls together under a shared governance layer. The controls supported by the selected release and their enforcement should be verified during the pilot.