Existential dread aside, what are you guys doing to throw a lasso around Claude accessing on-prem resources?
Posted by anpr_hunter@reddit | sysadmin | View on Reddit | 50 comments
Title says it all. We've been subjected to a Claude Enterprise rollout at warp speed over the past month, and only now is our leadership realizing that our warnings about carte-blanche UNC and ODBC access were valid, and we are now in a perilously undergoverned situation with our Claude Desktop clients.
We're looking at leveraging Docker at the client and server levels to start funneling all the MCP stuff through chokepoints where we can apply EDR/DLP policies.
This is super, super easy to achieve when you're dealing with Claude interacting with cloud-hosted services with API keys, as many software engineering firms do, but the documentation Github offerings for interactions with on-prem systems - MS SQL, SMB servers - are sparse and immature for enterprise use. We're trying a few things with Docker, MS DAB and other things and making some headway though.
What's your angle of attack?
981flacht6@reddit
Waiting for Mythos so take down everything first so we can rebuild from scratch.
Centimane@reddit
If you're talking Claude desktop, then Claude is performing actions on behalf of a user. Claude is probably using the credentials of that user in order to interact with things. Which means you can't effectively limit Claude more without limiting the users more.
But also, users can allow/deny Claude to run commands. Hold them accountable for what Claude does on their behalf.
bageloid@reddit
We are trialing Prompt Security next week as part of this. There are a couple other vendors we are looking at for visibility/control as well.
Thank god I had the foresight to engage vendors proactively because one month ago we were no ai/no cloud. This month we have over half our devs on Claude enterprise and in two months we are going to have an azure environment with Azure OpenAI available to all employees.
inameandy@reddit
Smart to get ahead of it. One month from "no AI/no cloud" to half the devs on Claude Enterprise is a brutal timeline.
Worth adding to your evaluation: Prompt Security is strong on the prompt/output layer but the gap with Claude Enterprise specifically is the MCP tool calls hitting your on-prem resources. That's where the original poster's pain is. Make sure whatever you pick can enforce policy on the tool call itself, not just the prompt going in or response coming out.
I built aguardic.com for that layer. Pre-execution enforcement on MCP tool calls plus the standard prompt/output governance. Would be happy to show you how it compares before your trial next week. Even if we're not the right fit, the comparison criteria are useful when evaluating any AI governance vendor right now.
thortgot@reddit
How would providing your data to a middle layer be a more secure solution than actually protecting your data?
Actual answer is to use DLP security to prevent MCP solutions from reading sensitive data.
inameandy@reddit
Fair question. Aguardic isn't a middle layer that sees your data. The enforcement runs in your environment (self-hosted or your cloud), policies are evaluated locally, and only the policy decisions and audit metadata are logged. Your actual data stays where it is.
On DLP: you're right that DLP should prevent MCP from reading sensitive data in the first place. That's the ideal. The problem is DLP classifies data at rest or in transit based on patterns and labels. It doesn't understand agent context. An agent legitimately reading a customer record for a support task vs the same agent reading the same record to exfiltrate it look identical to DLP. Both pass the data-level checks.
Pre-execution policy on the tool call adds the behavioral layer DLP can't provide. "This agent is authorized to read customer records but not to then write them to external endpoints in the same session." DLP protects the data. Policy enforcement protects the workflow. You need both.
thortgot@reddit
That assumes you trust the middleware. I assume its not open source.
DLP prevents the data from being on boarded in the first place. The data is either protected or it isnt.
inameandy@reddit
On DLP: agreed it's the first line of defense, but agents need access to real data to be useful — you can't DLP-block everything and still have a functioning agent. The gap is behavioral: same data access, different intent. That's what policy on the tool call covers.
thortgot@reddit
And the risk is still inherently there. Why would I assume a tiny company is trust worthy to manage this data?
Semantic protections aren't deterministic meaning they are wildly insufficient for actually important data.
Proper agent orchestration leaves the sensitive data in locale and uses Semantic communication instead.
inameandy@reddit
Two fair points.
On trust: we’re not only SaaS. Self-hosted deployment runs entirely in your environment. Policy engine evaluates locally, data never leaves your infrastructure, we never see it. Only policy decisions and audit metadata get logged.
On deterministic vs semantic: agreed semantic alone isn’t sufficient. Deterministic runs first. Pattern matching, allowlists, regex on SQL, explicit tool blocks. 60-70% of rules that matter (no SELECT on PII tables, no writes to production, SMB path blocks) are deterministic and run in under 10ms. Semantic only kicks in for ambiguous cases.
On semantic communication keeping data local: valid architecture and the ideal end state. Challenge is most Claude Enterprise deployments aren’t there yet. MCP integrations make direct queries out of the box. Policy enforcement on tool calls is the stopgap until semantic-only patterns are standard.
gslone@reddit
Prompt security is a product name? if so, that is a terrible name. Whats the vendor?
bageloid@reddit
Well it was bought by Sentinel One.
XDWiggles@reddit
What’d you look at for competitors of prompt security? I’ve been recently tasked with this. Most of them seem half baked.
bageloid@reddit
Harmonic security and oximy. But still haven’t set up trials with them.
kozak_@reddit
We don't care. We are a hybrid aws shop and use AWS bedrock.
AWS got us by the gonads anyway
inameandy@reddit
Docker chokepoints work as a stopgap but you're solving at the wrong layer. Network funneling tells you what happened. It doesn't prevent the bad query from executing.
The approach that scales: pre-execution policy enforcement on the MCP tool calls themselves. Before Claude runs an ODBC query or hits SMB, the policy engine evaluates against rules like "no SELECT on tables with PII" or "no writes to production from any agent." The agent gets ALLOW, BLOCK, or REQUIRE_APPROVAL back. Action never fires until policy clears it. Works the same on-prem or cloud because you're enforcing on the tool call, not the network path.
Built aguardic.com for this. MCP integration, pre-execution enforcement, session-aware evaluation, full audit trail. Works alongside EDR/DLP. Happy to show the on-prem MCP piece since docs are thin in this space.
Also respect for the leadership exit. Working the real problem with a good team beats C-suite battles every time.
gslone@reddit
How exactly does the tool intercept all tool calls?
inameandy@reddit
We publish an SDK that hooks into your agent's tool execution layer — every tool call gets evaluated against your policies before it executes. For MCP clients like Claude Desktop, same engine exposed as an MCP server. Either way, your agent gets ALLOW, BLOCK, or REQUIRE_APPROVAL back before anything fires.
gslone@reddit
Isn‘t this builtin in claude? And how would one enforce the usage of this SDK?
inameandy@reddit
Claude's built-in confirmation is per-user, per-click — no centralized policy, no audit trail, no org-wide rules. For enforcement: you control the agent's runtime. If you're deploying agents in your infra, the SDK call is part of your tool execution pipeline — agents don't get to skip it the same way they don't get to skip auth middleware.
gslone@reddit
You can roll out central rules via MDM or the claude tenant and it supports OTel telemetry to log all tool call decisions.
inameandy@reddit
Fair point, Claude's tenant-level controls and OTel telemetry cover a lot if you're all-in on Claude. The gap is when you're running agents across multiple LLM providers or custom frameworks, since no single vendor's admin console covers all of them. Aguardic is one policy engine across Claude, OpenAI, custom agents, and MCP servers.
gslone@reddit
This thread is difficult to follow, everyone throwing buzzwords and product names around without context. Can we get technical?
OP, are you talking about claude code, cowork or another product? How are you „using docker to start funneling MCP through it“? Are you talking about Docker Sandboxes?
As for UNC paths, what exactly do you mean? Iirc, by default claude write-access to the current working directory and will prompt for access to other paths. do you mean that by „carte blanche access to UNC“, or are your users running with „—unsafe-skip-all“ type flags?
Independent-Sir3234@reddit
We ended up treating it like any other new privileged integration: no direct share access, only a small broker service with read-only service accounts and audited queries. We tried broad file share exposure first and it got messy fast because people started treating every path as fair game. The boring allowlist-and-proxy setup was slower to roll out, but it cut the panic way down.
DestinyForNone@reddit
My blood pressure went up, think about a scenario where we would allow Claude that level of access...
Yeah, we never let that genie out of the bottle
SageAudits@reddit
I imagine some junior sales admin, getting frustrated and telling Claude to just delete everything and start over.
Bye file servers!!
ledow@reddit
Good luck putting the genie back in that bottle.
Should never have been allowed in the first place.
The only way to stop it is literally to stop it. Don't allow it. Remove it from everywhere.
Then, maybe, start again from scratch in a controlled manner.
mahsab@reddit
Yeah, turn off the internet. Or better yet, power. Start from the scratch.
SageAudits@reddit
Back to papers and pencils
anpr_hunter@reddit (OP)
I couldn't agree more, and actually stepped down from a management role specifically because I knew the next conversation I had with the CFO would end with me being escorted from the building.
NuAngelDOTnet@reddit
Read only accounts for AI coworkers. HR for anyone who violates that.
SageAudits@reddit
Are you talking about agents then? Read only sure but how are you handling outbound web requests then? Claude desktop runs in the current user session, right? And obviously the end user can create connections for the read only accounts locally, (eg use my ODBC connection, Claude!) so that’s gotta be fun 😝
anpr_hunter@reddit (OP)
This is another angle of attack we're employing which I forgot to mention.
Folks who want to interact with SMB servers will have to do so from an AWS Workspace tied to a read-only AD account. We may lean fully into this approach and force all Claude Desktop installs to be deployed this way, but it feels like a stopgap solution that will take a long time to break way from if a better option comes up.
Expensive_Finger_973@reddit
Personally, I voiced my concerns over it and got the results from above me in writing. After that I stopped worrying about the outcome. When it comes the CYA will either save my job or allow me to explain the resume gap during an interview credibly.
SikhGamer@reddit
We have an entire team around this. Their entire life is basically this now. They go through and vet what is and isn't allowed. It's shit work. It's all controlled at an enterprise level.
mtgguy999@reddit
Claude has its own network firewalled off with no access to internal resources. Any files Claude needs to be access are manually approved by CTO and moved to the claude network. The assumption is these files are subject to being leaked
No_Investigator3369@reddit
What if claude applies for a remote IT security job, gets it, then proceeds to turn off those rules after gaining the trust of the users?
Afraid-Donke420@reddit
Everything in markdown files, create a way to build context, then from there use an MCP with commands to allow the user to review the data the want
Implement features like rigrep and a snapshot tool for this markdown so it can have the freshest content and also see what’s changed etc.
I’ve done this now for a few systems, scrape API or data, convert to markdown organized, feed to MCP and then feed to LLM.
anpr_hunter@reddit (OP)
Yeah, that's a sticking point for us: A lot of the data our users want to play with can't live locally, especially in the ODBC space, as a lot of our customers use their SSN as their federal tax ID
NoyzMaker@reddit
Hope you aren't international this sounds like a GDPR and data sovereignty nightmare.
anpr_hunter@reddit (OP)
Like I said, existential dread :|
Midnight_Rain1213@reddit
I hope you have a legal team reviewing things...
Darkace911@reddit
Legal is like, "We have an NDA with them, right?" "What is the problem?"
olpa99011@reddit
With GDPR…..even a name is considered personally identifiable.
Responsible_Ad5216@reddit
I utilize Cursor native sandboxing, keep env files hidden from Claude, keep ash keys in a kdbx container and pipe them using agent and my a yubikey only for necessary periods. I use IaC where I audit every script and manually whitelist any sudo/admin commands prior to execution.
It is a thin edge, but we have learnt to walk it since the beginning, one wrong command on a live server (before IaC) could destroy the whole prod.
I have contemplated running independent agents. I think I will be deploying coder.com on some older server next month for that.
(This is not an advertisement for either of these products)
OkEmployment4437@reddit
You're on the right track with Docker as a chokepoint. Key mental shift: treat the MCP layer as an untrusted integration plane. Claude Desktop should never talk to SQL or SMB directly. Put a proxy in between that you control.
Practically:
Proxy everything. A thin API gateway translates MCP tool calls into scoped queries. Claude never sees a connection string or UNC path. The proxy holds creds and enforces parameterized queries.
Service identity per tool. Each tool gets its own service account, read-only by default, scoped to specific tables/shares. Write access needs a separate tool, separate identity, explicit approval.
Gate tools with Entra groups. Finance gets GL lookup, eng gets repo search, nobody gets "run arbitrary SQL."
Log at the proxy. Every request plus response metadata, correlated to user and invocation ID. Ship to SIEM.
Segment the network. Proxy talks to backends on a dedicated VLAN. Claude endpoints never get routable access.
For rollout, start read-only on non-sensitive data. Let it bake while you tune logging, then selectively add write tools with per-invocation approval.
FriscoJones@reddit
Was this written by Claude lmfao
gogreenenj@reddit
Warp speed doesn’t sound like crawl walk run
bjc1960@reddit
We tie the Claude connectors to an Entra group - so the app reg only supports users in that Entra group. We also have CA rules for Claude too, requiring phishing-resistant MFA, etc.
To quote the movie "No Country for Old Men", 'you can't stop what's coming...'
From a security perspective, most of of our staff is still in the "If it ain't Chrome, Outlook, Acrobat or a printer, no want it, don't need it, wouldn't know what to do with it if I had it."
Alarmed_Cupcake_3120@reddit
The security model matters more than the access method. Most teams are using either SSH tunnels with strict IP allowlisting, VPN connections with conditional access policies, or API gateways that sit between Claude and your internal systems—effectively creating an abstraction layer that logs and controls every request. The key is treating Claude like any untrusted external application: never give it direct credentials, use service accounts with minimal permissions, and implement request signing so you can audit what actually happened. If you're building this yourself, you'll spend months on this; if you're evaluating platforms, look for ones that handle the auth layer and keep your credentials completely isolated from the LLM's context window.