Academy

Cognitive Least Privilege: your agent should know only what it needs

Any information that doesn't serve the agent's job both lowers accuracy and widens the attack surface. Borrow least privilege from security and extend it to what an agent knows.

The Felesh team 4 min

One of the oldest principles in information security is giving a user only the access they need to do their job. This principle maps directly to an agent’s context window. We call this cognitive least privilege: an agent should hold only the information essential to its task, and nothing more.

Least privilege for a person and for an agentA table with two rows. A billing clerk may use invoices, payment runs and the customer ledger, and never sees payroll, HR files or source code. A notice agent holds order K-5521, a polite tone rule and the new date 14 Oct, and never sees other customers, the return window or the system map. The same rule, applied to what the agent knows.whomay usenever seesbilling clerkfiles and systemsinvoicespayment runscustomer ledgerpayrollHR filessource codenotice agentcontext windoworder K-5521tone: polite, briefnew date: 14 Octother customersreturn windowsystem mapsame rule, applied to what the agent knows
The rule is the one security already uses: each party touches what its job needs, and the agent's context window is one more thing to ration.

Why less is better

This restriction yields two structural advantages. First, accuracy: giving an agent irrelevant information creates noise. The model may weigh that irrelevant data in its reasoning, leading to errors or hallucinations. Second, security: the tighter the data in an agent’s context, the smaller the surface area for information to leak or be abused. The logic of security and the logic of accuracy converge.

One stray line changes the replyTwo contexts for the same task, a delay notice for order K-5521. The left context holds three lines: a polite tone, the order and its three-day delay, and the new date 14 Oct. Its reply states the delay and the new date. The right context holds the same three lines plus a stray line, return window 30 days. Its reply states the delay and the date, then adds an offer to return the item within 30 days that nobody asked for.only what the task needsplus one stray linetone: polite, 2 sentencesorder K-5521, 3 days latenew date: 14 Octtone: polite, 2 sentencesorder K-5521, 3 days latenew date: 14 Octreturn window: 30 daysreplyreplyK-5521 is 3 days late.New date: 14 Oct.K-5521 is 3 days late.New date: 14 Oct.Return it within 30 days?context nobody asked for can end up in the reply
The same task with and without one stray line: the extra line leaks into the reply, so the answer drifts off the task.

The boundary between self-knowledge and system-knowledge

A simple distinction helps enforce this: an agent should know about itself, not the system. “Self-knowledge” covers the agent’s identity, its responsibilities, and the rules governing its behaviour. This belongs in the prompt. “System-knowledge” is awareness of other agents, system topology, and data flow. This should be omitted.

Define the agent by the task it does, not by the position it holds in the system. Remove referential phrases like “upstream” and “downstream” from instructions. Ask for output without specifying a destination: instead of “send the result to such-and-such component,” write “return the result.”

A system line leaks, then is rewrittenA prompt for the delay-notice agent holds three self-knowledge lines: it writes delay notices, it names the order and the delay, it uses two sentences with no promises. Below them are three system lines: the intake agent sends orders, output goes to billing-router, the QA agent scores replies. A customer asks who sees my reply, and the agent answers that the QA agent scores it and then billing-router gets it. The system lines are then rewritten as the task: you receive an order, return the result, say only what you need. The reply now says it writes the notice for order K-5521 and has nothing else to add.agent promptcustomer chatself-knowledgeYou write delay notices.Name the order and delay.Two sentences, no promises.system-knowledgerewritten as the taskIntake agent sends orders.Output: billing-router.QA agent scores replies.You receive an order.Return the result.Say only what you need.Who sees my reply?agent replyThe QA agent scoresit, then it goes tobilling-router.I write the noticefor order K-5521.Nothing else to add.no line about the system, nothing to leak
A line about the system leaks when a customer asks for it; the same line rewritten as the task leaves nothing to leak.

In practice

Before adding information to the context, ask: does the agent strictly need this to do its job? If no, remove it. Then ask: could this information leak into user-facing output or reveal internal system details? If yes, remove it. Observing this structural discipline improves accuracy while keeping the attack surface small. A focused agent that has command only of its own task will almost always outperform a know-it-all agent.

Two questions for each candidate lineFour candidate lines for the delay-notice agent are checked in turn. Order K-5521, 3 days late: needed, cannot leak, kept. Return window, 30 days: not needed, removed. Delay cause, stock error: needed, but it could reveal an internal detail, removed. New date, 14 Oct: needed, cannot leak, kept. What is left in context is the order and the new date.candidate lineneeded?could leak?contextorder K-5521, 3 days latereturn window: 30 daysdelay cause: stock errornew date: 14 Octyesnokeptnonot askedremovedyesyesremovedyesnokeptleft in context: order K-5521, new date 14 Oct
Two questions, in order, decide every candidate line: does the task need it, and could it reach the user.