Choosing an Intranet Platform: Governance, Permissions and Internal Search

A new hire in your finance team searches the intranet for "parental leave policy" and the top result is a superseded 2021 draft that HR never archived, sitting one folder over from the version legal actually approved. Multiply that across benefits, security procedures, and travel rules, and the intranet stops being a source of truth and becomes a liability: people act on stale answers, and nobody can say who published what, when, or with whose sign-off.

The stakes are governance, not convenience. An intranet holds the content most tied to compliance, and the permissions, approvals, and audit trails it needs are the same controls you already run on your public website. Yet most intranet platforms treat search, permissions, and workflow as three disconnected systems that drift apart.

This guide reframes intranet selection around three questions a governance buyer should actually ask: can permissions follow the user (including any AI assistant), does internal search return the current, authorized answer, and is your audit trail a query rather than an archaeology project. Sanity, the Content Operating System for the enterprise, is used here to show what "governed by default" looks like in practice.

Why does intranet governance fail even when the platform has permissions?

Intranet governance fails because permissions, publishing, and search are usually three separate systems that share no source of truth. The access-control list lives in the platform, the approval process lives in email or a ticketing tool, and the search index is a nightly copy that lags behind both. Each is individually reasonable. Together they produce the failure mode every governance buyer knows: a document that was correctly restricted, correctly approved, and still surfaced to the wrong person because the search layer never learned about the change.

The deeper issue is that most intranet platforms model process as something that happens around the content rather than as data attached to it. When an editor submits a page for legal review, that fact lives in a workflow engine or a person's inbox, not in the content repository. So when compliance asks the obvious question, "what published in Q3 without legal review," there is no single place to query. Someone reconstructs it from screenshots, export files, and memory. That reconstruction cost is the real price of governance-as-afterthought, and it recurs on every audit.

The reframe for a buyer is to stop scoring intranet platforms on whether they have permissions and approvals (nearly all do) and start scoring them on whether those controls are unified. Do permissions, editorial state, and the search index read from one repository, so that a change in one is immediately true in the others? On this axis, Sanity models editorial process as data next to the content: with Workflows (Beta, opt-in), stages are defined in TypeScript, versioned and deployed like the rest of your code, so the governed process cannot drift from what is written down. That is the difference between a platform that has governance features and one where governance is structurally enforced.

How should permissions work when an AI assistant reads the intranet?

When an AI assistant reads the intranet, its permissions should equal the permissions of the person asking, no more and no less. This is the single most underbuilt control in production AI features. Vendor demos run the assistant as a service account, because demos have no users, and a service account can see everything. Ship that same pattern into an enterprise intranet and you have built a machine that will happily summarize the restructuring memo, the salary bands, or the unannounced layoff plan to anyone who types the right question.

The correct posture is auth-forwarded tools. The logged-in user's session token flows through the tool layer to the backend APIs, so the token never leaves the user's identity context. That single design choice buys you three things at once: retrieval is personalized, so the agent sees only what the user can see; action is personalized, so the agent does only what the user could do; and audit is traceable, because every action is logged against the user, not the model. The side benefit matters most for an RFP: the agent inherits your existing security model, the same row-level permissions, the same rate limits, and the same regulatory boundaries. You do not stand up "AI security" as a separate discipline. You make sure the token flows.

For a governance buyer, this reframes the AI question entirely. The right thing to verify is not "does the AI have guardrails" but "does the assistant run on behalf of a logged-in user or as a privileged system account." In Sanity, that model rests on Roles & Permissions, SSO, and Audit logs, the same primitives that govern human editors, extended to the assistant. An answer the user was never cleared to see is an answer the assistant structurally cannot retrieve.

What makes internal search return the current, authorized answer?

Internal search returns the right answer when it combines three retrieval layers rather than betting on one. Keyword search (BM25) catches literal matches, the exact policy name or SKU someone typed. Semantic ranking catches intent, the query phrased in words that never appear in the document. Structured predicates enforce the filters that have to hold: this market, this department, published, and not archived. Pure keyword search misses paraphrase; pure vector search cannot dig itself out of the empty-result problem or respect a hard permission boundary. You need all three.

The evidence that no single layer is enough is unusually clean. Anthropic's contextual retrieval research measured it directly: contextual embeddings cut top-20 retrieval failures by 35 percent, adding contextual BM25 took that to 49 percent, and adding reranking on top brought it to 67 percent. The shape of that improvement holds whether you read the paper closely or just notice that each layer removed failures the others left behind.

