AI Agent Context Permissions vs Routing: Who Can Read and What Agents Receive

AI agent context permissions and routing control different paths to the same managed item. Permissions decide who can find it in the repository, read it on demand, or change it. Routing decides which agents receive its published or current content, or a Skill’s published metadata, in their context bundle. Teams need both decisions because an agent can require a rule during work without being allowed to edit the source of that rule.

The distinction also explains two common surprises: a reviewer can read an item that never appears in an agent’s bundle, and an agent can receive a routed item without having repository read access. Neither state is automatically a mistake. The question is whether it matches the work and the people responsible for that item.

TL;DR

For each context item, ask two questions separately: who may access or change it in the repository, and which agents should receive it automatically? Check the first with Resource roles and the second with direct or Group routes. A route is a delivery authorization, not an edit role. A repository role does not create a route. Review both when an agent misses a rule or receives something outside its scope.

AI agent context permissions vs routing: the four states

This matrix applies to one managed item and one agent. “Read access” means an authorized on-demand repository read. “Routed” means the item has an applicable route for that agent. A routed Knowledge or Memory entry includes content; a routed Skill lists published metadata and requires a separate package read.

Repository read access	Applicable route	What happens
Yes	Yes	The agent can read on demand and receives the routed entry in its bundle.
Yes	No	The agent can read on demand, but no entry appears through automatic routing.
No	Yes	The agent receives the routed entry, without gaining broader repository discovery or edit access.
No	No	No entry appears through automatic routing, and the agent cannot read it from the repository.

The third row is easy to miss. Routing independently authorizes delivery, so removing a repository Viewer role does not cancel an existing route. That matters when a team narrows access to a sensitive policy or working Memory. Check the route targets as well as repository grants.

The second row is useful for an agent that should look up a reference only when asked. Read access alone does not put that reference into every session. In Alignbase today, automatic routing is Always: an active routed entry appears in each current-context bundle. Task-based When relevant routing and Context Search are planned, so do not assume a read role creates task-based retrieval.

For a broader explanation of how routes are assigned, see the context routing guide.

What each control governs

Knowledge and Skills have repository roles for viewing, proposing, editing, publishing, and ownership. Memory has viewing, editing, and ownership roles because permitted updates are live and audited without a publication queue. Roles can come from direct grants or a Group. They govern repository operations; they do not decide which agents automatically receive an item.

A route targets an agent directly or a Group of agents. The current bundle uses published Knowledge, published Skill metadata, and current Memory. A routed Skill’s published package remains readable through read_skill even when the agent lacks general repository discovery access. That exception lets the agent use the Skill it was routed, without opening drafts, other versions, or unrelated Skills.

Routes deserve their own review because delivery can expose content to an agent that cannot browse the repository. The resource owner should check the content, version, audience, and expected lifetime before broadening a route. Repository permissions still control who may propose, edit, or publish that item afterward.

The ability to change a route is a third decision. In Alignbase, an admin can manage routes. A non-admin user needs access to the Resource and Context Manager on the target agent to change a direct agent route. Group routes are admin-only. A person who can edit a Knowledge item does not thereby gain authority to route it to every agent.

Work through a missing-rule case

Suppose a coding agent repeatedly skips a release check. The check exists in a published Skill, and the agent has Viewer access to the Skill. That only establishes that the agent could read it on demand. It does not establish that the Skill was routed or read during the run.

Inspect the failing run in this order:

1. Confirm the required check is present in the Skill’s published version, including any supporting file the agent would need.
2. Check direct and Group routes for the agent at the time of the run. A route added today cannot explain yesterday’s work.
3. Inspect the run’s compilation and response records for the exact Skill version. Check whether the published package was fetched if the workflow needed its full instructions.
4. Compare the agent’s tool calls and test output with the required check. A final message saying “done” is weaker than a test log.

If the Skill was not routed and the agent did not read it on demand, adding an appropriate route may address the gap. If its metadata was routed but the package was not fetched, check the integration and Skill invocation path. If the package was fetched, look for unclear wording, conflicting instructions, failed tools, or a workflow that did not require the agent to check test output. The instruction debugging guide covers those next steps.

For an earlier run, do not use today’s get_current_context response as historical evidence. Compilation shows what Alignbase assembled; response issuance shows what it sent. Acknowledgment and confirmed injection require separate evidence, and none of these alone proves model consumption or compliance. The point-in-time audit guide explains the evidence chain.

Work through an overexposure case

Suppose an operations Memory is routed to All Agents, but only the operations Group needs its current task state. Removing repository read access from unrelated agents will not stop automatic delivery. Narrow or remove the Group route through an authorized route manager, then check fresh bundles for an in-scope and an out-of-scope agent.

That change affects future bundles. It does not erase text from a running conversation or reverse an action taken with earlier context. Review active sessions and enforce any urgent action limit in the tool or target system. Preserve historical route and bundle evidence so an audit can still explain what earlier agents were issued.

For sensitive material, also check whether the Memory itself contains facts that belong in a restricted source system instead of agent context. Credentials and secrets should never enter managed context, a bundle, a log, or an audit record. The access control guide covers the wider identity and action checks beyond repository access and context delivery.

Where Alignbase fits

Alignbase keeps repository permissions and Always routes independent for governed Knowledge, Skills, and working Memory. That lets teams maintain one current source, give editors the access needed to update it, and deliver the right published or live version to connected agents. Audit records help reconstruct what was compiled and issued for a run, while action controls and outcome checks remain separate.

The Alignbase blog has related guides to context governance, routing, and point-in-time audit. When configuring an agent, use the four-state matrix to check both the repository role and the route before concluding it can or cannot receive a rule.