Our security team will not allow cloud AI agents to scan entire proprietary repositories or run with unrestricted access on developer machines, but the productivity benefits are becoming difficult to ignore. We are testing a compromise: map the repository locally, send only explicitly selected functions, signatures, or snippets to the model, and require manual approval before any changes are written to disk. What approaches are working in practice—enterprise plans with zero-retention agreements, local models, sandboxed agents, proxy layers, or local context-mapping tools?
4 Answers
The strongest pattern seems to be treating the agent as an untrusted CI job rather than as a developer’s trusted shell. Run it in an ephemeral container with an unprivileged user, mount only the repository or task-specific paths, avoid home-directory and secret mounts, use short-lived credentials, and restrict outbound traffic to approved model and package endpoints. Give it a dedicated identity instead of the developer’s SSH keys, cloud credentials, or kubeconfig. This limits the blast radius even if the agent ignores instructions or discovers more context than intended.
For code that cannot leave the network at all, a self-hosted model and an existing code-review workflow are the safest route. One workable setup is to have an issue trigger an isolated bot job, let the bot work in a temporary checkout, and have it open a normal pull request for review. That preserves traceability and existing approval processes. Local models may not match the best hosted models, and if they are too weak people may bypass them, so it is worth measuring capability and watching for shadow usage. For less sensitive repositories, a governed enterprise service behind a proxy may offer a better productivity tradeoff.
Local repository mapping is a good middle layer for highly sensitive projects. Treat context assembly as a security boundary: select only the required files, signatures, AST nodes, or snippets before constructing the prompt. That prevents accidental inclusion of neighboring repositories, environment files, internal schemas, or huge amounts of unrelated code. The agent can then generate a patch, while a human or automated policy check reviews changes before they are applied.
We combine the mapper with a sandbox. The mapper controls what reaches the model, while the sandbox prevents the agent from reading the host environment or using inherited credentials. Both controls are needed.
Enterprise SaaS can be reasonable for ordinary proprietary work, but only after reviewing the actual enterprise terms, data-processing agreement, retention settings, training policy, and audit controls. Consumer plans may have materially different terms. Zero-retention is important, but it only addresses the provider’s storage; internal prompt tracing, telemetry, shared logs, and debugging buckets can still leak full prompts. Those systems need their own redaction and retention controls.
We found that our own tracing pipeline was logging complete prompts even though the model provider had a zero-retention agreement. Fixing internal telemetry was just as important as negotiating the vendor contract.
Exactly. Prompt filtering is useful, but it is not a substitute for limiting what the process can physically read or execute. We also record request hashes and byte counts so we can audit what left the environment without storing sensitive prompt bodies.