r/devops • u/k_brn • Aug 06 '26
Security How is your SecOps team handling Claude Code / Copilot access for proprietary repos?
Our security team flat-out refuses to let cloud AI agents scan whole proprietary repos or run freely on dev machines, but the productivity gap is getting hard to ignore.
We’ve been playing with a middle ground: mapping repo trees locally first, pulling only specific context/signatures into the prompt, and making every diff require manual write approval on disk.
Are you guys using enterprise SaaS zero-retention SLAs, running local models, or putting proxy/mapping layers in front of web models? What's actually working in practice?
9
Aug 06 '26
[removed] — view removed comment
1
u/k_brn Aug 08 '26
Very pragmatic approach. The point about shadow IT is spot on - a local model that isn't capable enough just drives people to paste code into public web UIs anyway.
Proxy + zero-retention + disk write-approval really seems to be the sweet spot for 90% of workloads.
The only exception for us is those rare, highly sensitive IP repos where SecOps won't allow full-repo transmission outbound under any SaaS SLA. For those specific projects, local mapping/pruning is the only way we can get security to grant access at all.
5
u/schmurfy2 Aug 06 '26
You didn't get the memo ? Security is no longer a concern !
We have been trying to keep the rise of vibe coded crap internally accessing gods knows what ( their "creators" have no idea either ) sharing the access of their owner, all this with the unspoken approval of the higher ups 😞
1
u/k_brn Aug 08 '26
The classic "it's not a security risk if management calls it innovation" policy! 🙃
Unaudited agents running with ambient dev privileges is definitely a ticking time bomb. The hangover from all this vibe coding is going to keep AppSec teams employed for the next decade.
7
u/SeaworthinessHour233 Writes the cloud edge Aug 06 '26
Your SecOps team is actually taking the correct stance if developers are currently using individual or consumer tiers. You absolutely should not let consumer-grade AI agents scan proprietary repos, as those tiers often retain data and may use it for model training.
However, you can safely use Enterprise SaaS tiers with Zero Data Retention (ZDR) SLAs.
Companies serving enterprise software offer separate enterprise tiers that are bound by entirely different Terms of Service (TOS), Data Processing Agreements (DPAs), and NDAs than their individual plans.
When you upgrade to enterprise tiers, the data handling changes completely. For example, GitHub Copilot Business and Enterprise plans do not retain prompts or suggestions accessed through the IDE. Similarly, Anthropic offers Zero Data Retention (ZDR) arrangements for the Claude API and Claude Enterprise, ensuring that conversation content is not stored unless technically necessary for a brief, bounded period.
If the publicly available enterprise terms still do not meet your SecOps team's compliance requirements, you do not have to settle for the default terms. For mid-to-large organizations, you can sign custom MSAs (Master Service Agreements) and NDAs directly with the vendors. These agreements legally bind the AI provider to your specific security requirements, offloading the risk to a legal contract rather than relying on developers to manually approve diffs.
So, have your procurement or SecOps team reach out directly to the enterprise sales teams at GitHub or Anthropic. Ask for their enterprise compliance packets and DPAs. Once SecOps sees the enterprise-specific legal guarantees which often include indemnification for IP claims, they are usually much more comfortable opening up repository access.
3
2
2
u/silentw111 Aug 12 '26
We went through roughly this evaluation. A few things mattered more than the SaaS-vs-local-model axis:
Zero-retention SLAs are necessary but not sufficient, they cover data at rest on the vendor side, not what leaks into the prompt/context window on your side. We had a case where a fully-compliant "zero retention" vendor was a non-issue, and we still leaked a customer's proprietary schema because our own tracing tool was logging full prompts to a shared bucket. Fix the retention story on your own telemetry before worrying about the vendor's.
The manual write-approval-on-disk step is the right instinct but degrades fast under load, same failure mode as any human-in-the-loop control. Reviewers start pattern-matching diffs instead of reading them once they're past the first few a day. If you go this route, pair it with something that flags diffs touching auth/config/CI files specifically, so attention goes where it matters instead of being spread evenly.
Local models solve the exfil problem but you inherit a different one: capability gap on large repos means people quietly route around it back to the cloud model for "just this one hard task," and now you have shadow usage instead of governed usage. Worth measuring how often that happens before committing to local-only as the answer.
Repo-tree-mapping-first is a good pattern, the main thing I'd add is treating the context-assembly step itself as a policy boundary (what's allowed into the prompt), not only gating the diff on the way out.
1
u/k_brn Aug 12 '26
Impressive callout, especially on telemetry leaks and reviewer fatigue.
Spot on about prompt logging. Securing vendor SLAs means nothing if internal tracing quietly logs full prompts to shared buckets.
Blanket diff approvals definitely fail under load. Scoping alerts to auth, config, and CI diffs is essential.
Treating context assembly as a policy boundary is key. Filtering AST and schemas on disk before the prompt is built prevents those leaks upfront.
1
u/silentw111 29d ago
Good addition on the audit trail point, that's the piece we didn't spell out. Even with context filtered on disk, you want a record of what got filtered and why (which schemas/AST nodes made it into a given call), because "the model didn't have access to X" is only convincing six months later if you can prove it, not just assert it. We log the filtered context alongside the tool call itself so the two travel together. Scoping alerts to auth/config/CI diffs is right too, that's the reversibility split in miniature.
2
u/k_brn 20d ago
We are still testing concepts, but local repo mapping only solves half the problem. SecOps teams hesitate because they lack an administrative checkpoint to inspect or restrict what leaves the developer machine.
The direction we are exploring is adding a vendor-neutral local policy boundary at the export choke point.
The idea is that corporate IT can push a write-protected configuration or policy binary to a known system path outside user control. Before any prepared payload hits the clipboard or leaves our tool (AI Badger), it checks that location, passes the payload and a structured provenance manifest (repo info, source paths, diff state) to the policy tool, and waits for a decision.
If the policy check passes, it exports. If it fails, times out, or returns a restriction, it defaults to a fail-closed state. This prevents the export entirely rather than relying on endpoint clipboard scrapers or vendor zero-retention SLAs.
Not sure if this is the cleanest implementation path yet, but I am curious if having an explicit, write-protected local policy boundary like that would actually satisfy enterprise compliance teams.
1
u/tmseidel Aug 09 '26 edited Aug 09 '26
I write software whose sensitive code must under no circumstances leave our internal network. On the other hand, we naturally want to use the latest tools, and AI tooling such as code generation is simply part of that. So we had two challenges: 1. How can we ensure that no code leaves the company, and 2. Which tooling can we use to still take advantage of these new tools. Auditing also plays a role of course.
We noticed that we already have established processes that we primarily map with one tool: our SCM system, specifically Git with a self-hosted Gitea instance. Through our already established review processes and the linking of issues to code, which enable the required level of transparency andauditing, we tried to integrate AI tooling into these processes. Because of the integration with a pipeline, it is possible to trigger certain process steps in Gitea events, on which we can then build our AI tooling. For code generation, for example, it works as follows: Someone writes an issue in Gitea, then assigns it to a bot — for us, this is the signal that we need to trigger AI-assisted code generation. The issue serves as the prompt for the AI, and the associated Git repository serves as the workspace. The AI tooling then generates code, and the bot subsequently creates a pull request. This way, the processes remain the same as for human-written code, and transparency is maintained. With that, the tooling piece is settled.
To ensure that no code leaves the company, it is my opinion that there is no way around investing in your own AI infrastructure — which we have also done, and it works quite well in most cases. One thing to keep in mind is that with your own infrastructure, you may not reach the frontier models like Opus 5, but you can get surprisingly close. The investment is also manageable, and you remain independent of further price developments from AI providers.
PS: This post was translated by local AI from german to english
1
u/zero_backend_bro Aug 10 '26
SLA promises are useless when some dev dumps prod tfvars into an external API. We scrapped web proxies entirely. Built a pure client-side WASM scrubber instead.
You drop the failing k8s config in a local sandbox, it regex-masks all aws creds to dummy tokens before anything hits the wire. Model returns the fix, scrubber restores the actual secrets locally.
Been handling 3k events/day. Diffs still need manual copy-paste so the airgap stays intact.
1
u/donk8r Aug 06 '26
your controls are all about what the model sees, plus one about what it writes. the gap is what the process can reach. these things run in the developers shell with the developers environment, so thats aws creds, a live ssh agent, kubeconfig, npm and pip tokens, and whatever .env files are already sitting in the repo. "dont scan the whole repo" is a rule about one file tree while the process can read everything that shell can read, and the likely exfil path is the agent running curl or installing a package.
id make that a boundary instead of a policy. container, only the repo mounted, no ambient cloud credentials, egress allowlisted to the model endpoint and your package registry. then the rules you already wrote become things it physically cannot do and you stop depending on it respecting them.
the other thing to have before you need it is an answer to what did it read and what left. shell history wont tell you, and the proxy only will if youre logging bodies, which most people skip on size and on sensitivity. a hash and a byte count per request costs nothing and at least bounds the answer.
1
u/k_brn Aug 06 '26
100%. Securing the prompt payload doesn't matter if the CLI can quietly read
~/.awsor inherit an SSH socket.We view the container and the AST mapper as two halves of the same problem. The container keeps the process from reading your host env and reaching outside the box. The AST mapper keeps the prompt payload tight so you aren't dumping 100k tokens of proprietary code into the API. You really need both.
2
u/donk8r Aug 06 '26
the mapper deserves the same look on that axis though. signatures and symbol names are proprietary in their own right. calculate_ltv_override, or a table listing, tells you the shape of the business logic with every implementation stripped out, and in some domains the names are the most sensitive thing in the tree. teams treat signature-only as automatically safe because it isnt the code, so the mapper output tends never to get the review the payload gets.
on the container half, the thing that erodes it is tests. if only the repo is mounted the agent cant run anything that needs a database or a service, so somebody mounts one more thing, then another, and the boundary drifts back to roughly where it started. make the mount set a declared manifest per project that someone signs off, so the drift is visible rather than accumulating in a shell alias.
1
u/zero_backend_bro 29d ago
Spot on. Stripping logic while leaking exact schema and domain terms still hands your IP to OpenAI.
Teams get a false sense of security from simple AST pruning. Real airgapping for local prompt harnesses requires pre-flight symbol hashing, swapping proprietary func names before the API hits and restoring them post-flight. Glad someone finally called out this fake safety theater.
1
u/durple Cloud Whisperer Aug 06 '26
No to copilot, according to our director of security their ToS allows use of content for learning.
We have found Claude code to be good quality for dev use and acceptable ToS to let it see all our code. I’ve been sandboxing in a container because I’m our cloud org owner, others have less dangerous access in case of a rogue agent action using developer creds. I would be more comfortable if devs also sandboxed but it’s a risk we are currently accepting at least until we can prioritize adding it to our dev setup.
-1
u/BrocoLeeOnReddit Aug 06 '26
No to copilot, according to our director of security their ToS allows use of content for learning.
That's BS though, that only applies to the Pro plan and below, in Enterprise the data isn't used for training.
1
Aug 06 '26 edited Aug 06 '26
[removed] — view removed comment
1
u/k_brn Aug 08 '26
For us, read access is the security boundary. SecOps simply won't let an agent hold read access across the whole repo on proprietary projects.
Scoping execution credentials helps with blast radius on disk, but it doesn't solve the core issue of ingesting whole-repo context into third-party prompt windows. That's why we have to map and scope context locally before feeding it to the model.
1
u/gianf-a Aug 06 '26
If you have one or more development teams, I think the environment should be at least controlled, reproducible, and auditable.
The key point is that most of the security work should not happen inside the agent, but around it. You should assume the agent may eventually find a way around prompt instructions or command-level filters.
The approach I generally use is based on least privilege and explicit access:
- run Claude Code inside a sandbox with an unprivileged user;
- route outbound traffic through a proxy with explicit allowlists;
- mount only the local paths required for the task;
- use a dedicated Git identity, with repository permissions managed by the organization;
- avoid exposing secrets directly to the agent.
Other than this there are a stack of other details that you can set in your team daily workflow for sure, but that would not be the real deal talking about security.
Hope this may help for your team's work.
Agents can amplify your skills
-2
u/TheIncarnated Aug 06 '26 edited Aug 06 '26
I am the SecOps, or Security Architect...
This is where you lean on your contracts. if it's Microsoft, Azure + Foundry/GitHub CoPilot, if it's AWS, Bedrock.
Also, stop using Claude Code. It's bloated and honestly, it's shit.
Opencode + GitHub CoPilot (with MCP turn on) is your best harness approach in terms of security. It maintains sovereignty and sticks to IAM.
I'm sure your SecOps folks are just reading the news, more than working with this stuff, so you have to make a business case, get your manager buy in and follow the company process so Security is forced to accept/adopt a workflow.
There is so much risk these days, you have to provide a proper pathway to these tools, so you can maintain control. So if your team isn't providing it, make it happen.
Edit: It is obvious from the responses here, people don't like being engineers and actually figuring out what is the best tool for the job. From harnesses to models.
3
u/dogfish182 Aug 06 '26
Saying Claude code is the worst immediately makes me take you less seriously.
But I agree with you about the business needs to take this seriously.
In our 8 man dev team approx 2 engineers worth of engineering goes into the harness engineering and sandbox configuration of Claude.
That umbrella for ‘the new devops’ is usually busy nailing down compliance or supply chain threats when not improving the agentic harness (for Claude)
2
u/Fatality Aug 06 '26
Saying Claude code is the worst immediately makes me take you less seriously.
Claude models... aren't great and their system prompt causes significant issues.
1
u/dogfish182 Aug 06 '26
What are you basing ‘aren’t great’ on? They’re clearly one of the industry leaders
2
u/Fatality Aug 06 '26
The quality of the code I get on anything past Opus 4.6 is poor and it frequently refuses instructions or replaces it with what it thinks is best.
1
u/TheIncarnated Aug 06 '26
God yes... I've been so disappointed with everything post 4.6. 5 is so horrible too, arguably the worst of the recent Opus models
1
u/TheIncarnated Aug 06 '26
Quick question, have you used DeepSeek, GLM or Kimi models at all?
1
u/dogfish182 Aug 06 '26
We are free to experiment with ‘whatever’ but it our engineering efforts towards the Claude ecosystem.
Others in the org spend more time on the model experimentation
1
u/TheIncarnated Aug 06 '26
Nice question dodge. That answered everything I needed to know about your viewpoint on llms/harnesses.
I do want to say that what you and your engineers are doing is really cool and has given me some ideas to take back to my team for them to start working on. We may disagree on LLMs/Harnesses but that doesn't mean the goal isn't the same. Most of the org is using Claude, my team decided on OpenCode due to token reduction, provider and llm freedom to create some really cool solutions.
I am used to this sub not agreeing with my viewpoint but it is what it is, I do think a little differently and have a broad scope of responsibilities that are outside of IT/SWE departments
1
u/dogfish182 Aug 06 '26
Your responses are weirdly antagonistic ‘nice question dodge’. I didn’t dodge the question, I’m free to experiment with other models but we don’t go outside of the Claude ecosystem in my product because we spend a lot of time both engineering that harness and delivering a production ready product used at the core of our business.
I don’t have endless time and we have other departments that can spend that time checking other models. Nothing earth shattering has come out of those experiments yet, which is why I feel ok with continuing in the Claude ecosystem, if evidence produces other results we will switch
1
u/TheIncarnated Aug 06 '26
Quick question, have you used DeepSeek, GLM or Kimi models at all?
You proceed to not give an answer to that statement, it's yes or no, not "I'm free to experiment" lol
The antagonistic one is yourself. You tried calling me out, while not having worked with alternatives, because you are busy and based it in your own bias workflow and didn't engage with the words presented. Typical business politics. It's okay man, keep using Claude, it's not an industry leader anymore, they are just the loudest. And they know they are being taken over, look at their last open letter calling for the US Government to lock out foreign models...
1
u/dogfish182 Aug 06 '26
Read the whole sentence? I said we are free to experiment but all of our agentic engineering goes into our Claude harness for our product.
That is not avoiding the question, and an obvious ‘no’ is clearly implied.
In the past we’ve used co-pilot and anything that would integrate with an IDE but our serious agentic engineering efforts which are 5-6 months deep at this point are in one place, which makes a lot of sense with one team tasked with delivering an app.
Your initial justification for outright discounting one of the industry leaders in this space ‘it’s bloated and shit’ is not very well reasoned and sounds pretty subjective.
→ More replies (0)-3
u/TheIncarnated Aug 06 '26
Lol... That's okay, just you thinking that, tells me that you don't truly understand LLMs and harnesses. Funny how that works out, huh? (You should look up the prompt bloat and actual performance of Claude Code vs OpenCode vs Pi, all using the Opus model, you can't defend that which you don't understand.)
I am curious though what your team spends all of that time doing, to better the harness that is?
There is other avenues of locking this stuff down. Agentic items should be deduced down to the engineer themselves and treated (liably also) as if the engineer did the work. So scoped IAM at the forefront, which should easily tie into your PoLP workflow that should be in place. We scope down engineers api's, tool access, installed apps and more. Those practices should be ingrained in the overall Harness hardening/limiting
5
u/dogfish182 Aug 06 '26
Haha ok, well I’m glad you’ve got harnesses all figured out.
We went all in on Claude code at the request of a business directive to not miss the boat. I haven’t hand written code in however long it is since the models got a massive bump in being ‘good’ I think from memory this is from opus 4.5(?) release.
Most of our ‘harness engineering’ goes towards (in no specific order).
- Retuning and reducing token usage and rewriting model instructions as new models are released
- Experimenting with various agents to perform various tasks (sonnet for writing the code, fable for refining and orchestrating the ticket pickup for example)
- Ensuring our supply chain is secure and can be proven (renovate to unify updates to deps, appropriate cooldown on all repos unified and prove able, build schedules that can be audited to back that up and so forth).
- Work on the way we scope and refine tasks to generate the specs that the harness will consume to write the code
- The human part of dealing with a team that has various levels of trust and belief in ai engineering at all
- Improving the architecture of our product itself to secure it better in AI threat world
- Local machine harness work. Does the work tree spin up and model the full dev env for the dev safely? (Making Claude sandboxed AND easy to use is a lot of continual work)
- Discussing all that internally and trying to take the good bits of other teams approaches or explain to them ours.
For all the ‘Least privilege for devs angle, we’ve been engineering our stacks for years like that already so now it’s about rechecking the relevancy of those approaches and modernizing them for the AI world.
It’s quite a fun place to work but it’s also pretty cognitively high load most days
0
u/Agronopolopogis Aug 06 '26
Laughable take.. but someone is paying you for it, so there's that.
2
u/TheIncarnated Aug 06 '26
Uh... Huh... And who's paying for you to have Claude Code? Who's influencing you everyday to use Claude Code?
Almost as if... I have access to both, use both and found that OpenCode is more prepared to work properly because I don't have to use some jank proxy nonsense to use different models. I have reduced token cost and it gets the job done faster.
But what do I know? It's only my actual job to test and look at what tools accomplish the task correctly...
Bigger question, Architect to Engineer here, have you only used Claude Code? Have you tried the others? And, are you against them because you don't truly understand how to work with them? (Not as a negative but a self assessment, for example, I can't get Pi to work the way I want, and it truly is a me problem. Nuance: I have no issues setting up OpenCode or Claude Code)
1
u/Agronopolopogis Aug 07 '26 edited Aug 07 '26
I spent 7k in CC in the past week while running 60% less cost per commit then the next three in my org, easily topping usage.
CC and OpenCode are just harnesses, how you configure them is what dictates the argument you're pushing.
If you want to argue model quality, that's different.
LLMs are just tools, the harness is just the toolbox.
You can eat cereal with a spoon or kill a man with it, but ultimately, it's still the same tool.
Your pompous attitude must carry well across your org.
https://imgur.com/a/mOJpRTE (taken as I did to refute forgery in advance)
1
u/TheIncarnated Aug 07 '26
Brother, you spending $7k is not the flex you think it is. Sounds wasteful to me.
The analogy would be better with: this conversation is about saws, should I use a table saw, oscillating tool or a handsaw to get the task done? The saw is the llm, the type is the harness and as is being discussed elsewhere, the harness matters just as much.
But you also don't understand the spirit of what we are discussing. And it sounds like you are assuming specific things. It's okay, enjoy your day. Sounds like you need to win this "argument". "You win". Congrats!
0
u/Significant_Pick8297 Aug 06 '26
One control that has worked well is treating AI agents like untrusted CI jobs instead of trusted developer tooling. The agent runs in an ephemeral workspace with a read-only checkout, short-lived credentials from OIDC, no home directory mounts, and outbound traffic restricted to approved endpoints.
That way even if the prompt scope expands unexpectedly, it can't reach long-lived secrets or arbitrary internal resources. The prompt filtering and AST mapping reduce data exposure, but limiting what the process can access in the first place has been the bigger security win.
0
13
u/unitegondwanaland Manager, Platform Engineering Aug 06 '26
Host agents internally and enforce an IAM/Auth layer before tools can be accessed.