Give every agent only the knowledge its job needs

  • Choose what each agent searches
  • Permissions apply on every request
  • Sensitive data stays out until approved
Get a demo
See how it works

Trusted by teams across leading enterprises

  • X-Chem
  • StrongDM
  • U.S. Air Force
  • Cengage
  • PLI

A knowledge scope is the set of company knowledge sources an agent can draw on

Least-privilege data access, through permission- and context-aware data set curation.

Why scope matters

How it works

Build one

Ship securely

Avoid duplication

FAQs

Click to jump to topic:

Less to search means better, faster, cheaper answers

Without a knowledge scope

The agent searches everything it can reach, on every request

With a knowledge scope

The agent searches only what the job needs, so it answers faster, better, and for less
  • Lower cost, quicker answers
    A fraction of the data to search means fewer tokens and faster responses.
  • Sharper answers
    Less noise in means more relevant, cited answers out.
  • Less risk
    Least privilege by default: no agent reaches more than its job, or its user, allows.
  • More control
    Sensitive data stays out unless its owner approves.
  • No upkeep
    New content that fits the scope joins on its own.

Three filters run on every request

The scope narrows the search, source-system access controls apply, and restricted data stays out, all before anything reaches the model. Here's the sales team's agent answering one question.

  1. Everything Atolio indexes
    every connected system
    4.2M
    permitted items
  2. The agent's knowledge scope
    Henderson opp, #deal-henderson, renewal emails
    1,073
    items the job needs
  3. What the person asking can open
    checked on every query
    912
    items this rep can see
  4. Restricted data held back
    sensitive by default
    −1
    until its owner approves
  5. What the agent receives
    ranked, right-sized, and cited
    9
    passages for this question

Whose access applies depends on how the agent runs

The third filter checks what the person asking can open. Here's who that is for each kind of agent.
How permissions work
  • Shared agent
    Any account exec can ask it
    Acts as
    Whoever asks, so each person gets answers from what they can open.
  • Personal workflow
    One engineer runs it
    Acts as
    The person who built it, with that person's access.
  • Autonomous agent
    Runs on a schedule
    Acts as
    Its own service account, with access your admins set.

Build a scope by describing the job

Works with all of your AI tools and agent builders:

Click to jump to topic:

Test it, restrict it, and see every request

The checks security and data owners ask for, from least privilege to oversharing, are built into how every scope works.

Agent operations
Security and sovereignty

Find it before you build it (again)

Every registered agent and its scope is listed in one directory, so teams can reuse what already works instead of building it twice.

Questions to ask about AI agent access control

Use these to compare any approach.

Does the scope hold documents, messages, tickets, and records, or only tables and definitions?

Atolio's answer

The content itself, across every connected system.

Are source permissions checked on every document, on every query?

Atolio's answer

Yes, not just on access to the scope itself.

Is sensitive data off-limits to every agent by default?

Atolio's answer

Yes, until its owner approves access for a specific agent.

Does new content join on its own, or does someone review each change?

Atolio's answer

It joins on its own when it fits the scope.

Where do the scope and its index run?

Atolio's answer

In your cloud or on-prem, including air-gapped.

Can any model and any AI tool use the scope?

Atolio's answer

Yes, through MCP or API, with the same rules in each.

Can you see what an agent would get before it ships?

Atolio's answer

Yes, with a live view of each request and its results.

FAQs

Knowledge Scope questions

A knowledge scope is a defined set of company information that an AI agent can draw on.

It's built from the sources Atolio already indexes, such as two SharePoint sites, one Slack channel, and Jira tickets with a given label. When the agent asks a question, Atolio searches only inside its scope, ranks the results, and returns cited context. New content that fits the scope joins on its own, so you set it once rather than maintaining a list of documents.

A scope works together with permissions. The agent still sees only what the identity it acts as can open, and restricted data stays out of every scope until its owner approves access. Because the agent searches a fraction of your company's data, it uses fewer tokens, answers faster, and returns less noise.

Agent authors build scopes themselves by describing what the agent does, with an assistant that proposes the right sources. Each registered agent and its scope appears in the agent directory, so other teams can reuse it or copy it instead of building the same thing again. Scopes are part of Atolio's sovereign context layer, so they run inside your own environment, next to the index they draw from.

A knowledge scope sets what an agent's job needs, while permissions set what its identity may open.

Permissions come from your source systems. They sync continuously from each source and are checked on every query, against direct, group, and nested-group memberships. They answer one question: is this identity allowed to see this item?

A knowledge scope answers a different question: does this agent need this item to do its job? An HR assistant's user may be able to open the sales pipeline, but the assistant has no reason to search it.

