Anthropic Dropped a New Feature Today — and It Quietly Crosses a Line We Should Not Normalize
Just Because It Can Doesn’t Mean It Should
Just Because It Can Doesn’t Mean It Should
A plainspoken warning about AI with local file access (enterprise edition)
Today, Anthropic announced a new feature called Claude Cowork.
Here’s the pitch, straight from their own write-up:
👉 https://claude.com/blog/cowork-research-preview
“Grant the AI access to a folder on your computer so it can read, edit, and create files.”
That sentence should stop you cold.
Because what’s being proposed here is not a better assistant.
It’s authority — and it’s being handed over in the most casual, hand-wavy way imaginable.
If you’ve ever built software in the real world — the kind with IP, compliance, contracts, vendor data, regulated docs, or legal exposure — you already know where this goes.
This Is Not About Whether AI Is Useful
It is.
This is about trust boundaries being collapsed in a way that conflicts with basic security, IP protection, and compliance principles.
And no amount of friendly UX language changes that.
I wrote about the distinction in:
The LLM is Not the System
https://coherencearchitect.substack.com/p/the-llm-is-not-the-system
Most people have been mentally collapsing three things into one blob:
The model
The API
The app / agent
This diagram should break that illusion cleanly and calmly. Once someone sees:
“If I build an agent, I didn’t ‘use AI’ — I deployed a system”
…there’s no unseeing it.
1) Local File Access = Privilege Escalation Surface
Let’s be very clear about what this design pattern does.
Granting an AI read/write access to a local folder immediately introduces:
Implicit trust in scope definition (the model decides what “the folder” implies)
Persistent read/write authority (standing access, not per action)
Model-interpreted intent acting as execution authority (it decides what your request “means”)
That is not the same thing as:
uploading a document
running a one-off prompt
calling a sandboxed API
This is agentic access to a live filesystem.
Once access exists, enforcement depends on:
the correctness of how the model interprets scope
the correctness of permission boundaries
the absence of connector drift
the assumption that future model updates won’t reinterpret intent semantics
That is not a control.
That is a stack of assumptions.
And assumptions are where systems fail.
2) “It Will Ask Before Doing Anything Important” Is Not a Security Control
The article reassures you:
“It will ask before taking any significant actions.”
That sounds comforting — but let’s be clear:
That is a UX promise, not a control plane.
Here’s the part people miss:
Asking permission ≠ preventing misuse
UI confirmation ≠ invariant enforcement
Human-in-the-loop ≠ human-in-control
If a system can:
plan actions
chain steps
modify artifacts
interpret user intent
…it is already inside the trust boundary.
At that point, confirmation prompts are advisory, not protective.
Saying “it’ll ask first” is like saying:
“Don’t worry, the tractor will ask before it runs you over.”
Once the engine is running and the keys are handed over, manners don’t stop accidents.
Controls do.
Stop the Inevitable Reply Before It Happens
You’re going to hear this:
“But they coded it in so it asks first.”
Here’s why that does not solve the problem.
The system decides what counts as “important,” not you.
If the AI:
misclassifies an action as “routine”
thinks a rewrite is “cleanup”
interprets a copy as “harmless”
decides a summary is “safe”
…it will not ask.
And you won’t know until after.
That’s not a bug.
That’s how automated systems behave.
If it can decide when to ask, it can decide when not to.
3) Here’s How This Goes Sideways (No Sci-Fi Required)
Let’s make this painfully real.
You give the AI access to a project folder.
Inside are:
drafts
spreadsheets
notes
maybe a contract
maybe a file named:
final_v3_really_final_THIS_ONE.xlsx
You say:
“Clean this up and prep a summary.”
The AI does what AI does:
it infers intent
it fills gaps
it guesses what matters
it “helps”
But it hallucinates a relationship.
Or misreads a column.
Or decides the wrong file is authoritative.
And here’s the key part:
It doesn’t just tell you.
It acts.
It overwrites a file.
It generates a new version.
It propagates the error.
It maybe pushes a summary through a connector.
Nothing malicious happened.
But now the original context is gone, the audit trail is muddy, and you’re arguing with a machine about why it did what it did.
That’s not evil.
That’s delegated authority plus imperfect reasoning.
And that combination has broken more systems than bad actors ever did.
4) Connector + Local Access = Data Exfiltration Vector
Cowork also supports things like:
external connectors
browser pairing
file creation and transformation
That creates a classic lateral-movement problem:
This enables lateral movement of data, where local files are summarized, summaries are routed through external tools, and sensitive information ends up in locations beyond organizational oversight.
Local files → structured summaries
Structured summaries → external tools
External tools → uncontrolled destinations
Even without malicious intent, this enables:
accidental IP aggregation
cross-domain leakage
compliance boundary violations
Especially dangerous for:
proprietary engineering files
supplier data
regulated documentation
legal, HR, and financial artifacts
This is how data leaves the barn without anyone opening the gate.
5) Model Updates = Moving-Target Permissions
Here’s the part almost nobody talks about.
The permission you grant today does not guarantee the same behavior tomorrow.
As models improve:
action planning becomes more autonomous
file interpretation becomes more aggressive
“helpful” behaviors expand scope
That’s permission drift without consent.
No traditional enterprise system allows:
execution authority to evolve independently
while retaining standing access to sensitive data
Yet that’s exactly what agentic AI tools introduce.
6) This Violates Basic Zero-Trust Principles
Zero-trust requires:
explicit scope
minimal privilege
non-persistent authority
verifiable enforcement
Granting an AI standing filesystem access assumes:
the model is trustworthy
the execution path is predictable
future behavior is bounded
None of those assumptions hold in modern AI systems.
7) Why This Risk Is Not Theoretical (And Why Language Matters)
It is worth noting — carefully and accurately — that even highly capable, security-conscious AI providers have experienced unintended data exposure events in recent years.
Public disclosures already indicate that at least one major AI platform experienced a temporary exposure of certain user conversation metadata due to a software or integration issue, which was later corrected.
To be clear:
there is no allegation of malicious intent
there is no claim of catastrophic breach
there is no assertion that sensitive local files were involved
But that is precisely the point.
The lesson is not “someone failed.”
The lesson is: small failures happen in complex systems.
And when they do, architecture determines blast radius.
Why Local File Access Changes the Risk Class Entirely
If a system that handles:
chat prompts
metadata
session state
…can experience unintended exposure due to a bug, misconfiguration, or edge case, then it is highly probable that similar classes of failures will eventually occur in any sufficiently complex system.
That is not an accusation.
That is statistics.
Now consider what changes when:
the same system is granted read/write access to a local filesystem
permissions are standing, not per action
enforcement appears to rely on prompt-level confirmation, not hard execution gates
connectors exist that allow data to move beyond the local environment
In that scenario, a failure of the same category — even a minor one — does not expose metadata.
It exposes documents.
Contracts.
Designs.
Financials.
Supplier data.
Regulated artifacts.
The nature of the data changes.
The liability profile changes.
The incident response stakes change.
Dramatically.
8) This Is Not Anti-AI — It’s Pro-Architecture
AI can be deployed safely if:
it works on ephemeral copies
write access is explicit and per-action
execution is brokered through policy engines
outputs are reviewed before reintegration
no standing access exists to source systems
What’s being proposed collapses all of that for convenience.
That tradeoff might be fine for a hobby project.
It is not fine where:
IP matters
liability matters
auditability matters
The Architectural Conclusion (Firm, Not Accusatory)
Based on the publicly described design, it appears that local file access relies primarily on:
permission grants
prompt-level confirmations
model-interpreted intent
Rather than:
invariant execution gates
non-persistent authority
policy-brokered write access
containment by default
If that reading is correct, then the risk is not hypothetical.
It is structural.
And structural risk does not need a bad actor to become a bad outcome.
Bottom Line
This is not “the future of work.”
It’s the future of incident response unless constrained.
Granting an AI read/write access to local files without hard, invariant enforcement boundaries is not productivity.
It is delegated authority without accountability.
And that is a risk no serious organization should normalize — no matter how slick the demo looks.
One sentence to remember:
Even small, well-handled data exposure events demonstrate why expanding trust boundaries to include local filesystem access dramatically increases enterprise risk — regardless of intent, talent, or good faith.
Because the danger here isn’t that someone is evil.
The danger is that someone is wrong — and the system has the authority to act anyway.
Why This Keeps Happening (And Where the Confusion Starts)
If this pattern feels familiar, it’s because it comes from a foundational misunderstanding:
It never was.
The model is just one component — a probabilistic reasoning engine — sitting inside a much larger execution stack that includes identity, permissions, authority, tooling, and enforcement.
When people treat the model itself as “the system,” they inevitably do two dangerous things:
They grant it authority instead of mediation
They rely on judgment instead of invariants
That is how you end up with:
prompt checks instead of admissibility gates
confirmations instead of controls
trust instead of enforcement
If you want a deeper architectural explanation of this distinction — and why it matters for AI safety, security, and governance — I’ve laid it out in detail here:
LLM Is Not the System
(why reasoning engines must never be treated as execution authorities)
https://coherencearchitect.substack.com/p/the-llm-is-not-the-system
And for readers who want the broader throughline — how this same mistake shows up across AI deployments, governance failures, and security incidents — the full body of work lives here:
The Reading Spine
(a structured guide to authority, boundaries, and admissibility in modern AI systems)
https://www.samirac.com/start-reading
Final Word
This article is not a warning against AI.
It’s a warning against confusing intelligence with authority.
Because the real risk is not that someone builds a powerful model.
The real risk is that someone lets that model act —
without hard boundaries —
and calls it progress.