Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL

A company brain becomes dangerous at the moment it becomes useful. If an intern can ask the same shared agent that executives and finance teams use, an ordinary question could expose compensation or other restricted information. Tanmai Gopal, CEO and co-founder of PromptQL, approaches that problem from a team that previously created the Hasura GraphQL Engine and worked extensively on data access and security.

The design grew out of roughly a year of work with 15 to 20 organizations spanning AI-native companies, technology-forward businesses, and Fortune 100 banks. Those groups tolerate very different levels of experimentation. An AI-native startup may accept breakage if the capability is compelling; a bank must prevent a broadly capable agent from inheriting broad access merely because deployment is convenient.

PromptQL’s own company brain contains about 5,000 interconnected pages modeled as a wiki. The storage format is not the essential choice: linked Markdown, a knowledge graph, or another representation can hold the material. The more revealing signal was the daily edit count. A neglected knowledge project should show an early burst followed by decline; an automatically populated memory might fluctuate around a steady level. PromptQL instead observed a gently rising edit rate over a two-month window.

The proposed explanation is cumulative teaching. Once the brain can query data, people teach it how to interpret the result. Next they teach it to act, then to evaluate the action through something such as an A/B test. Each imperfect skill also continues to receive corrections, so the update rates from old and new capabilities add together. This is an early observation rather than an established health metric: Gopal explicitly allows that the curve may eventually flatten into a steadier pattern.

Two use cases establish what must be secured. Personal use of shared knowledge: one employee asks an agent to answer a customer security questionnaire using information learned from colleagues. Multiplayer work: several employees use one agent to fetch logs, inspect code, raise a pull request, deploy through staging and production, and create an alert during an incident. The first moves knowledge between people; the second also performs actions under different privilege levels.

Here, a “company brain” means shared context in linked files plus access-control rules for the data and tools available to a coding agent. The coding agent matters because it can solve general tasks by writing and running programs, rather than merely retrieving a passage and returning text. The proposal therefore does not begin with one enormous knowledge graph loaded into a model. It begins with context and permissions available to an agent as it works.

That brain cannot realistically arrive as a two-year central knowledge project, especially in a century-old organization. The work itself must produce it. Each employee contributes the part encountered while doing a real task, allowing the system to accumulate instead of requiring a central team to reconstruct the organization in advance. Gopal’s memorable distinction is to “grow a company brain,” not build one.

The concrete example starts with a customer security-onboarding email containing several questions. The agent reads the message and its screenshot, drafts answers using company information such as the trust center and security architecture, and sends the approved draft when instructed. The observable change is simple: an unanswered questionnaire becomes a completed customer email without Gopal manually locating every security fact.

The causal chain is harder. A security or compliance specialist must previously have answered a similar questionnaire. Knowledge from that work must survive the original session, become available outside that person’s agent, and reach the later email task—without making restricted material visible to everyone. That contribution path is the real company-brain problem.

Two obvious approaches fail for organizational reasons. A shared GitHub skills repository asks an exhausted compliance specialist to anticipate an unknown colleague’s future need, write a reusable skill, and navigate review after completing a large spreadsheet. Most people will not do that extra work. A team agent with automatic memory lowers the effort but creates another silo: knowledge saved inside one team or channel remains unavailable elsewhere unless the later user joins that same space.

The third option keeps knowledge company-wide without making it universally readable. All context enters one linked wiki, while every file carries read and write scopes. A finance page can require a finance claim; a personal page can remain personal. Centralizing the namespace prevents channel-level silos, while file-level authorization prevents centralization from becoming universal access.

The most important rule governs writes: the agent must not silently save memory. It proposes facts and the scopes under which they should be stored, then a person accepts or rejects the proposal. This occupies the middle ground between a full GitHub contribution workflow and unreviewed automatic memory. The agent handles page selection and links; the reviewer concentrates on whether the facts are correct and who should see them.

A sales email demonstrates the interaction. After helping with the message, the agent presents a small box containing the facts it wants to add. The user reviews those bullets, chooses scopes per page if needed, and presses “Add to wiki.” The result is a low-friction contribution attached to the work that generated it, rather than a separate documentation chore.

Every accepted change also carries a human name. “The agent added this” is insufficient because it leaves no accountable decision-maker when a scope is wrong. Human attribution records who approved both the fact and its visibility, making investigation and remediation possible. Attribution does not prevent a mistaken approval, but it removes anonymous, unreviewed knowledge mutation.

What path lets an agent reuse shared knowledge without reading as an all-powerful service account? The requesting user’s claims must accompany every read. The diagram makes the key relationship visible: the agent proposes knowledge as an assistant, but the human authorizes writes and the user’s own identity authorizes reads.

The multiplayer case raises the stakes because several people with different privileges share one investigation. In the incident example, the wiki-learning system fails. The agent initially lacks an effective diagnostic procedure. An engineer directs it to the relevant OpenTelemetry span name, then notices that it is using a slow LIKE query and replaces it with an equality query. That change surfaces more useful details and eventually points toward the failing code.

The first proposed lesson—use equality rather than LIKE—is useful but incomplete. A second person joins and challenges the technical decision behind a custom prefix on wiki page names. Their argument, followed by deeper investigation, changes the durable lesson from a local query optimization into a production rule: pages should not have that prefix because it can cause lookup failures. The conversation improves the memory by exposing the reason behind the incident, not merely the command that happened to find it.

This is why collaborative threads can produce high-quality organizational context. Several people contribute different evidence, question an undocumented decision, confirm the root cause, and agree on a fix. Yet the same shared surface creates privilege escalation risk. Permission to inspect logs or prepare a pull request must not automatically confer permission to deploy to production. In a bank, debugging, staging, alerting, and production deployment may belong to different people.

How can one shared agent preserve those distinctions? Keep credentials out of its cloud sandbox. When code reaches an HTTP service or SQL database, an external layer injects the current user’s credentials and evaluates that interaction as the human who requested it. The topology below shows why a credential-free sandbox matters: sharing the agent does not mean sharing a stored production credential.

The architecture reduces to four constraints. Centralize context: keep one linked company-wide wiki instead of per-channel memories. Scope and attribute knowledge: enforce access per file and attach every accepted change to a person. Keep credentials outside the sandbox: never give a shared execution environment durable secrets. Mediate real interactions: proxy HTTP, SQL, and other tool access so the current user controls what the agent can do.

These controls turn a company brain into a system of delegated reads, reviewed writes, and user-bound actions. They are an architectural proposal, not proof that leaks have been eliminated under every adversarial condition: the recording supplies deployment experience and demonstrations but no measured leak rate, red-team results, or formal security evaluation. The practical value is that the design gives builders concrete places to enforce policy rather than asking the model to remember who should be allowed to know or do what.

Gopal closes by previewing PromptQL Tag as an implementation of this multiplayer approach with support for multiple model providers. The more durable ending is architectural: a shared AI becomes viable when shared conversation does not imply shared authority, and when useful organizational learning enters the brain only through a visible human decision.