Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL
Read the talk
Securing a company brain without isolating its knowledge
Tanmai Gopal explains how linked company context, human-approved updates, and permissions applied at each interaction can support useful agents while limiting secret exposure and privilege escalation.
From a talk by Tanmai Gopal
At a glance
Ideas worth remembering
A companywide knowledge store can preserve reuse while limiting visibility through per-file scopes and user-specific checks on every read.
Agents can reduce contribution effort by proposing facts, organization, and scopes during work. Human approval and attribution retain responsibility for what becomes shared.
Increasing daily updates may reflect expanding useful capabilities plus continuing corrections. Gopal’s two-month observation remains preliminary and may eventually level out.
Resolved debugging discussions can capture better knowledge than initial observations: the prefix incident produced an intended rule and its production failure rationale.
Shared conversations should preserve individual tool authority. Gopal proposes credentials outside the sandbox, user-specific injection at HTTP and SQL boundaries, and access controlled by tool owners; the implementation details are only briefly covered.
Shared knowledge creates an access problem
Tanmai Gopal opens with a concrete failure scenario: an intern joins a company and asks its shared AI system questions that expose employees’ compensation. A company brain makes accumulated knowledge easier to use, but that convenience becomes a liability when the system gives a person information they should not have. He presents this fear of leaking company secrets as a major obstacle to deploying agents broadly.
His team’s background is the Hasura GraphQL engine and its data-access work, including deployments he reports at Apple, Meta, and JP Morgan. For the company-brain work, he describes a year of partnering with about 15 to 20 organizations. Their needs differ: AI-native companies prioritize getting something working; technology-forward companies such as Instacart want strong technology and tolerate some breakage; banks impose extensive security rules. These are reported deployment experiences, rather than evidence that every security risk has been eliminated.
Internally, the team models its own company brain as a wiki with about 5,000 interconnected pages. Gopal allows that shared knowledge could use other representations, including markdown files on GitHub or knowledge graphs. The important starting point is accumulated, connected context; the storage representation alone does not settle how that context should be shared securely.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A useful brain keeps getting taught
Gopal asks the audience what daily updates to a healthy company brain should look like: decline after an initial burst, fluctuate around a steady rate, or keep increasing. A declining curve could represent a familiar organizational pattern: someone scrapes Slack and email, assembles a shared skills repository, and then maintenance loses momentum. A fluctuating curve could reflect an agent accumulating memory while participation varies with people’s enthusiasm.
When he plotted his team’s history over two months, daily updates gently increased. His explanation is that useful behavior encourages people to teach the system more. They first teach it to query data, then to interpret results, then to act on those results, and later to perform A/B testing. Each capability also needs continuing correction because agent learning is imperfect. New capabilities therefore add maintenance activity on top of the existing correction rate.
This is an early observation, not a universal growth law. Gopal explicitly says the rate might eventually level out and resemble the steady, fluctuating option. His proposed health signal is nevertheless useful: look at whether people continue improving the system through use, rather than judging success only by the total amount of knowledge stored.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Shared context and shared execution
The first use case is an individual agent drawing on other people’s knowledge. For example, a customer emails a security questionnaire, and an employee asks their agent to use the company brain to answer it. The second is collaborative execution: several people work with a shared AI to investigate an incident, fetch logs, inspect code, raise a pull request, deploy to staging or production, and create an alert. The first shares knowledge across people; the second also puts actions into a shared interaction.
For this talk, Gopal defines a company brain as shared context in markdown files together with access-control rules for data and tools, supplied to a coding agent. The agent is a general problem solver that can write code to complete work. His simple example is a request to write a tweet: the agent could write a small script that calls an AI model, although returning the tweet directly would be sufficient for that particular task.
That definition determines the security surface. Context helps the agent decide what to do, while permissions govern the data and tools it can use. Gopal argues against beginning with a gigantic company knowledge graph and trying to secure it afterward. His dismissal of that approach is a design position in the talk; he does not provide a comparative evaluation establishing that every knowledge-graph approach fails.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Grow context through the people doing the work
Gopal rejects the idea that a centralized, two-year project can comprehensively capture the brain of a company such as JP Morgan, with roughly 100 years of history. His alternative distributes ownership: each person doing a piece of the company’s work builds and maintains the corresponding part of its shared context. The ambition remains companywide, but contributions originate with the people who understand the work.
He calls this growing a company brain. The system should let people serve their own needs and contribute their portion as they work, allowing the larger body of context to come together incrementally. This makes contribution design central: capturing knowledge must fit ordinary work closely enough that people actually do it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reusing security knowledge in an email
The concrete example is an email from Dave at StitchFix containing a screenshot of security-onboarding questions. Gopal describes the agent retrieving the email and answering the questions using the company brain, including information about the trust center and the company’s security arrangements. He then approves the draft and tells the agent to send it to Dave. The sequence connects retrieval, shared context, answer preparation, and an explicitly requested external action.
The architectural question is how those answers became available to his agent. He suggests that another person had previously worked on a similar questionnaire and captured useful knowledge as memory or a skill. That earlier contribution now needs to reach a different employee’s agent. The example demonstrates the intended reuse, but the exact history of those particular facts is not established: Gopal describes the earlier contribution as a presumed explanation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Why repositories and team memories fall short
The first obvious solution is to have everyone write shared skills on GitHub. Gopal’s objection is behavioral: a security or compliance employee who has just completed a large Excel questionnaire is unlikely to take on another task of preparing reusable instructions for an unknown future colleague. A repository can hold the knowledge, but its existence does not provide enough motivation or remove the effort of contributing.
The second solution is a team brain: a shared agent that saves memory automatically for a small group. This reduces explicit documentation work, and some audience members report using such a setup. Gopal’s objection is that the resulting knowledge remains isolated. Per-channel memory repeats the same problem: someone added to the channel may benefit, while someone working elsewhere cannot reuse its context. Automatic capture solves part of the contribution problem while leaving the companywide sharing problem intact.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
One wiki, scoped files, and proposed changes
The third option combines three choices. All context goes into one shared wiki of markdown files that can link to each other. Each file has scopes defining who can read and write it. Agents suggest memory additions rather than adding them automatically. A common knowledge store therefore does not imply common visibility: file-level scopes separate what different people may access within that store.
The agent proposes both what should be added and the scopes for the addition; a human accepts or rejects it. Gopal places this between the effort of writing a shared skill, opening a pull request, and getting it reviewed, and the uncertainty of letting an agent silently write memory. The contribution appears during the work itself. A person adding sensitive finance information checks that it has a finance scope; personal information receives a personal scope.
His interface example follows an email exchange in which a sales representative adds him to a call. After he helps answer the email, a small box presents proposed facts as bullets. He reviews whether those facts are correct and selects “add to wiki.” The agent handles the destination files and links, while he can choose scopes for each affected wiki page. This divides the work deliberately: the agent organizes the knowledge, and the person approves its substance and visibility.
A page about his email prioritization illustrates how ownership and access can apply to personal working context. Gopal leaves the particular interface and access-control system open, but keeps the core requirement fixed: an agent should suggest a change for a person to authorize. Approval still depends on that person correctly judging the facts and the intended audience.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Attribute changes and authorize every read
Gopal makes human attribution a rule for every accepted change. The record should identify the person responsible, rather than merely saying an AI agent added it. If compensation information becomes visible to everyone, a human name lets the organization trace the decision and take remedial action. Attribution provides accountability after a mistake; it does not make an incorrect sharing decision impossible.
Read access uses the requesting user’s claims each time the agent retrieves context. In his finance example, the agent can read finance material because the user has the finance claim and access to that part of the wiki. The check happens on every read. This ties retrieval authority to the person being served, so the shared agent’s ability to help many users does not itself grant each user access to all shared knowledge.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Collaborative debugging improves the knowledge
The collaborative case involves several people using shared context while holding different privilege levels. Gopal argues that these interactions can generate especially valuable company knowledge. His example begins with the wiki-learning system failing. The agent’s investigation initially lacks a useful skill, so a person directs it to an OpenTelemetry span name. That improves the investigation, but it remains slow.
The person inspects the code and finds the agent using a SQL LIKE query. They tell it to use equality instead. The revised query surfaces details, and further investigation identifies a line of code producing the error. The agent then proposes learnings: use equality rather than LIKE for this lookup, and recognize that a custom prefix on wiki page names can cause problems. The talk does not specify the query, schema, index, or measured latency, so this supports a correction for the demonstrated investigation rather than a general rule that LIKE is always inappropriate.
Another person joins and challenges the technical decision behind the failure. Their disagreement exposes an undocumented choice. As they investigate the root cause and decide to remove the troublesome prefix, the knowledge changes from a description of existing behavior into a rule with a reason: these pages should not have that prefix because it can cause production lookup issues. Capturing the first observation alone would preserve a problematic convention; capturing the resolved discussion preserves the intended behavior and the failure it avoids.
This is why Gopal values shared problem-solving conversations, such as Slack threads. The useful context includes the reasoning that emerges when people question a decision, establish its consequences, and agree on a correction. An agent can offer that knowledge for acceptance, but the quality comes from the substantive investigation and discussion.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep shared execution tied to individual authority
A shared agent creates a serious privilege-escalation risk if its authority spans everyone participating. An engineer may be allowed to prepare a pull request while another person has production-deployment authority. If either participant can use the same agent to exercise all available powers, the conversation bypasses that separation. Gopal emphasizes that banks may assign debugging, staging deployment, alert creation, and deployment to different people, even though keeping their work in one conversation helps preserve knowledge.
His proposed extension applies user-specific authority to tool execution as well as context retrieval. Credentials stay outside the sandbox. At the HTTP and SQL layers, the system injects the credentials of the user involved in the particular interaction, allowing the AI to act as that person. The boundary is between code running in the sandbox and the layer that supplies authority for access to real systems.
Gopal summarizes the execution design with two rules: keep credentials out of the cloud sandbox, and proxy or virtualize interactions with real data under user control. The person adding a tool controls who gets access to it. This places authorization at the point of interaction rather than treating participation in a shared session as permission to use every tool. He gives only a brief architectural account, leaving details such as how an interaction is bound to a particular user unexplained.
He closes by presenting the context and tool constraints as principles from which to derive the architecture. After inviting further discussion, announcing a product launch, and taking an audience photo, he adds that the approach supports multiple model families, including GLM and GPT. That closing claim separates the intended shared-agent design from dependence on one model provider, although the talk does not demonstrate how the integrations differ or how their behavior is validated.
Suggest correction
Read the complete timestamped transcript
- 0:01
[music]
- 0:12
All right. Um, everybody can see. Hey
- 0:15
everybody. Um, thank you for being here.
- 0:18
I'm going to talk about um
- 0:22
the fact that if you go ahead and build
- 0:23
a company brain, it will um likely leak
- 0:26
company secrets. um which is kind of the
- 0:28
big fear that we have about building a
- 0:30
company brain anyway, right? Which is
- 0:32
this case of like intern joins the
- 0:34
company and then suddenly gets like comp
- 0:35
details and everybody kind of situation,
- 0:37
right? You want to you want to guard
- 0:39
against that. Um this has kind of been I
- 0:41
guess pretty much the biggest thing
- 0:43
that's been holding us back from just
- 0:45
deploying openclaw and Hermes all over
- 0:48
the place, right? It's also kind of the
- 0:50
reason it's like this big opportunity
- 0:51
that Claude Tag had with it recent
- 0:53
launch a few days ago where like it was
- 0:55
going to be the company brain but then
- 0:56
everybody's like well it's not um it
- 0:59
doesn't look like it's going to be the
- 1:00
company brain right so I'm going to talk
- 1:01
about kind of what makes it challenging
- 1:03
so before we get into that let's let's
- 1:06
kind of understand and dissect this
- 1:07
company brain business a little bit
- 1:09
right um I'm Tan I'm the co founderql um
- 1:13
you can check promqql out um later but
- 1:16
uh the our background as a team building
- 1:18
This is we come from um the hustra graph
- 1:21
we're creators of the hassur graphql
- 1:23
engine which is very popular open source
- 1:25
project in the graphql space uh where we
- 1:27
solved a lot of data access problems um
- 1:30
we deployed everywhere from like apple
- 1:31
to meta to JP Morgan etc. uh and um and
- 1:35
that kind of gave us a lot of these this
- 1:36
grounding uh for uh and and you know
- 1:40
kind of like a lovehate relationship
- 1:42
with uh data and data security. Um,
- 1:46
all right. So,
- 1:49
I'm going to show you stuff that we've
- 1:50
been working on over the last year and
- 1:52
kind of what we've learned from that so
- 1:53
that you can kind of take that and
- 1:55
exercise that and try it out for
- 1:57
yourself. Um, and of course, at the end
- 1:59
of the talk, happy to kind of exchange
- 2:01
notes and see what works or what might
- 2:03
what might not work for you. Um, over
- 2:06
the last year, we've only partnered with
- 2:08
a small set of people who've exhibited
- 2:10
some kind of spike on scale. M so about
- 2:13
15 to 20 folks so far and now we're just
- 2:15
starting to open it up to other people
- 2:17
but over that course of time we've kind
- 2:20
of looked at three different types of
- 2:21
set of people with very different needs
- 2:22
right you have AI native companies that
- 2:24
are willing to just do whatever as long
- 2:26
as it works you have kind of tech
- 2:28
forward companies right folks like
- 2:29
Instacart who um like best of breed
- 2:32
technology right um so they'll move fast
- 2:34
they'll be tolerable to breaking things
- 2:36
but it just needs to be really really
- 2:38
good right and then you have fortune
- 2:40
banks uh who have like a me level
- 2:42
security. Uh, thank God that they do
- 2:44
because they're my bank. I definitely
- 2:46
don't want vibecoded AI agents running
- 2:48
inside a bank because that's where my
- 2:50
money is. Um, so they have a lot of
- 2:53
security rules. Uh, thank you so much.
- 2:55
Uh, but we're deployed in places like
- 2:56
those as well. Um, with kind of the
- 3:00
beginnings or like the frontal lobe of a
- 3:01
company brain, right? So, we'll kind of
- 3:03
talk about those kind of learnings. Our
- 3:05
own personal usage of kind of building
- 3:08
out our company brain. Um it kind of is
- 3:12
about 5,000 pages. So we model it as a
- 3:14
wiki. Uh you can model it however you
- 3:15
want. You can model it as a set of
- 3:16
markdown files on GitHub. You can put it
- 3:18
into a remember graph frag. Uh you can
- 3:21
model it in a you can model it in
- 3:22
knowledge in knowledge graphs. You can
- 3:24
do whatever you want. Um so you can you
- 3:26
can place it wherever you want. But like
- 3:27
it's about 5,000 interconnected pages
- 3:29
for us.
- 3:32
Question for you folks. So suppose you
- 3:34
had a company brain that was working. It
- 3:36
was working well. It was all set up
- 3:38
right. um there would be a kind of daily
- 3:41
number of updates that would happen to
- 3:42
this com to this company brain, right?
- 3:44
Because it was learning stuff from
- 3:45
everybody in the company, right? From
- 3:47
finance to HR to um your engineers to
- 3:51
everybody. So if you were to plot the
- 3:54
daily number of updates happening to the
- 3:56
company brain, what would it sort of
- 3:59
look like? Would it sort of look like a
- 4:03
roughly downward trend? Like all of
- 4:04
these are like random graphs, but would
- 4:06
you would it sort of like start and then
- 4:08
go down? Would it kind of be steady
- 4:10
going up and down as updates spike or
- 4:12
would it kind of steadily increase
- 4:14
upwards? Um so kind of think about like
- 4:17
what would the commit history to your
- 4:19
shared skills repo look like, right? How
- 4:21
many updates are happening to a healthy
- 4:24
company brain, right? Um every single
- 4:27
day, what does that trend look like? Um
- 4:29
anybody for option A?
- 4:31
Anybody thinks it's option A? Okay,
- 4:33
cool. Uh, option B.
- 4:37
Okay. Option C. Ah, that's nice. Um, and
- 4:41
and and so that's so when I kind of
- 4:43
plotted our thing, right, to see what a
- 4:45
healthy company brain looks like. Um, if
- 4:47
you look at number one, it's basically
- 4:50
saying we had a lot of enthusiasm. We
- 4:53
built the company brain on day one, day
- 4:56
two. somebody we gave somebody the task
- 4:57
and said build all the shared skills
- 4:59
repo scrape all the slack scrape all the
- 5:01
emails build it and we'll all use it and
- 5:03
then nobody cares right or you have a
- 5:06
system which is autolearning maybe you
- 5:07
have a Hermes that's deployed internally
- 5:09
something like that where it's kind of
- 5:10
steadily adding more and more comments
- 5:12
so it kind of goes up and down depending
- 5:13
on who has enthusiasm right um and then
- 5:16
when I plotted our history over just the
- 5:19
last uh two months and this is a little
- 5:21
bit outdated now this is what we got and
- 5:25
I was kind of shocked
- 5:26
I was like, why is it continuously
- 5:29
increasing? Like it's a gentle curve,
- 5:32
right? But why is it gently just going
- 5:33
up? Why is the number of updates per day
- 5:37
increasing? And that was fascinating for
- 5:39
me to see because what I realized was
- 5:41
that if you have a system that starts to
- 5:42
work, what happens is people start to
- 5:44
teach it a lot more. It's like saying if
- 5:47
I taught you the skill for quering data
- 5:50
then tomorrow I'm going to teach you the
- 5:52
skill for interpreting that data and
- 5:54
then day after tomorrow I'm going to
- 5:55
teach you the skill of how to take an
- 5:57
action based on that and then after that
- 5:58
I'm going to figure out how to do AB
- 6:00
testing based on so people like you
- 6:01
continuously add more but because
- 6:03
everything is an agent where no amount
- 6:05
of learning is perfect everything has
- 6:07
its own kind of steady rate as well
- 6:08
right so the rates kind of even your
- 6:10
steady rates kind of keep adding up and
- 6:12
that's what I started to notice in our
- 6:14
thing as well this is early. So, who
- 6:16
knows if it'll kind of peter out
- 6:17
eventually. Maybe it'll start to look
- 6:18
more like option B. But a healthy brain,
- 6:22
of course, the overall size keeps
- 6:23
increasing, but even your daily updates
- 6:26
per day kind of keep increasing as well.
- 6:28
So, that's a sign
- 6:30
of a good brain that you built, right? A
- 6:32
healthy brain that you built for your
- 6:34
company. Awesome. The use cases for
- 6:37
company brains, how we start to analyze
- 6:39
how we build a system that won't leak
- 6:41
secrets, right? So, two use cases.
- 6:44
The first use case is there is a company
- 6:47
brain. I want to use it in my AI agent
- 6:52
whatever to get work done, right? Um
- 6:55
I'll show you an example of that, right?
- 6:56
It's like I got an email with a security
- 6:58
questionnaire I need to answer from a
- 7:00
customer and I talk to my AI and I'm
- 7:01
like look up the company brain and help
- 7:03
me answer this security questionnaire.
- 7:05
Right? That's a totally valid use case
- 7:07
of a company brain. Second, very useful
- 7:09
use case, right? because it's other
- 7:10
people's knowledge that are that is
- 7:13
coming to me. Second use case of a
- 7:15
company brain is kind of similar to what
- 7:17
uh cloud tag is is a this idea of
- 7:20
multiplayer and if you've been putting
- 7:22
agents inside slack in places where
- 7:25
multiple people can interact with it
- 7:27
it's kind of being using using it as a
- 7:28
shared AI right to like get stiff stuff
- 7:31
done. Um, and an example of that could
- 7:34
be collaborative incident management,
- 7:36
right? So, for example, you want to say
- 7:38
like, hey, I want to fetch logs. I want
- 7:40
to investigate the there's an incident,
- 7:42
go fetch some logs, investigate the code
- 7:44
codebase, raise the PR, deploy to
- 7:46
staging, deploy to prod, set up an
- 7:47
alert, right? You want like multiple
- 7:49
people are doing things with the company
- 7:51
brain. So, those are kind of two use
- 7:52
cases of the company brain. One is kind
- 7:54
of this like shared collaborative
- 7:56
knowledge use case and one is like
- 7:57
shared AI use case itself, right? Both
- 8:00
of those have a huge um security kind of
- 8:05
problem, right? Um so
- 8:10
to start to secure it, let's kind of
- 8:13
define that a little bit more strongly,
- 8:15
right? So what exactly is a company
- 8:18
brain? And this is my definition of it,
- 8:19
right? It's shared context that you'd
- 8:22
put in a markdown that you'd put in a
- 8:23
set of markdown files, right? and its
- 8:27
access control rules for the different
- 8:29
data and tools that you want to access
- 8:31
as given to a coding agent.
- 8:34
So that's what I'm calling it for um
- 8:38
because I'm speaking so I can define
- 8:40
whatever I want. Um that's my
- 8:42
definition. So I'm not saying this is
- 8:43
knowledge that is pulled into an LLM
- 8:46
that will do tool calls, right? It is
- 8:49
not a AI that is doing general purpose
- 8:51
stuff. It is an AI that is a coding
- 8:53
agent that is solving whatever problem
- 8:56
you throw at it. Right? And similar to
- 8:57
the a little bit of the previous talk
- 8:59
that you folks might have heard which is
- 9:00
this idea of like can we just use a
- 9:02
coding agent to solve general problems.
- 9:04
It's that right? So in the most trivial
- 9:06
case if you say hey write me a tweet
- 9:09
you're writing a small script that's
- 9:10
making an AI call to write a small tweet
- 9:13
right you probably don't need to do
- 9:14
that. The AI itself can just like return
- 9:16
the tweet back to you but like
- 9:18
essentially claude code being used for
- 9:20
everything. Cloud co-work is the same
- 9:21
architecture. The codeex app is the same
- 9:23
architecture which is this realization
- 9:25
that you can use coding agents to solve
- 9:27
general purpose problems. So we're
- 9:28
building the brain for that. We're not
- 9:30
building gigantic knowledge graph
- 9:32
knowledge base for the company and then
- 9:33
trying to secure it that anyway it
- 9:35
doesn't hasn't worked won't work. Um,
- 9:39
so in terms of how we want to approach
- 9:41
designing the company brain, right?
- 9:45
Should we build a company brain?
- 9:50
So, if you're an enterprise and you're
- 9:52
paid to twiddle your thumbs, then you
- 9:55
like this idea of building a company
- 9:57
brain because you're like, "Yes, let me
- 9:58
take on a two-year project and I will
- 10:00
build the company brain for JP Morgan."
- 10:02
That's not going to happen. You can't
- 10:04
build a company brain for an
- 10:05
organization that's like 100 years old,
- 10:06
right? you can barely build it for your
- 10:08
own family, right? Which might just be
- 10:11
months or years old, right? So, so the
- 10:13
idea and the way that we want to build a
- 10:15
company brain is we want each person who
- 10:17
does a little bit of the work in the
- 10:18
company to own and build their part of
- 10:21
the company brain, right? That's the way
- 10:24
we should build it. So, that's kind of
- 10:26
constraint number two that I'm putting.
- 10:28
One was the definition of the company
- 10:29
brain and second is how the approach
- 10:30
that we want to take for how a company
- 10:32
brain is built.
- 10:35
I like kind of this way of phrasing it,
- 10:36
which is that we're going to grow a
- 10:38
company brain. We're not going to build
- 10:40
one, right? We're going to like let it
- 10:43
let it come together. The system needs
- 10:44
to come together otherwise it'll it'll
- 10:46
it's not it's not possible to build. All
- 10:47
right. Um
- 10:51
broadly, we want to let each person
- 10:52
self-s serve their bit of the company
- 10:54
brain. Um and so these are kind of like
- 10:56
the various steps that you want to
- 10:57
follow. I'll come back to this in more
- 10:59
detail if we have time. But let's start
- 11:01
with a particular use case, right? So in
- 11:04
this particular use case, what I have is
- 11:06
this kind of situation where
- 11:09
this is kind of the tangible example I
- 11:11
want to take for you folks. Um I got an
- 11:12
email just a security questionnaire
- 11:14
example, right? Hey, I got an email from
- 11:17
Dave at StitchFix. Um and that has a
- 11:19
bunch of questions I want to answer,
- 11:20
right? So it pulls up my email. It says
- 11:23
the email has a screenshot of their
- 11:25
security onboarding and then it starts
- 11:27
to kind of answer those questions,
- 11:29
right? Um I have no idea how it knew. I
- 11:32
was kind of very surprised to see that
- 11:34
it answered all of the questions on
- 11:35
like, hey, this is our trust center.
- 11:37
This is how our security stuff looks.
- 11:39
Um, they have a gateway, right? It does
- 11:41
something. All of this is kind of coming
- 11:43
from the company brain, right? Which is
- 11:46
the answer to that. And then kind of go
- 11:47
ahead and I'm like, hey, just go ahead
- 11:50
and send this. I like this draft. Go
- 11:52
ahead and send this draft to Dave,
- 11:53
right? And then goes and sends that
- 11:55
email. Really simple example of what I
- 11:56
want to do. Now, the challenge here,
- 12:00
right? And the issue is that how do we
- 12:03
build a system right which somebody else
- 12:07
can contribute to
- 12:09
that a third person kind of uses
- 12:13
how did this knowledge about what our
- 12:15
security thing is come in presumably
- 12:19
somebody else had been working on the
- 12:20
same security questionnaire right so
- 12:22
they had let's say a Hermes agent or
- 12:24
whatever they were working on it you
- 12:26
autosaved some memory maybe somebody
- 12:27
wrote down a skill somehow that piece
- 12:30
piece has to come to my AI agent. How
- 12:33
are we going to make that possible right
- 12:35
now? Um let's try obvious thing uh
- 12:38
number one right which is that everybody
- 12:40
writes shared skills for each other on
- 12:42
GitHub. So the first time the security
- 12:43
questionnaire was answered by your
- 12:46
security person everybody visualize like
- 12:48
your security and compliance person in
- 12:49
your head right now. Imagine that they
- 12:53
after answering the questionnaire, it
- 12:55
sucks to answer questionnaires. After
- 12:57
answering this gigantic Excel sheet of a
- 12:59
of a questionnaire, they then went to
- 13:01
GitHub and updated a shared skill,
- 13:04
right? Many of you are fortunate to work
- 13:07
with people who are modeled after our
- 13:10
Lord and Savior Christ, who are so nice,
- 13:12
who will go and update shared skills in
- 13:15
a GitHub repo, right? Most people will
- 13:18
not. Nobody is going to write skills for
- 13:21
another person in GitHub like that is
- 13:24
not that is not something that is
- 13:26
natural to us right in the dayto-day of
- 13:29
doing work we don't suddenly decide that
- 13:31
ooh this might be really useful for
- 13:34
somebody else I don't even know I'm not
- 13:37
connected to in this situation in the
- 13:39
future not happening I can barely get it
- 13:41
to like curate my own memory and my
- 13:43
context I do not have the time to send
- 13:45
it to somebody else um to write it down
- 13:48
for somebody
- 13:49
[snorts]
- 13:49
Second, instead of having a company
- 13:52
brain, why don't you do a team brain?
- 13:53
Why don't you all just use one shared?
- 13:55
Why doesn't the security team kind of
- 13:57
use one more
- 14:00
shared silo where you can do this,
- 14:01
right? So, build an agent and have it
- 14:02
kind of save to memory itself, right?
- 14:05
Um, and that's kind of the architecture
- 14:06
that I I'm guessing a lot of you folks
- 14:07
have with maybe something like a Hermes
- 14:09
added to Slack. Does anybody have kind
- 14:11
of a team team brain situation going
- 14:13
where you have an AI that multiple
- 14:15
people use that autosaves memory and
- 14:17
auto adds context? Does anybody have
- 14:18
kind of like a skill that does that
- 14:20
already just for a small team? One.
- 14:23
Anybody else? Okay. Okay. A few of you
- 14:25
have that. That's cool. Um this is nice
- 14:27
but the problem is it's still not a
- 14:29
company brain because it's still
- 14:30
isolated, right? So it's like one more
- 14:33
silo, right? Like for example um if this
- 14:35
gets like with claw tag um it it has a
- 14:39
per channel memory right so in every
- 14:41
channel it gets saved but now it's
- 14:44
another silo in that one channel right
- 14:46
so now it's again locked into one place
- 14:49
that can't be used anywhere else so if
- 14:50
somebody got added to that channel it
- 14:52
would work but otherwise it wouldn't
- 14:53
work right um and so
- 14:57
this is the third option
- 14:59
the third option is saying all context
- 15:02
text goes into a single shared wiki. A
- 15:06
wiki is a set of markdown files and
- 15:07
markdown files can link to each other.
- 15:08
So imagine a gigantic folder. The folder
- 15:11
has lots of markdown files, right? And
- 15:14
markdown files can link to each other.
- 15:16
So all all context instead of saving it
- 15:19
inside a folder, siloing it, you put it
- 15:22
in a markdown file, the equivalent of a
- 15:24
markdown file, and you let it link with
- 15:27
each other.
- 15:28
The second thing that you do is you
- 15:30
allow each file to have scopes on who
- 15:33
can have readwrite access to that file.
- 15:38
The third thing that you do which is the
- 15:40
most important,
- 15:42
you don't let the agent auto add the
- 15:45
memory.
- 15:49
You don't let it auto add because if it
- 15:51
auto adds,
- 15:53
you have no idea what happened, right?
- 15:55
You can't
- 15:57
the we we're back to kind of the same
- 15:59
world where some stuff is getting added
- 16:00
and as long as you're in that agent's
- 16:02
memory, you're lucky, right? So, the
- 16:05
third thing that you do is instead of
- 16:06
letting the agent auto add, do something
- 16:09
that allows your agent to suggest what
- 16:13
is added with what scopes
- 16:16
and then have the human
- 16:19
accept or reject.
- 16:21
So it's not as heavy as GitHub where I
- 16:25
have to go and write this update a
- 16:27
shared skill do a PR review and then get
- 16:29
it merged but it's also not as yolo as
- 16:33
the memory just kind of being
- 16:34
autowritten by the agent right it's kind
- 16:37
of the sweet spot where while you are
- 16:39
working you pop it up suggest the right
- 16:43
scopes and let somebody add it so now
- 16:45
what happens is with this very simple
- 16:47
addition right you are able to let
- 16:51
people add to a gigantic wiki, but you
- 16:54
let that person take on responsibility
- 16:56
for what they can see or not. So, if I'm
- 16:58
adding something to the finance wiki, I
- 16:59
want to make sure I'm adding something
- 17:01
that's sensitive, I want to make sure it
- 17:02
has a finance scope. If I'm adding
- 17:04
something that's personal, I want to
- 17:05
make sure that that's personal scope.
- 17:06
Let me show you an example UX of what
- 17:08
that might look like. This is what we
- 17:09
do.
- 17:25
This was a recent email that I got um
- 17:30
from one of our sales reps adding me
- 17:32
onto a call. I looked at that email,
- 17:34
helped answer it, and then
- 17:37
I got a little box that suggested a
- 17:39
bunch of bullets that told me what it's
- 17:41
going to add, right? And when I hit add
- 17:44
to wiki and and so now it's much easier
- 17:46
for me to review what is getting added.
- 17:47
I don't care I don't care if it gets
- 17:50
added into this markdown file, that
- 17:52
markdown file, what links that the agent
- 17:54
takes care of. What I care about is are
- 17:56
these facts correct?
- 17:58
If these facts are correct, I'm going to
- 18:00
hit add to wiki and I'm going to be
- 18:01
done, right? And and during the time of
- 18:04
add to wiki, I can choose what scopes
- 18:05
need to be added per wiki page or not.
- 18:08
Right? So each wiki page itself can get
- 18:11
a certain set of scopes that you want to
- 18:12
decide who gets access to what for
- 18:14
example right so for example my email
- 18:17
this is the wiki page that I have for my
- 18:18
emails and how my emails are prioritized
- 18:20
and I can now decide who gets access to
- 18:22
this who are the owners for this and
- 18:24
what the artback for this is. So
- 18:25
whatever the system looks like is up to
- 18:27
you folks but the core idea is that you
- 18:30
want to get the agent to suggest a
- 18:32
change instead of doing the change. All
- 18:34
right. So, two rules. One, make sure
- 18:37
that everything goes into one
- 18:38
companywide wiki. Don't back down from
- 18:40
this rule. Second, make sure that like
- 18:43
as a part of that, every change is
- 18:45
backed by a human's name. Nothing should
- 18:48
be allowed inside the wiki that is
- 18:50
Claude added this or like your AI agent
- 18:53
added this or Hermes added this. No,
- 18:55
Tanme added this. that that name needs
- 18:57
to be there so that you can tie it back
- 18:59
to this is the person who screwed up and
- 19:02
like allowed everybody to see like
- 19:04
everybody's comp right and like whatever
- 19:07
now you can take remedial action uh
- 19:09
right whatever that is put them on a pip
- 19:11
um you didn't know how to edit a wiki so
- 19:13
so that is very very important and rule
- 19:15
number two once you decide that you can
- 19:18
then go to the second scope of like okay
- 19:19
you've got to make it easy for them to
- 19:20
do that which is where this business of
- 19:22
scopes come in where you want to scope
- 19:24
each file according to who gets access
- 19:26
you to build kind of a system around it.
- 19:27
This is what an architecture diagram of
- 19:29
that looks like where you have users um
- 19:32
users talk to the agent uh agent when
- 19:35
it's reading context uses that
- 19:37
particular user's claims right so if I
- 19:40
am reading something for solving a
- 19:42
finance problem it's using the finance
- 19:45
claim to read as me because I had access
- 19:47
to the finance wiki so I can read it and
- 19:50
that is done every single time right so
- 19:53
the agent is always using the user's
- 19:54
credential to read the right part of the
- 19:57
wiki. Um,
- 20:00
all right. I am um I'm fairly out of
- 20:03
time for the second use case. So, what
- 20:05
I'm going to do is give you a quick
- 20:06
flavor of the second use case, but
- 20:08
extend this idea. This is the daddy use
- 20:12
case. This is like this is the big daddy
- 20:14
use case. This is a really complicated
- 20:15
use case because now it's not just one
- 20:18
person answering an email. It's a bunch
- 20:21
of us using the shared context to solve
- 20:26
a problem with various different
- 20:28
escalation like privilege levels at the
- 20:30
same time, right? And these are kind of
- 20:32
the these are the these are the
- 20:34
interactions AI where the most amount of
- 20:36
company brain knowledge is created,
- 20:39
right? For example, I'm going to show
- 20:41
you a quick real life example of um what
- 20:45
it looks like for us. Um so this was a
- 20:47
case from an SR situation where um
- 20:51
somebody was like hey our autolearning
- 20:53
our wiki learning uh fairly meta was
- 20:56
failing it wasn't working what's going
- 20:58
on right and then it starts doing the
- 21:00
investigation and it sucks cuz it's it
- 21:02
didn't have a skill it failed so like
- 21:05
bro don't do this please use this open
- 21:07
telemetry span name used an open
- 21:08
telemetry span name it did a slightly
- 21:10
better job but was still really slow so
- 21:13
he looked at the code and he's like oh
- 21:15
you're using a like query. You're you're
- 21:17
a you're a dumbass. This is Opus 4.5. Um
- 21:20
we like like don't do this. Right? So
- 21:23
then he's like don't use a like query.
- 21:24
Use an equals to query. Right? And then
- 21:26
it does equals to query and it surfaces
- 21:28
some details and it and then he says oh
- 21:30
dig deeper into this and it says
- 21:32
whatever this is a line of code where
- 21:33
the error is coming from. Simple stuff
- 21:35
right? This is now where it surfaces
- 21:38
some knowledge and says aha I learned
- 21:41
that I should use equals to and not
- 21:42
like. Right? I learned that if you have
- 21:45
a custom prefix added to wiki page
- 21:47
names, it can cause issues, right? Um,
- 21:49
so it offers these learnings that you
- 21:51
can choose to accept.
- 21:53
So he kind of went dug in deeper um into
- 21:55
what the problem was. Somebody else
- 21:57
joined the conversation, right? And said
- 22:01
the technical decision that we've made
- 22:02
here is wrong. Why is this happening?
- 22:04
And now two people start to have an
- 22:06
argument, right? They have an argument
- 22:09
saying, hey, it should not be like this.
- 22:10
it should be like this but why is it
- 22:11
like this but it should be like this
- 22:12
right that argument creates knowledge
- 22:15
because the actual problem was that
- 22:16
somebody made a technical decision that
- 22:18
was not documented right when they
- 22:20
decide to fix that issue and they
- 22:22
observe that that is indeed the root
- 22:24
cause and they decide that this is the
- 22:25
way it's going to be fixed hey we should
- 22:27
remove this prefix that's causing a
- 22:29
problem whatever whatever the thing is
- 22:31
that creates the highest quality context
- 22:34
to be added to your brain because the
- 22:36
previous suggestion was to say uh pages
- 22:39
should not pages have a prefix. But the
- 22:41
fact that pages have a prefix is a
- 22:43
problem. Right? So now the thing that
- 22:45
you're documenting in the brain is pages
- 22:47
should not have a prefix. If they have a
- 22:49
prefix, it can cause lookup issues and
- 22:51
prod. This happens when multiple people
- 22:54
talk to each other, right? And solve
- 22:56
problems together. This is what happens
- 22:57
in a Slack thread. When two people talk
- 22:59
to each other and solve a problem, it
- 23:01
creates the highest quality context. But
- 23:04
and so so that's kind of what you want
- 23:05
here. But the challenge is that the priv
- 23:08
privilege escalation around this becomes
- 23:10
very very serious. If you if you're
- 23:13
building an agent that can do everything
- 23:17
surrounded by multiple people, that's
- 23:18
scary because the engineer was allowed
- 23:20
to do the PR work but now I can use the
- 23:23
same agent to deploy to prod. That's too
- 23:25
scary. I can't have a conversation where
- 23:27
I debug and
- 23:29
deploy securely, right? Especially if
- 23:33
you're in a bank, right? like the people
- 23:34
who are debugging, deploying to staging,
- 23:36
setting up an alert and deploying are
- 23:38
not the same. But but being the same has
- 23:40
a lot of value because that's where all
- 23:41
the knowledge is, right? And so that
- 23:44
kind of brings us to the second
- 23:45
architecture which I'm not going to get
- 23:46
into too much detail with, but think of
- 23:49
it as the same idea where user
- 23:51
credentials and claims were used to read
- 23:53
context. Instead of that, also use user
- 23:57
credentials, right, when the code is
- 24:00
executing tools. So never store
- 24:03
credentials in the sandbox.
- 24:05
Instead of that at the HTTP layer, at
- 24:08
the SQL layer, inject the user's
- 24:10
credentials, allowing the AI to behave
- 24:13
as the human in a particular
- 24:14
interaction, right? Um so there's
- 24:17
interesting details here. Um but that is
- 24:20
what allows a shared AI to work with
- 24:22
shared context, right? And those are
- 24:23
kind of the two um key pieces to work
- 24:26
with. So I would summarize and you'll
- 24:28
this architecture is not particularly
- 24:29
complicated, but it's very simple to
- 24:30
work back from these two rules. Do not
- 24:32
store credentials in the cloud sandbox.
- 24:34
And second,
- 24:36
virtualize all interactions with real
- 24:38
data. Proxy it, virtualize it, whatever
- 24:41
word you want to use. And let users
- 24:43
control them. So the user who adds a
- 24:45
particular tool should control who gets
- 24:47
access uh to that particular tool. So
- 24:50
you can derive this entire thing if you
- 24:52
just kind of follow these four
- 24:53
principles and work backwards from that.
- 24:54
there's only one architecture that is
- 24:56
possible that makes sense uh in how you
- 24:58
manage context and what constraints you
- 25:00
set up and how you manage tools and what
- 25:01
security rules you set up. Um that is my
- 25:05
time um and and so um happy to chat more
- 25:08
um after the talk um we have a booth as
- 25:10
well so happy to chat more through that
- 25:12
on what the nuances inside this
- 25:14
architecture are. I'm Tanme on Twitter.
- 25:16
Um we're called PromQL. Um do check us
- 25:19
out um at the end of the day um with the
- 25:23
AI engineering community. We're going to
- 25:25
do a product launch. Uh and so I would
- 25:28
love to share that folks share that with
- 25:30
everybody. I'm going to take a picture
- 25:32
with everybody on stage so that I can uh
- 25:34
I can share that. And so let me let me
- 25:37
do that while I'm here.
- 25:40
All right. Do folks want to say cheese?
- 25:43
[laughter]
- 25:46
Thank you so much. Um so watch out for
- 25:48
that. Um it's our approach to um claude
- 25:51
tag which is prompt tag which is very
- 25:52
similar to the ideas that we tag chatted
- 25:55
about here except that you're not stuck
- 25:57
to cloud you can use GLM and you can use
- 25:59
GPT and then soul comes out and we can
- 26:01
use that and have a lot of fun. Um so do
- 26:03
check that out and otherwise I'll see
- 26:05
you folks soon.