Skip to main content
A coding agent is fixing a failing build. Reading an error log, editing a configuration file, and installing a missing dependency could all help. Uploading that same log to a public issue could expose a credential. The difference is not simply which tool the agent uses. It is whether the action serves the task, stays within the user’s authority, and handles the data appropriately. Silmaril calls this contextual understanding Omniscience. The name describes a design goal. A defense needs enough relevant context to judge what an action means in the application where it happens.

​
Start with the intended task

“Fix the build” gives the agent a goal. It does not give every instruction the agent encounters equal authority. Suppose an error report recommends a package and includes an installation command. That recommendation may be useful, mistaken, or deliberately misleading. The report is information to assess. It cannot expand the user’s authorization just by telling the agent what to do next. Installing a dependency can be a normal part of the repair. The important questions include where the package comes from, what it will change, and whether that change fits the task.

​
Four pieces of context

The task explains the intended result. Repairing a test configuration is different from changing the production service. The user helps establish authority. A developer’s permission to work in one repository does not necessarily extend to another team’s secrets or infrastructure. The data determines what could be exposed. A build log with compiler errors and a build log containing an access token need different handling, even when the upload command is identical. The preceding actions explain how the agent reached this point. A package recommendation copied from an untrusted report deserves a different assessment from a dependency already declared by the project. Together, these details connect a proposed action to its likely consequences. They help reveal when an apparently helpful step has drifted away from the intended work.

​
Connect context to a decision

This principle depends on what an integration can observe. A classification request, gateway, and agent plugin can expose different information and cover different parts of a workflow. Check the relevant integration guide rather than assuming that the defense sees the entire application. Independent enforcement explains where this decision belongs. Learning your application explains how its context stays relevant as workflows change. For the broader argument behind all three principles, read The Vital Trifecta.