Instructions guide; permissions constrain
An agent may be told not to read sensitive records, install a dependency, access the public internet, or change a protected repository. That instruction alone does not make the action impossible. If the agent's tools and credentials permit it, the enterprise remains exposed to mistakes, misunderstandings, and misuse.
The SHAPE Framework therefore requires coding agents to operate in enterprise-approved execution environments with technically enforced permissions and boundaries. Security is part of the platform provided to the Product Engineer, not a collection of aspirational sentences in a Markdown file.
What the boundary covers
Relevant controls depend on the application and the organization, but may include which repositories an agent can read or write, which commands and tools it can run, whether it may reach external networks or services, what credentials it can obtain, which data environments it may access, and whether changes to protected shared resources are possible without additional authorization.
Least necessary access
Provide only the capabilities necessary for the authorized development task. A coding agent implementing a user interface should not automatically receive broad production-data access. A request for a new integration should not silently grant credentials or permission to alter shared infrastructure.
Separation of responsibilities
The Product Engineer directs work within the approved environment. Architects and enterprise platform/security owners establish or approve the boundaries appropriate to their responsibilities. An agent must not be able to bypass required governance simply by editing its own instruction files.
Review is still required
A secure execution boundary limits what an agent can do; it does not establish that generated code is correct. Code review, application security controls, independent verification, and UAT remain relevant. Conversely, a strong code review does not compensate for an execution environment that exposes sensitive data unnecessarily.
Match controls to risk
The framework does not prescribe one vendor, product, or universal sandbox configuration. Enterprises implement restrictions that match their applications, risk classifications, and established security policies. Stronger controls may be required for sensitive or regulated environments.