Most agent knowledge problems are not about retrieval quality. They are about scope.

An agent retrieves the wrong documents because it had access to the wrong collection. A support agent surfaces internal runbooks to a customer because there was no boundary between internal and external knowledge. A production agent uses test data because knowledge access was not scoped by environment.

Once agents start accessing real knowledge stores, scope becomes a production requirement.

Knowledge scope is not the same as prompt context

Prompt context is what you put in the system message. Knowledge scope is what the agent is allowed to access at runtime.

These are different concerns.

An agent might have instructions to “only use customer-facing documentation.” But if the runtime gives it access to internal knowledge sources, the agent can still retrieve sensitive information.

Scope must be enforced at the infrastructure layer, not in the prompt.

Scope needs to be explicit per run

Different runs need different knowledge access.

A customer support agent helping a specific customer should only access:

  • Documentation relevant to that customer’s product tier
  • Knowledge filtered to that customer’s account
  • Graph data scoped to that customer’s entities

An internal operations agent should access:

  • Internal runbooks and procedures
  • Cross-customer analytics
  • System-level graph knowledge

This is not something the agent should decide. It should be frozen at run creation.

sypho freezes knowledge scope at run time

When you create a run on sypho, you declare:

Vector collections — Which collections the agent can retrieve from

Graph namespaces — Which graph knowledge the agent can query

Permissions — Read-only or read-write access per source

Environment filters — Scope knowledge by customer, account, or deployment context

This scope is immutable for the lifetime of the run. The agent cannot escape it.

Why this matters for compliance and security

Knowledge access is a common compliance requirement.

You need to answer:

  • Which documents did this agent retrieve during this run?
  • Was the agent allowed to access this knowledge source?
  • Did the agent have permission to query sensitive data?
  • Can you prove the agent did not access out-of-scope information?

With scoped knowledge, the answer is always yes.

Every retrieval is logged. Every query is validated. Every access is traceable.

Multi-tenant agents need scoped knowledge

If your agents serve multiple customers, knowledge scope is not optional.

Each run should only access knowledge for the relevant customer:

  • Customer A’s agent cannot retrieve Customer B’s documents
  • Internal agents see cross-customer knowledge
  • External-facing agents see only public documentation

Without runtime enforcement, this is impossible to guarantee.

Scoped knowledge makes agent behavior reproducible

When you debug an agent failure, you need to know:

  • What knowledge was available during that run?
  • Which documents were retrieved?
  • What was in the graph namespace at the time?

If knowledge access is unbounded, reproducing behavior is guessing.

With scoped knowledge, you can replay the run with the exact same context.

sypho makes knowledge scope a deployment primitive

On sypho, knowledge scope is not a feature. It is how agents access data.

Every run declares:

knowledge:
  vector:
    - customer-docs: read
    - internal-runbooks: read
  graph:
    - customer-entities: read_write
scope:
  customer: customer_id_here
  environment: production

This scope is validated on every retrieval, every graph query, and every tool call that touches knowledge.

Need scoped, governed knowledge access for production agents? Join the sypho waitlist to get early access to knowledge management infrastructure.