Detailed Analysis
A small company's approach to deploying Claude Code across a six-person team surfaces a set of governance questions that are becoming increasingly common as organizations move from individual AI experimentation to structured, company-wide adoption. The poster, acting as an internal champion for AI tooling despite having no formal development background, is proposing a reasonably sophisticated architecture: segmenting a shared knowledge base ("company brain") into access-controlled areas, defaulting to read-only permissions, using GitHub as a source of truth, limiting Claude Code usage to one or two power users while the rest of the team relies on Claude's chat interface or Cowork, requiring human approval for sensitive actions, and maintaining separate test and production environments. The specific technical question — whether to manage permissions via `.claude/settings.local.json` on a per-project basis, or to enforce access boundaries through separate repositories, user accounts, folder permissions, and scoped API credentials — reflects a genuine ambiguity in how Anthropic's tooling is documented and used in practice, particularly for non-technical teams without dedicated IT or security staff.
This question matters because Claude Code and similar agentic coding tools were originally designed with individual developers in mind, where a single user typically has broad trust and visibility into their own environment. As these tools get adopted by small businesses for tasks well beyond coding — document drafting, website management, internal tooling, and now centralized knowledge repositories — the permission model has to scale to multi-user, multi-sensitivity-level environments without the benefit of enterprise IT infrastructure. Small companies are effectively being asked to solve problems that larger enterprises address with dedicated security teams, SSO integration, role-based access control systems, and audit logging — but with a fraction of the resources and expertise. The instinct to separate "who can read" from "who can act" and to gate irreversible or sensitive actions behind human approval is sound security practice, but implementing it correctly with lightweight, file-based permission configs like `settings.local.json` raises real risks: such files are easy to misconfigure, easy to accidentally commit or override, and don't provide the kind of centralized audit trail that becomes important as more people and more autonomous agents touch the same knowledge base.
The broader trend this reflects is the rapid mainstreaming of agentic AI tools into non-technical, resource-constrained organizations, which is outpacing the maturity of permissioning and governance tooling built for that context. Anthropic has been pushing Claude Code and Cowork as products usable by non-engineers, and features like MCP (Model Context Protocol) connectors, project-based memory, and enterprise admin controls are steadily being added to address exactly this gap — but a lot of the burden of designing a secure, maintainable system still falls on early-adopter teams improvising their own conventions, as this small company is doing. This mirrors a pattern seen across the AI tooling industry: capabilities (autonomous coding, document generation, agent-to-agent collaboration) are shipping faster than the surrounding scaffolding of identity management, credential scoping, and least-privilege defaults needed to deploy them safely at organizational scale.
Finally, the poster's specific instincts — read-only by default, git as source of truth, separating test/production, restricting write-capable agent access to a small trusted group, and requiring human-in-the-loop approval for consequential actions — align closely with what security-conscious practitioners in larger organizations are converging on as best practice for agentic AI deployment. The fact that a non-developer running a six-person shop is independently arriving at these principles suggests that baseline security literacy is diffusing alongside the tools themselves, even as the concrete "how" (file-based configs vs. infrastructure-level controls like scoped API keys, separate repos, and OS-level folder permissions) remains unsettled and under-documented, particularly for organizations too small to justify dedicated platform engineering.
Read original article →