A coding agent can obey a repository's instructions most of the time and still carry more authority than its task needs. That is the gap Mozilla AI highlights in its argument for better agent infrastructure: written intent and technically enforced permission are different things. A more capable model may make better decisions, but it does not create the boundary that holds when a decision is wrong.
Mozilla's infrastructure argument concerns agents that inspect repositories, change files, run commands and tests, and prepare pull requests. Delegation compresses the developer's individual checkpoints into an observe–act–revise loop. The useful question is therefore not only how much work the model completes, but what the surrounding system prevents, records and can recover.
Instructions have a job; they are not the execution boundary
Three responsibilities need to remain distinct. Instructions describe desired behavior, the model interprets them, and infrastructure determines which actions are possible. Granting broad access and asking the model to restrain itself reverses that hierarchy: the worker becomes its own primary control system.
AGENTS.md solves a real coordination problem by keeping build commands, test requirements, conventions and security context beside the code. The format's site reported adoption by more than 60,000 open-source projects in the account. Shared, versioned instructions can travel across agent products; nested files can describe service-specific requirements inside a larger repository.
But the agent still has to find the relevant file, resolve overlapping rules, apply them to the task and retain them during a long run. Incomplete files, truncated context, conflicting nested instructions or an overgeneralized exception can weaken that chain. Markdown does not itself restrict a shell, network, cloud account, package registry or production database.
“Do not publish from a feature branch,” “seek approval before changing authentication” and “read only this directory” communicate intent. Filesystem boundaries, network rules and approval services must enforce the relevant limits. This does not diminish instructions: many software decisions require context no simple filesystem rule expresses. It assigns instructions and enforcement different roles.
Useful autonomy increases the consequences of an ordinary mistake
An integration-test repair can lead an agent to read environment files, launch services, install dependencies and regenerate snapshots. A vague task can expand beyond its intended scope. No malicious intent is necessary: destructive cleanup may be mistaken for routine maintenance, a credential treated as disposable, or issue and dependency text mistaken for trusted guidance.
Prompt injection sharpens that last problem by putting hostile instructions in data the agent was asked to process. Natural-language warnings help, but the model is still judging the trustworthiness of other language. An external boundary narrows what happens when that judgment fails.
The sandbox architecture referenced in the source separates a trusted harness from the environment running model-directed commands. Approvals, tracing, recovery and state can remain outside the execution container. The worker can then operate without automatically inheriting every credential and resource the organization possesses.
A documentation task does not need package-publishing keys; repairing one service does not require unrelated repositories; writing tests does not require production database authority. These are runtime capabilities—permitted actions and reachable resources—not merely prompt-writing choices. A laptop is not automatically safe because it is local: it may hold code, browser sessions, cloud credentials, personal documents and signing keys. One overpowered credential can matter without administrator access.
This makes control quality part of the product, not an invisible implementation detail. Platform and security teams must enable useful delegation without granting unlimited authority. Vendors and individual developers face the same identity, credential, approval, logging and recovery questions that model benchmarks do not answer.
Put policy and authorization outside the model's narration
A trusted control plane manages access, routing, budgets, policies and operational state. The model proposes an action; another layer decides whether and how it executes. Run-specific identities separate agents from the human operator and other automated work. Task-scoped access to named files, commands, services and network destinations should expire rather than accumulate across runs.
The source's sandbox security guidance describes isolation, restricted outbound traffic, separated credentials and brokered access. With a trusted proxy supplying credentials only for permitted destinations, execution can make an approved request without seeing a reusable secret. Generated code printing its environment need not expose a long-lived production key, and revocation can occur at the broker rather than in every workspace.
Tool mediation can validate arguments, reject dangerous paths, limit request rates and require approval. Mozilla's mcpd policy plugins place authentication, validation, rate limits and logging between agents and tool servers. Because Model Context Protocol can expose files, databases and external applications, an intermediary offers consistent enforcement without asking each agent to reproduce policy correctly.
An approval also needs an authorized identity and an external state the model cannot manufacture. If permission exists only as another contextual message, untrusted material can imitate it. Similarly, “save tokens” is advice; an enforced budget remains a ceiling when the loop runs too long. Multiple subagents can spend faster than a person watching one chat, making limits per task, team, provider or outcome relevant.
Not every step needs approval. Reading a repository and writing inside a temporary branch can be routine, while publishing, deploying, changing permissions or contacting customers may require explicit authorization. Context matters: a command allowed in an isolated test environment can be forbidden in production, and documentation traffic can be allowed while unknown destinations are blocked. Constant low-risk interruptions undermine delegation; no gates leave consequential decisions inside the model loop.
Audit and recovery must survive incomplete work
An agent's explanation is not a complete record of tool inputs, rights, file changes, retries or rejected requests. An audit system should independently bind each action to its run, policy version, tool version, approval state, identity, inputs and result. Three attempted prohibited operations before an allowed route tell a different story from immediately choosing the allowed route.
Those records matter when policies or credentials have changed after an incident. They also reveal recurring interventions, false-positive policies and tasks exceeding scope, helping teams improve permissions and workflows. A transcript or final output alone cannot reconstruct the authority held at execution time.
State management is equally important. A workflow can complete an external action and fail before recording success. Blindly retrying the entire job can duplicate a pull request, payment instruction or customer message. Infrastructure must distinguish completed steps, safe retries and operations needing reconciliation; an external side effect is not interchangeable with a repeatable local read.
Mozilla's Otari control plane connects governance with routing, budgets, access control, deployment and failover across providers. Routing can express privacy boundaries, latency requirements and capability choices, not only cost. Keeping those decisions outside scattered application code can preserve policy, traces and workflow state when models or deployment environments change.
Knowledge, policy, audit and recovery serve separate purposes: knowledge informs, policy constrains, audit records, and recovery handles incomplete work. The agent becomes a replaceable component in a system the organization controls, rather than the sole location of its institutional rules.
Open ownership also creates operating duties
An inspectable stack can reduce lock-in, support custom integrations and keep sensitive components in an organization's own environment. Hospitals, banks, public bodies and software teams may need different approvals and retention rules; one hosted default cannot meet every obligation. Openness is an ownership model, however, not automatic safety.
Self-hosting requires updates, access reviews, backups, monitoring and tested recovery. Old components, permissive defaults, shared credentials, incomplete logs and unrestricted networking remain vulnerabilities even when the source is public. Rich traces may expose proprietary code, personal data, prompts and tool results, so retention must establish responsibility without permanently copying every sensitive input.
More rules are not necessarily better. Overlapping exceptions create gaps, excessive restrictions push developers toward unauthorized tools, and opaque central policy creates its own governance problem. Small, testable controls need owners, reasons and verification. Policy changes need review, tests and versioning; emergency overrides should expire and remain visible, with explanations of rejected actions and exception handling.
Infrastructure also cannot guarantee useful code. An agent can stay within its permissions and still implement the wrong behavior or omit a requirement. Tests and human review remain necessary, including private or independently maintained cases that expose optimization for visible checks and code-ownership review for sensitive changes. A detailed incident log proves what happened, not that prevention worked.
Mozilla's thesis will be tested by temporary task-scoped permissions, durable evidence of actions and authority, and portability that preserves both through model changes. Everyday friction matters alongside those safeguards. Better reasoning remains valuable; dependable delegation requires boundaries that do not disappear when that reasoning fails.
Related reading: technical-document knowledge bases and retained engineering context.