AI coding assistants are useful because they can do more than suggest code. Given access to a repository and development tools, they can inspect a problem, change files, run commands, and evaluate the result. That capability also creates a problem that is easy to underestimate: a capable worker may be able to take actions that the person assigning the task never intended to authorize. A sentence in a prompt is not the same thing as a technical restriction on what the worker can do.
This distinction became central to the development of Agent Operations, TENSA Engineering's supervised coding-execution system. Agent Operations is the engineering-execution foundation being developed within TENSA Driveline, the broader public project connecting software discovery and planning with controlled implementation. The systems did not begin as one integrated product, and the development history matters because the boundaries were refined through observed failures rather than chosen as abstract principles.
A coding assignment is not an open-ended mandate
A request to “improve authentication” sounds specific until a worker begins interpreting it. Does it permit replacing a dependency, changing a database schema, rewriting login flows, or modifying a deployment configuration? Those decisions may be technically related, but they are not necessarily authorized. An effective assignment therefore has to identify a desired outcome and the limits within which that outcome may be achieved. The worker needs a known starting revision, a defined set of allowed files or areas, an exact validation expectation, and instructions for stopping when the work depends on decisions outside its scope.
Agent Operations developed around approved task packets because this problem arises before a model executes a single command. The packet is more than a task description: it creates a record of what was approved. In the current manually supervised workflow, packet validation, workspace checks, and defined test commands help the operator compare actual work against that approval. The worker may discover that a broader change is desirable, but discovery does not grant permission. It must report the dependency for a separate decision rather than silently enlarging the task.
This also explains why planning and execution should be separate responsibilities. Argus Ventures is being developed for discovery, assessment, and preparation of approved implementation work. Agent Operations concerns the bounded execution and evaluation that follow. TENSA Driveline is the public identity for their intended connection, but that complete discovery-to-delivery integration remains in development. A well-written plan can prepare work for a coding agent; it should not become an excuse for the agent to redefine the product.
What the first permission experiments exposed
Early Agent Operations experiments found that coding workers could sometimes execute commands outside their task instructions. The finding was not that models invariably disregard instructions; it was that the distinction between “the model was told not to” and “the system prevented it” was material. Human review could spot a violation after the fact, but detecting it later is a different capability from denying it at the point of execution.
The managed-worker upgrade therefore began with small provider-behavior tests rather than a larger orchestration framework. Claude Code, Codex, and Grok were examined under narrow non-interactive conditions. The experiments asked whether an allowed action could execute, whether a denied action produced an observable tool event, and whether useful work could continue afterward. This is a tougher standard than accepting the model's written account of its own behavior.
In one set of Codex tests, the assistant described an attempted file write as denied. The execution record, however, did not contain an actual write attempt. The target remained unchanged, but that result could not prove the claimed permission behavior. A separate, experimental Codex interface did demonstrate an approval request followed by a decline and continuation. The two results were useful precisely because they were classified differently: one denial remained unproven, while the other demonstrated a particular approval flow under the tested configuration.
A small Claude Code experiment supplied narrower but stronger evidence. The assignment involved correcting a percentage calculation in a disposable test fixture. Recorded events showed authorized reads, one actual denied command, continuation after that denial, a focused code edit, and a passing prescribed test. The change itself was ordinary. Its importance was that the observable tool activity matched the intended boundaries for that run. It proved a useful provider behavior in a specific configuration; it did not prove universal permission enforcement or operating-system containment.
The workspace also defines the boundary
A coding model may be told to change only a few files, but the operator still has to establish what was actually changed. Agent Operations uses Git task workspaces to preserve a starting point and keep candidate implementations separate for review. Its workspace checks compare the branch, base revision, and changed paths with the approved packet. Its artifact inventory extends beyond a conventional tracked-file diff, accounting for created and modified files that might otherwise be overlooked.
This became necessary when an early implementation produced an apparently empty normal Git diff even though new implementation files existed in the workspace. A reviewer relying exclusively on the diff could have concluded there was little or nothing to examine. The lesson was not to abandon Git; it was to recognize that a reviewable workspace requires a complete inventory of the candidate, including untracked artifacts, and evidence tying checks to the code that was actually tested.
Workspace separation must not be confused with security isolation. A Git worktree is useful for development identity, reproducibility, and change review, but it is not a sandbox for untrusted programs. A coding worker running build scripts or tests can execute code under the permissions of its environment. For unfamiliar client repositories, a different risk boundary is needed. Agent Operations has separately provisioned disposable virtual-machine infrastructure for that direction, with preliminary checks, but it is not represented as a fully qualified client-security boundary or a demonstrated paid-delivery environment.
The practical approach is proportional. A trusted, supervised fixture does not require every safeguard appropriate for hostile executable code. Conversely, access to unfamiliar code should not inherit the authority of a developer's main workstation simply because the task is being carried out by an AI model. The execution environment, access to credentials, permitted network paths, and destructive capabilities need to match the actual risk.
Keep the authority outside the model
The long-term architecture aims to put enforcement in deterministic software surrounding the worker. The model may reason about a file change, propose a correction, or explain why a dependency is necessary. It should not be able to grant itself permission to change the approved scope, alter infrastructure, accept its own output, or publish a release. Those decisions belong to controls and people outside the coding session.
The September 2026 reset also taught an important limit to this idea. Agent Operations had accumulated layers of process suited to a more adversarial threat model than its normal supervised work required. The extra controls were expensive to operate and difficult to justify. The project returned to an earlier validated foundation instead of preserving complexity for its own sake. Strong boundaries are valuable when they address a demonstrated risk; a bureaucracy of duplicated checks is not evidence of better security.
The current foundation can validate task packets, inspect workspaces, run specified checks, inventory artifacts, and preserve launch and process evidence. Workers are still launched and coordinated manually in that foundation. Selected headless permission behavior has been demonstrated, but a general managed-worker permission broker, unattended approval system, and complete security boundary have not been established. Those distinctions remain important when describing TENSA Driveline's maturity.
What this changes about AI-assisted engineering
The central lesson is that a coding agent's competence and its authority are two independent concerns. A model can identify a legitimate improvement and still lack permission to make it. It can report a denial that never occurred as a tool action. It can produce correct code in a workspace that does not provide adequate containment for untrusted inputs. Trustworthy engineering requires inspecting each of those claims separately.
A bounded task is therefore not merely a smaller prompt. It is an agreement about the candidate being built, the environment in which work may occur, and the evidence that will be used to judge the result. That makes the next stage possible: testing and reviewing what the worker actually produced rather than relying on its description of success.
Continue reading
The next article, Why Passing Tests Isn't Software Acceptance, examines what happened when Agent Operations coding experiments passed their test suites and still failed independent technical review. For the broader project context, see TENSA Driveline; for related concepts, see Controlled AI Systems and Safe Tool Interaction.
Category
Controlled AI SystemsProject overview
TENSA Driveline