← All posts
Governance

Permissions belong in the context layer, not the prompt

Mahari Kalau7 min readAug 2026
Permissions belong in the context layer, not the prompt

There is a tempting shortcut in agent design: let the model see everything, then filter the output. It is easier to build, it demos well, and it is structurally unsafe.

The post-filter problem

If a model has board-level revenue figures in its context and you filter the response afterwards, three things can still go wrong:

Output filtering is a content moderation technique applied to an access control problem. The two are not interchangeable.

If it reached the model, it left your boundary. What the user saw is a separate question.

Scopes as the enforcement point

The alternative is to resolve permissions before composition. When an agent asks a question, the sequence is:

  1. Identify the caller — user, agent, or workflow — via your existing identity provider
  2. Resolve which scope applies to that caller
  3. Match the query intent against knowledge items within that scope only
  4. Compose the context package from the permitted subset
  5. Send to the model

Restricted knowledge never enters step four. There is nothing to filter afterwards because there is nothing there.

# Onboarding assistant asks about revenue caller: agent:onboarding_bot scope: support_tier_1 candidate_items: 847 in_scope: 6 matched: product_tiers, faq_billing withheld: arr_formula (scope: executive) sent_to_model: 2 items, 340 tokens

Identity-aligned, never elevated

A principle we hold to: the agent's effective permissions never exceed those of the human it acts for. If a support rep cannot see churn cohorts in your BI tool, the agent answering on their behalf cannot see them either.

This sounds obvious and is routinely violated. Service accounts with broad warehouse access are the default in most integrations, and an agent inheriting one becomes a privilege escalation path with a chat interface.

Design rule: map scopes to the roles that already exist in your identity provider. If you find yourself creating a new permission model just for agents, you have probably built a way around your existing one.

The audit trail this produces

Enforcing at the context layer has a useful side effect: every delivery is a discrete, loggable event. Who asked, what scope resolved, which items were served, which were withheld, and when. That record is far more meaningful than a transcript of model outputs, because it describes the boundary rather than the conversation.

When a security review asks "could the support bot have seen the board figures", the answer is a query against that log, not an argument about prompt engineering.

Mahari Kalau

Mahari Kalau

Founder & CEO, OneClickBrain

Writes about context engineering, agent architecture, and the unglamorous parts of enterprise AI.

Keep reading

📄
Featured

Why RAG alone can't fix enterprise hallucinations

12 min read · Aug 2026
🧩
Architecture

Metadata-first: reading a stack without touching a row

9 min read · Aug 2026
🤖
Engineering

Serving context over MCP: what we got wrong first

10 min read · Jul 2026