Atolio applies both on every request. The scope narrows the search to the sources the job needs, and the identity's permissions then remove anything that person or service account can't open. Restricted data sits outside every scope by default, even when the identity could see it.

A scope can only narrow what an agent sees. It never widens access beyond what permissions allow, so adding a scope never creates a new path to sensitive content. The result is an agent that sees less than its user, not more, which shrinks both the token bill and the exposure if something goes wrong.

Knowledge scopes curate the content agents search, while semantic layers and context catalogs define structured data.

A semantic layer or context catalog describes structured data: the definitions, metrics, joins, and approved queries an agent needs to query a warehouse correctly. That work matters, and it usually lives with the data team and the warehouse.

A knowledge scope covers the rest of what agents need: the documents, messages, tickets, and records spread across systems like SharePoint, Slack, Jira, Salesforce, and Gmail. It holds the content itself, not just descriptions of it, and Atolio checks source permissions on every document, on every query. Restricted data stays off-limits to every agent by default, until its owner approves. New content that fits a scope joins on its own, so nobody has to review and publish each change.

Scopes run inside your environment, in your cloud account or on-prem, including air-gapped deployments. Any model and any AI tool can use them through the Model Context Protocol (MCP) or an application programming interface (API). Many teams use both: the warehouse's own tools for tables and metrics, and Atolio for the knowledge that lives everywhere else.

A normal knowledge scope needs no approval; only access to restricted data needs an owner's sign-off.

Agent authors build and ship scopes themselves. They register the agent, describe what it does, and the assistant proposes the sources. They refine the scope, test it against real requests, and connect the agent. Because a scope can only narrow what an agent sees, never widen it, a normal scope doesn't create new risk that someone has to review.

Sensitive data is handled differently. Admins, or the data owners they delegate to, mark it as restricted, and every scope excludes it by default, even when the person running the agent could open it. If an agent needs restricted data to do its job, its author requests access. The data's owner approves or declines, and use is audited. The default answer for sensitive data is no, and access is a deliberate, visible decision.

This keeps security review from becoming the bottleneck for every new agent, while giving data owners clear control over the content that matters most. Admins can see every registered agent, its owner, and its scope in one place.

Restricted data is content marked off-limits to every agent until its owner approves access.

Admins, or the data owners they delegate to, decide what counts as restricted, such as board materials, security audit reports, HR records, or personal data. Once it's marked, it sits outside every knowledge scope, even when the person or service account an agent acts as could open it in the source system.

To get access, the agent's author requests it and explains why the agent needs it. The owner approves or declines. Approval adds that data to that one agent's scope, not to every agent's, and each use is recorded in the audit log.

Restriction works alongside source permissions rather than replacing them. Permissions still sync continuously from your source systems and are checked on every query, so restricted data an agent is approved for is still limited to what its identity can open.

The result is a short list of agents with a clear reason to touch your most sensitive content, and a record of each time they did. Your security team gets a control it can explain to auditors, and agent authors get a clear path to the data their agents genuinely need.

Yes, knowledge scopes reduce token costs, because each agent searches a fraction of your data.

Without a scope, an agent searches everything it can reach on every request. It pulls back results from systems that have nothing to do with the task, and the model reads through that noise, paying for every token. A knowledge scope narrows the search to the sources the job needs before retrieval starts, so fewer, more relevant results reach the model. That means fewer tokens per answer, faster responses, and fewer retries caused by off-target context.

Scopes add to the savings Atolio's architecture already delivers. Retrieving once from a single permission-aware index, and ranking across every system in one pass, cuts token usage by up to 80%.

Scopes also cut costs outside the token bill. Reusing an existing agent's scope instead of building a duplicate avoids paying twice for the same work, and a smaller exposure surface means fewer access reviews. Atolio's cost dashboard shows spend by user, agent, and model, so you can see the effect of each scope directly and compare agents doing similar jobs.

Yes, knowledge scopes work with Copilot Studio, Claude, and any other AI tool or agent.

Each registered agent connects to Atolio through the Model Context Protocol (MCP) or an application programming interface (API), and its requests are filtered by its knowledge scope. That covers agents built in Microsoft Copilot Studio, Claude, ChatGPT, Gemini, Python scripts, and other frameworks.

The scope lives in Atolio, not in each tool, so the same rules apply wherever the agent runs, and you don't rebuild access logic for every platform. If you move an agent from one tool to another, or switch the model behind it, its scope and its permissions come with it.

Authors can register an agent on a developer page or over MCP, which also lets them create agents and scopes in code. They can test the scope with a live view of requests and results before connecting it. Every request is logged in one audit trail, whichever tool sent it. Because the scope and the index run inside your environment, the AI tool receives only the scoped, permission-checked context for each request, under your agreement with that tool's vendor.

Keep reading

See a knowledge scope built live

Book a demo