A coding agent does more than send questions to a model. It reads and changes files, runs terminal commands, executes tests and may connect to external tools. Model calls are only one part of that workflow.
A model gateway manages requests between the agent and the model provider. Controlling what the agent can do in its execution environment requires an additional layer of security and governance.
What does a model gateway manage?
Depending on the product and its configuration, a model gateway can:
- Route requests to permitted models and providers.
- Authenticate model access and centrally manage provider credentials.
- Enforce request, token and cost limits.
- Record latency, errors and model usage.
- Evaluate requests and responses passing through it against defined rules.
These are important controls for enterprise AI adoption. Their scope, however, is limited to traffic passing through the gateway and the integrations connected to it.
Why is local execution different?
A model may propose reading a file or running a command. The components that perform those actions are the agent’s local tools and execution environment.
Even when a gateway can inspect a tool call in a model response, that does not mean it controls the resulting operating-system action. A model proxy alone does not:
- Prevent the agent from reading files outside its authorised workspace.
- Determine the permissions under which terminal commands execute.
- Restrict the access of child processes.
- Govern network connections outside the model API path.
- Independently verify that local actions occurred and establish their results.
These controls must be enforced where the actions take place.
An example: “Review this project and run the tests”
During this task, the agent may read source files, check dependencies and execute test commands.
The gateway can check that a model request goes to an approved model and stays within configured usage limits.
Without separate execution controls, however, the same agent—or a process it starts—could attempt to read a file outside the project or connect to an external address, subject to its available permissions. Those operations do not have to pass through the model gateway.
Likewise, blocking new model requests does not automatically terminate a local process that is already running.
What does governing a complete session require?
Session governance brings together user and repository authorisation, filesystem isolation, command permissions, network restrictions and session termination.
Audit records should also connect model activity with relevant policy decisions, approvals and execution results reported by the runtime. This does not require recording all source code or sensitive content.
An agent’s native permission and sandbox features can contribute to this architecture. The enterprise requirement is to apply these controls consistently under centrally managed policies.
The BatonX approach
BatonX is being designed to bring model-access controls together with authorised repository access, isolated execution environments, command and network policies, and session auditing.
The aim is to preserve the developer’s familiar agent experience as much as possible while technically enforcing the organisation’s boundaries.