Permission-Aware RAG for Enterprise Knowledge Systems

The Agentic Company Editorial Team — Tue, 15 Sep 2026 00:00:00 GMT

Executive Summary: Permission-aware RAG applies role-based access control filters during retrieval, so sensitive chunks never reach an unprivileged context window. The control belongs at the vector store, not in the prompt.

Key Takeaways:

Filter at retrieval time using security metadata so unauthorized chunks never enter the prompt.
GraphRAG needs permissions on both nodes and edges, not just documents.
Payload indexes keep metadata filters in the low-millisecond range.

Retrieval augmented generation collapses the distance between a question and every document behind it. In an enterprise that includes compensation tables, incident reports, and board decks. The failure mode is not a bad answer; it is a correct answer built from a document the caller was never allowed to read.

The control belongs at retrieval

The only durable place to enforce access is the retrieval step. If an unauthorized chunk reaches the prompt, every downstream control is a mitigation rather than a boundary. Attach a security predicate to the query and let the vector store do the filtering.

const results = await qdrant.search('knowledge', {
  vector: embedding,
  limit: 8,
  filter: {
    must: [
      { key: 'tenant_id', match: { value: tenantId } },
      { key: 'acl', match: { any: callerRoles } },
    ],
  },
});

Where teams get it wrong

Pattern	Failure mode	Fix
Post-filter in application code	Over-fetch then discard, leaks in logs	Filter inside the query
Prompt-level instructions	Model may ignore or summarize protected text	Enforce in retrieval
Per-document ACL only	Graph edges bypass document rules	Permission nodes and edges

GraphRAG needs dual-level permissions

Graph retrieval traverses relationships. A node may be visible while the edge that connects it encodes a sensitive relationship. Apply the same security predicate to node lookups and to edge traversals, and audit both.

MCP Server Architecture for Enterprise Tool Integration

The Agentic Company Editorial Team — Thu, 10 Sep 2026 00:00:00 GMT

Executive Summary: An enterprise MCP server is a typed, permissioned boundary between agents and internal systems. Design it around explicit tools, scoped credentials, and deterministic error contracts.

Key Takeaways:

Model each internal capability as a narrow, well-described tool rather than a generic executor.
Scope credentials per tool so a compromised agent cannot exceed its grant.
Return deterministic, typed errors so agents can recover instead of guessing.

Agents become useful when they can act, and acting means calling internal systems. The Model Context Protocol standardizes that boundary: a server advertises tools, an agent calls them, and the transport is uniform across providers. What the protocol does not decide is your security and error model. That is the architecture.

Tools, not a generic executor

The fastest way to create an unsafe agent is a single run_query tool. Model each capability as a narrow tool with a typed schema, so the agent's surface area is legible and reviewable.

server.tool(
  'get_invoice_status',
  { invoiceId: z.string().uuid() },
  async ({ invoiceId }, ctx) => {
    const invoice = await billing.getInvoice(invoiceId, ctx.auth.scopes);
    if (!invoice) return { error: 'not_found' as const };
    return { status: invoice.status, dueAt: invoice.dueAt };
  }
);

Credentials are per-tool

A shared service account turns every agent into a superuser. Issue scoped credentials per tool call, derived from the caller identity, and deny by default.

Errors are part of the interface

Agents plan around outcomes. Return typed, non-throwing errors such as not_found or rate_limited and document them, so the agent retries or escalates instead of fabricating a result.

Concern	Weak default	Enterprise contract
Tooling	One generic executor	Narrow typed tools
Auth	Shared service account	Per-call scoped credentials
Errors	Thrown exceptions	Typed, documented outcomes