'Your company brain will leak secrets: how we stopped it for big banks - Tanmai Gopal, PromptQL'
Building a shared 'company brain' for AI agents creates massive value but also serious security risks (leaking secrets across roles); the solution is a singl...
By Sean WeldonYour Company Brain Will Leak Secrets: How Shared Wiki Architectures Solve Cross-Role Leakage
Abstract
Organizational deployments of coding agents increasingly rely on a shared repository of institutional context - a company brain - to supply agents with documents, procedures, and tool access necessary for useful work. This synthesis argues that while such shared context generates compounding value, it introduces a severe confidentiality failure mode: a naively constructed company brain will leak sensitive information across organizational roles. Drawing on deployment experience across roughly 15-20 companies spanning AI-native startups, tech-forward firms, and Fortune-level financial institutions, four architectural principles emerge: a single shared wiki of interconnected markdown files, per-file scoped access control, human-attributed and human-approved memory writes, and per-user credential injection at the transport layer rather than credential storage in the agent sandbox. Empirical observation indicates that healthy company brains exhibit increasing daily update rates rather than decay, and that multi-human collaborative debugging yields the highest-quality context. Practical implications include a concrete blueprint for enterprise-safe agent memory systems.
1. Introduction
The practical bottleneck in enterprise agent deployment is no longer model capability but context supply and containment. Agents such as OpenClaw and Hermes can execute substantive knowledge work when given organizational context, yet broad rollout is consistently blocked by a single concern: an agent with access to a consolidated knowledge store may surface information the requesting user is not authorized to see. The canonical failure case is an intern querying the shared brain and receiving compensation details.
"If you go ahead and build a company brain, it will likely leak company secrets."
This paper defines the company brain as shared context expressed in markdown files, combined with access control rules governing the data and tools exposed to a coding agent. The definition is deliberately narrow: the target architecture is not a general-purpose LLM equipped with tool calls, but a coding-agent architecture in the lineage of Claude Code, Claude Co-work, and the Codex application. A key premise is that coding agents generalize - their file-manipulation and execution loop can solve non-coding organizational problems, from answering security questionnaires to coordinating incident response.
The central research question is architectural rather than algorithmic: what minimal set of structural constraints permits organization-wide shared context without cross-role information leakage or privilege escalation? Section 2 situates the problem relative to existing knowledge-management approaches. Section 3 analyzes deployment observations, growth dynamics, and two dominant use cases. Section 4 presents the resulting architecture. Sections 5 and 6 discuss implications and limitations.
2. Background and Related Work
Prior attempts to consolidate organizational knowledge have generally followed a top-down construction model: build a comprehensive knowledge graph or knowledge base, then retrofit security controls. The position advanced here is that this sequence has historically failed and does not become viable under agentic access patterns.
"We're not building a gigantic knowledge graph knowledge base for the company and then trying to secure it - that anyway hasn't worked, won't work."
Recent product entries have attempted the company-brain framing directly. Claude Tag's launch was positioned in this space but is assessed as falling short specifically on the cross-role leakage problem, largely due to its per-channel memory model. The perspective presented derives from engineering experience in distributed data access - co-founding PromptQL (a model-agnostic analogue to Claude Tag, compatible with GLM, GPT, and other backends) and previously building the Hasura GraphQL engine, deployed at Apple, Meta, and JP Morgan. This lineage is relevant because the proposed solution reuses access-control patterns from data infrastructure - claims-based, per-request authorization - rather than inventing a novel security model specific to agents.
3. Core Analysis
3.1 Growth Dynamics of a Healthy Company Brain
Observational data from a company brain of approximately 5,000 interconnected wiki pages reveals a counterintuitive growth pattern. When polled, audiences typically expect update frequency to decline over time as an organization's knowledge stabilizes. Instead, observed data over a two-month period showed a steadily increasing curve of daily updates. The proposed explanation is that as a system begins working reliably, users progressively delegate more complex responsibilities to it - first querying, then interpretation, then action, then testing - each stage generating new documentation needs. Consequently, both the absolute size of the brain and its daily update rate increase concurrently, which is interpreted as the primary signal of organizational health rather than convergence to a static knowledge base.
3.2 Two Use Cases and Their Distinct Risk Profiles
Two use cases dominate observed deployments. The first is individual use, wherein a single person leverages company context to complete a task - for example, answering an inbound security questionnaire using internal documentation. The second is multiplayer collaboration, wherein multiple humans jointly operate a shared agent, such as during incident management: fetching logs, investigating root cause, generating a pull request, and deploying to staging or production. Both carry significant security exposure, but the multiplayer case is qualitatively different because it combines knowledge access with tool execution, creating conditions for privilege escalation - an agent used for benign log inspection could equally be directed to execute a production deployment absent proper controls. Notably, collaborative debugging sessions, in which multiple engineers correct an agent's approach (e.g., switching a LIKE query to an equals-to query) and debate root cause, were identified as producing the highest-quality context for the brain, since disagreement and correction generate more precise, validated knowledge than solitary use.
3.3 Failure Modes of Prior Approaches
Two commonly attempted approaches to shared knowledge were found inadequate. The first, wherein employees manually author reusable "skills" to a shared repository such as GitHub for the benefit of unknown future colleagues, was assessed as unrealistic:
"Nobody is going to write skills for another person in GitHub that is not natural to us in the day-to-day of doing work."
The second, team- or channel-scoped memory (as implemented in Slack-integrated agents), fails to constitute a true company-wide brain because knowledge remains locked to its originating channel. A new member added to a channel gains access to that channel's memory, but knowledge does not propagate to adjacent teams or contexts, reproducing organizational silos rather than eliminating them.
4. Technical Insights
The resulting architecture rests on four principles that jointly determine system behavior:
- Single shared wiki: All organizational context resides in one corpus of interconnected markdown files rather than siloed per-team stores, eliminating the fragmentation problem identified in Section 3.3.
- Per-file scoped access control: Each wiki page carries independent read/write scopes in an ABAC-like model, allowing fine-grained authorization (e.g., a finance-scoped page) without requiring a monolithic security layer applied after the fact.
- Human-approved, attributed writes: Agents do not autonomously add memory. Instead, they surface proposed additions as bullet points with suggested scopes; a human reviews and confirms via an explicit "add to wiki" action. This is deliberately lighter than a full GitHub pull-request review cycle but stricter than autonomous agent memory writes. Every accepted addition is attributed to the approving human's name rather than the agent, preserving accountability:
"No, Tanmai added this - that name needs to be there so you can tie it back to this is the person who screwed up."
- Credential injection at the transport layer: Credentials are never stored in the agent's execution sandbox. Instead, the specific user's credentials are injected at the HTTP or SQL layer at request time, so the agent acts as that individual for each interaction rather than under a shared or elevated identity. This virtualizes all interactions with real data and places access control in the hands of the credential owner, directly preventing the privilege-escalation risk identified in Section 3.2.
A practical implementation note: custom prefixes applied to wiki page names produced lookup failures in production, indicating that naming and indexing conventions require careful validation independent of the access-control logic itself.
5. Discussion
These findings suggest that the central challenge in enterprise agent deployment is not knowledge representation but authorization granularity combined with organic growth. Systems designed as top-down, centrally built knowledge graphs are structurally mismatched to how organizational knowledge actually accumulates - incrementally, unevenly, and driven by immediate task needs rather than anticipatory documentation. The framing of "growing" rather than "building" a company brain reorients the design problem toward self-service contribution embedded in daily work, with security enforced structurally (per-file scope, credential injection) rather than through retrospective auditing.
A notable implication concerns the relationship between collaboration and data quality: multi-human debugging sessions appear to generate superior context precisely because of the friction and correction inherent in disagreement, suggesting that architectures should be optimized to capture multiplayer interactions rather than treating them as an edge case of single-user design. This has industry-wide relevance as agent platforms increasingly market "team" or "workspace" features without necessarily resolving the underlying cross-role leakage problem, as illustrated by the Claude Tag case.
Open questions remain regarding scalability of human-in-the-loop approval as wiki size and update frequency grow, and regarding how attribution-based accountability interacts with regulatory audit requirements in financial-services contexts specifically.
6. Conclusion
This synthesis identifies four architectural principles - single shared wiki, per-file scoped access, human-attributed approval of memory writes, and transport-layer credential injection - as jointly sufficient to permit organization-wide agent context without the cross-role leakage failure mode common to naive implementations. The practical takeaway for engineering teams is that security should be embedded structurally at the point of read and write, not layered on afterward, and that organic, incrementally-approved growth outperforms centrally planned knowledge-base construction. Organizations deploying coding agents at scale should prioritize per-user credential proxying and lightweight human approval workflows over either fully autonomous memory systems or siloed, channel-scoped alternatives.
Sources
- Your company brain will leak secrets: how we stopped it for big banks - Tanmai Gopal, PromptQL - Original Creator (YouTube)
- Analysis and summary by Sean Weldon using AI-assisted research tools
About the Author
Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.