How we are building the governance and permission layer

The moment you put an AI agent into a revenue workflow, it stops being a tool you query and starts acting on behalf of a person. It reads that person's accounts, surfaces their signals, drafts their follow-ups, and answers questions in their name. A question you could ignore when the software just displayed rows now has to be answered on every single request. Does this agent see exactly what its operator is allowed to see, and when it reasons across the whole company to find a pattern, is it ever reaching data its operator was never supposed to touch?

These are not abstract questions. On a real revenue team they have concrete, uncomfortable versions. Can one rep's agent read the pipeline in another rep's accounts. Can it pull the quota conversation from a deal it was never on. Somewhere in the same graph sits a founder's inbox and a teammate's private thread, and the whole value of a shared understanding of the customer collapses the instant an agent can see something its operator could not. The context is only worth trusting when every fact it serves is scoped to what that user is actually authorized to see.

We built the context graph so an agent could act on one resolved, current picture of a customer instead of eight fragmented ones. This piece is about the layer that sits next to it and decides, for every fact in that picture, who is allowed to read it. We call it the governance and permission layer, and it runs before any answer is assembled.

Who sees what

Every fact in the graph has to answer two questions. Whether it belongs in the graph at all, and, once it is there, who is allowed to read it. The context-graph work answered a different question, which is whether a fact is true and current. Governance answers whose it is.

The answer is different for a person and for an agent, and different again for one rep versus another. A founder should see the whole book. A rep asking about an account they work should get everything on it. That same rep asking about an account a teammate owns should see that a conversation happened and when, and should not read the body of the teammate's email. An agent acting for that rep inherits exactly the rep's boundary, so it can never become a way around a permission the person does not have. One graph, many viewers, and a different visible slice for each of them.

One rule, two places

The hard part is that the same rule has to be true in two places that pull in opposite directions. At ingestion, where a fact enters the graph, and at read, where a viewer asks for it. Get it wrong at read and an agent leaks a private conversation. Get it wrong at ingestion and you throw away the signal the whole product exists to capture, because a message a rep is allowed to see is worth nothing if it never entered the graph in the first place. The rule also has to hold for two kinds of reader with one implementation, the person in the app and the agent acting for them, or the two drift and the agent becomes the hole. Our design keeps ingestion unconditional so no signal is ever lost, and puts the entire decision at read, in one place every read passes through.

Ownership at ingestion

The foundation of the whole layer is that ownership is not a field someone fills in later. It is computed from the data itself, the moment the data lands, and it is computed twice.

The first is account ownership, and we derive it from co-attendance. Every touch that comes in, an email through a connected mailbox, a LinkedIn message, a meeting captured by the notetaker, carries the rep whose channel it came through. We record that as a relationship_owner on the account, holding every member who has actually communicated with this person and marking the one who touched it most recently as the primary. Membership only ever grows, so it never flips a rep's access out from under them, and it produces the true picture of a relationship, that you and a teammate are both on the same account, without anyone assigning anything. This runs on every channel we ingest, so the "who owns this" question is answered by what actually happened rather than by a CRM field nobody updates.

The second is row ownership. Every observation is stamped at ingestion with the owner_user_id of the rep whose connected channel captured that specific message. Account ownership tells us whose relationship this is; row ownership tells us whose words these are. The read gate reads both.

The read rule

With ownership on the data, the read rule is small enough to state in one line, and it lives in one function every leak-critical read passes through. If you are on the account, you read everything on it, including a teammate's messages to the same person, because it is your relationship too and half a conversation is worse than a clean summary of all of it. If you are not on the account, you still see its shape, the stage, the facts, the signals, the meeting that happened and when, and the raw body of another rep's email or LinkedIn message is redacted. A workspace owner or admin sees everything. A system process with no viewer, the sync or the scorer, sees everything, because it is machinery rather than a person.

Because the rule is ownership-based and not role-based, even the founder does not read a teammate's private conversations on accounts they are not on. That is the point. The boundary follows the relationship, so it is the same whether the reader is a person in the app, a message in Slack, or the customer's own agent over the API. The agent calls the same serve path a person's session calls, carrying the operator's viewer, and it receives exactly what that person would receive.

The serve path

Every request runs the same path. We resolve the viewer from the caller, whether that is a login session or an API key acting as its owner, confirm the workspace the caller belongs to, and assemble the account, the claims, the timeline, and the fit. Then, before anything is returned, we apply that viewer's boundary, computing the accounts they are on and redacting other reps' message bodies everywhere else. The answer that leaves is the resolved picture the graph holds, narrowed to the slice this viewer is allowed to read.

The property that matters most is that the agent path and the human path are the same path. An agent does not get a privileged read of the graph and does not build its own private copy of a customer. It carries the operator's viewer through the same functions, which is what lets a team put an agent in front of their revenue data without it becoming the one actor in the building that can see everything.

Append-only and audited

The gate is only trustworthy because the record it reads from cannot be quietly rewritten. Every fact enters the graph as an append-only observation carrying its source and its date, and a database trigger refuses edits and deletes, so the evidence trail stays intact and the current picture can be rebuilt from the raw record at any time. The privileged actions that governance itself depends on, admin impersonation, account deletion, credential changes, are written to a dedicated audit log whose rows are made immutable by a trigger, so even the service that writes them cannot alter them after the fact. The people who work at the company are marked internal and kept out of the prospect graph entirely, so an agent asking which accounts to work never gets a teammate back as a lead.

Built into the graph

Governance fails when it is a settings panel bolted onto a finished product, because by then the data has already been pooled and the boundaries have to be reconstructed after the fact. We build it the other way. Ownership is a property of the graph, created with the data at ingestion and carried on every fact, and the decision to show or hide is made in one place on every read. That is what makes the answer safe to trust at machine speed, on a real book of business, whether a rep or an agent is asking.

A resolved picture of the customer is what makes an agent useful. A boundary that travels with every fact is what makes that agent safe. Both have to be true at once, and building them as one system, the context graph and the governance layer side by side, is how a revenue team gets an agent it can actually hand its pipeline to.