In Sanity, this is one query rather than three systems stitched together. In GROQ, structured predicates do the filtering that must hold, then a score pipeline blends a BM25 keyword match on the title (boosted, because title hits matter more) with a semantic similarity score across the document, ordered by relevance. One important discipline: text::semanticSimilarity() is valid only as an argument to score(). Semantic search ranks, it does not filter, so you narrow the candidate set with a filter first, then rank what is left. That ordering is what keeps a stale or restricted document from ranking its way into results it should never appear in. The authorization is not a post-filter bolted on after search; it is the first thing the query enforces.

Who keeps the search index fresh when policies change daily?

The search index goes stale the moment the content pipeline stops keeping it current, and on an intranet content changes constantly: policies get revised, org charts shift, procedures get deprecated after an incident. An index that re-embeds on a nightly batch means there is always a window where the intranet confidently serves the old answer. For a governance-sensitive topic like a security procedure or a return policy, that window is exactly where the risk lives.

Here is the honest part every buyer should hear: hybrid retrieval itself is not exotic. PostgreSQL can do it with pgvector and full-text search. Elasticsearch can. Algolia is built for the structured-plus-relevance case. Pinecone plus a metadata filter layer can. What none of them do for you is the content pipeline that keeps the index fresh, the re-embedding on change, the deletion handling so a retired policy actually disappears, and the backfill when your schema changes. With those tools you own and maintain that pipeline, and freshness becomes a permanent line item on your engineering roadmap.

Where Sanity differs is that retrieval is wired into the content backend rather than sitting beside it. Content Lake handles the freshness work as a property of the store, so when a document is published, revised, or deleted, the index reflects it rather than waiting for the next batch. The freshness problem stops being something a team maintains and starts being something the platform guarantees. For a governance buyer, that is not a convenience feature. It is the difference between an intranet that can prove it served the current, authorized version and one that can only hope it did.

How do you make an intranet audit a query instead of an investigation?

An intranet audit becomes a query when the editorial process leaves its trail in the same repository as the content, rather than scattered across a workflow tool, an email thread, and someone's export folder. The question a compliance reviewer actually asks is narrow and specific: what published without legal review, who approved the vendor-security page, which market saw the old data-handling policy and for how long. In most intranet estates, answering any one of those means reconstructing history from systems that were never designed to be joined.

Model the process as data and the audit collapses into a read. Because Sanity's Workflows (Beta, opt-in) record editorial stages next to the content, "what published without legal review" is one GROQ query. The process left a trail in the content repository, so there is nothing to reconstruct. Stages are defined in TypeScript and versioned like code, which means the audited process is the actual deployed process, not a policy document that describes an aspiration. Agents can move work through those stages too, a person submits a draft, an agent checks it against the style guide and either advances it or sends it back, while humans keep control at the gates that matter.

There is a related trap worth naming, because it undermines audits quietly: conflicting facts. The same policy appears in several places and the copies drift, a help centre says returns are accepted within 30 days while a product page says 45. Sanity Knowledge Bases (Beta, opt-in, enabled by an organization admin on the Apps page in Manage) detect that conflict during the index build and raise an issue showing the two claims side by side with their sources, so a human picks which is ground truth. An audit trail is only as trustworthy as the content underneath it, and surfacing contradictions before they ship is how you keep the trail honest.

Sanity vs the legacy governance stack: what actually differs

Legacy DXPs earned their place in regulated intranet estates, and an honest comparison starts there. Adobe Experience Manager brings genuinely deep approval flows and a vast partner ecosystem. Sitecore pairs mature governance with personalization. OpenText TeamSite has anchored compliance-heavy content operations for decades. None of these platforms is dead, and a governance buyer should respect the entrenched workflow depth they offer. The question is not whether they govern, it is how much cost and reimplementation effort each governed change carries, and whether the controls extend cleanly to AI-era retrieval.

The axes where a modern Content Operating System pulls ahead are specific and testable. First, audit as a query rather than an investigation, because process lives with the content. Second, permission-aware AI assist through token forwarding, so an assistant inherits the user's exact reach instead of running as a privileged service account. Third, a search index that Content Lake keeps fresh rather than a pipeline your team owns. Fourth, code-defined governance, workflows and schema versioned in source control, so a governed process can evolve without a package-manager migration or a professional-services engagement. Where the legacy suites win on the sheer depth of built-in approval tooling and marketing-suite integration, Sanity wins on adaptability, auditability, and the cost of every future change. Match the columns below against your own RFP and score the axes you will actually be audited on.