Why can’t one warning sentence secure an agent?

A procurement employee asks an agent to compare quotes. One document lists prices and terms, then instructs it to send an internal file elsewhere. The agent must read the quote, but its author cannot assign work. How do you preserve the first ability without granting the second?

Telling the model not to follow instructions in documents helps, but it is not an execution boundary. The model reads the quote in the same context where it chooses tools. A malicious sentence can look like a helpful note. The company cannot rely solely on the model spotting the difference.

A source is not an authority

ADR-0010 in agentic-organization describes layers rather than one classifier. It separates content origin from authority to act, then considers tool decisions, network access, and privileged commands. ADR-0003 qualifies their strength: a workstation plugin is easier to bypass than a server-side gate. Start by asking where each control runs.

The current workstation plugin tracks a specific form of provenance. After a session successfully uses one of its configured taint-source tools, including common web fetch and web search names, that session is marked as having seen untrusted content. Later tool calls report that status to the policy endpoint. The mark stays for the rest of the session: a web result encountered several steps ago may still influence the next decision. The implementation tracks a session, not individual sentences or message fragments. It cannot tell you exactly which line of a document shaped a particular call.

The default list covers web tools, not automatically every uploaded document or another agent’s message. Teams can extend it after identifying those input paths. If an input is not marked, a rule depending on the mark will not fire. Provenance tracking is not proof that every document is covered.

Ask at the moment of action

The policy engine contains a baseline rule for selected higher-risk tools when the provenance is untrusted. A proposed shell call, web fetch, file write, edit, or patch can receive an ask decision. This makes a useful distinction between using a quote to compare offers and allowing its contents to trigger a side effect. The decision is made on the tool call, not on whether the agent gave a plausible explanation for doing it.

The policy engine defaults to dry_run: a normal ask is visible but does not stop execution. Applying it requires enforce at the appropriate scope. An enforced ask in the workstation plugin aborts the call with a human-approval message; it does not open a complete approval workflow. Plan for that interruption.

The baseline rule is not immovable either. The engine evaluates ordered rules, with the last match deciding the effect. Organization rules can override the baseline, including by relaxing it. That flexibility helps with legitimate exceptions, but it also makes rule ordering a matter for testing. A broadly written permission can undo the intended result. A single classifier score would not solve that governance problem; it would simply move the decisive judgment to another place. Tracking context and checking an actual call gives operators something concrete to inspect, provided they inspect the rule set and mode together.

The network is another boundary, not the whole answer

The repository’s workstation sandbox puts its container on an internal-only network and routes permitted outbound traffic through a filtering proxy. An allowlist determines which hosts the proxy will accept. This gives teams another place to constrain an unintended outbound request even if an agent tries to make one. But an allowlist must be maintained as work changes; if it is too narrow, legitimate tasks fail. Nor does this container configuration automatically govern an employee who works outside the container.

ADR-0003 calls the local plugin and policy enforcement a soft control. An employee with sufficient access to their own workstation can remove a plugin or work around managed configuration. The sandbox reduces exposure within its container, not across the entire laptop. The same ADR warns against turning an architectural intention into a delivered guarantee: the audit collection path is currently best effort in places, not a promise that all agent activity stops when logging is unavailable. The plugin likewise defaults to allowing a call to continue when the policy or audit endpoint cannot be reached, unless a separate fail-closed setting is enabled.

The controls still matter. Instructions discourage misplaced trust; provenance informs tool decisions; policy mode determines whether decisions are applied; network rules constrain a specific deployment. None alone proves that data cannot leave.

Different departments, different moments of risk

In procurement, the suspicious text may arrive in a quote. In production, it might be tucked into a maintenance manual that an agent uses to prepare a shift note. Finance can encounter it in an invoice attachment, HR in an applicant’s file, and IT in a pasted incident report. These are examples for threat modeling, not prepackaged departmental policies shipped by the product. The question for each team is where outside text enters and which subsequent actions matter.

Comparing offers is not the same authority as changing a supplier record. Extracting a date from an invoice is not the same as preparing a payment instruction. Classifying an application is not the same as transferring personal data to another system. A provenance flag does not invent these boundaries for the organization. Someone must identify the relevant tools, destinations, approval responsibilities, and exceptions. Otherwise a generic rule can look reassuring while missing the action the business actually cares about.

A practical review starts with three inventories: sources the agent reads, tools the current plugin marks as bringing in untrusted content, and later calls that can change records or send information out. Walk through a few representative tasks and inspect decisions in dry_run. Then decide which scopes should actually use enforce, what a blocked ask means for the human workflow, and whether the egress allowlist covers necessary work without granting too much reach.

One important gap remains explicit in ADR-0010: scanning final responses and tool output for secrets or personal data is a later phase. Structural instructions and network controls do not silently supply that missing check. If a team needs it before deployment, the honest answer is to define and validate that additional boundary rather than write a stronger sentence in the prompt.

A guardrail is useful when its location and failure conditions are understood. ADR-0003 and ADR-0010 in agentic-organization offer a concrete way to examine those conditions without claiming perfect containment. Mapping the point where an outside document can influence a tool call is a better beginning for an organizational conversation than asking whether an agent is simply “secure.”

Verification note: This article was checked against ADR-0003 and ADR-0010 and the repository’s session taint, policy engine, workstation plugin, and sandbox implementation. Planned output scanning is distinguished from controls present in the code.