An agent is authorized to create new GitHub repositories for project scaffolding. The security team is concerned the agent might create repositories with public visibility, potentially exposing proprietary code. Which control most reliably prevents the agent from creating public repositories, regardless of the parameters it generates?
Select an answer to reveal the explanation.
Short Explanation
You can't rely on the agent's own instructions or a later cleanup step. Put the guardrail in GitHub itself: default new repositories to private and disable visibility changes, so the organization policy wins no matter what the agent asks for.
Full Explanation
GitHub organization policies create platform-level constraints that override individual API calls and user or application permissions. Setting 'Default repository visibility' to 'Private' at the organization level means that even if the agent's API call to create a repository specifies 'visibility: public', the organization's policy overrides the request and the repository is created as private. Additionally, disabling 'Repository visibility change' prevents the agent, or any other actor without appropriate permissions, from later changing a private repository to public. This provides two layers of protection: the creation default forces private visibility, and the visibility-change policy prevents post-creation exposure. This is the correct approach because it is a platform-enforced technical control that operates independently of the agent's behavior. The agent cannot override an organization policy through its API calls, prompt parameters, or any other mechanism. The system-prompt approach is incorrect because system prompts are not technical controls; they are instructions to the language model. A prompt injection attack or a sufficiently strong instruction in the task context can override the system prompt's instructions, so telling the agent to 'always create private repos' provides no guarantee if the model decides otherwise. The create-then-fix approach is incorrect because it creates a window of exposure: between the creation step, where the repository is public, and the visibility-change step, where it becomes private, the repository exists as public. During that window, it could be discovered by search engines, bots, or other automated systems, and any code committed in that window is exposed. The weekly-review approach is incorrect because it is a detective control, not a preventive control. A public repository created Monday morning remains public until the following week's review, which is a potentially catastrophic exposure window for proprietary code.