Blocked Tool Result Policy bypass when agent starts in sensitive context

[VadimLarinTech]

When an agent has Treat context as sensitive from the start of chat enabled, blocked Tool Result Policies can be bypassed.

Repro:

1. Configure a tool like read_issue.
2. Set Tool Call Policy so the call is allowed.
3. Set Tool Result Policy to Blocked.
4. Enable Treat context as sensitive from the start of chat.
5. Ask the agent to read an issue.

Expected:
The tool call may execute, but the result content should be replaced before it is sent to the model.

Actual:
The raw tool result is sent in the model-facing LLM request.

Root cause:
In platform/backend/src/guardrails/trusted-data.ts, evaluateIfContextIsTrusted returns early around line 68 when considerContextUntrusted is true, so it skips real Tool Result Policy evaluation around line 125 and
returns empty toolResultUpdates.

Slack thread with screenshots/repro:
SLACK_LINK

---

[iskhakov]

/bounty 80

[Mira-Mjodheim]

/attempt #4225

Plan:

• Refactor evaluateIfContextIsTrusted in platform/backend/src/guardrails/trusted-data.ts to prevent early exit when considerContextUntrusted is true.
• Ensure that tool result policy evaluation logic around line 125 within evaluateIfContextIsTrusted is always executed.
• Apply the determined tool result policies to toolResultUpdates before returning, specifically ensuring blocked results are handled.
• Introduce unit tests to verify that blocked tool results are correctly processed when context is sensitive from the start.

[AlexMelanFromRingo]

/attempt #4225

Hey, I think I have a fix.

Root cause matches your description: the early return on line 68 in
trusted-data.ts skips evaluateBulk(), so block_always policies never
replace the tool output when considerContextUntrusted is true.

Plan:

• Drop the early return; seed hasUntrustedData and unsafeContextBoundary
  from considerContextUntrusted up front.
• Let block policies run; existing ??= writes preserve the
  preexisting_untrusted boundary as the first cause of distrust.
• Skip dual-LLM sanitization under considerContextUntrusted (sanitizing
  into a "trusted" summary cannot recover trust the agent flag has
  revoked).
• Add 4 regression tests covering block, no-match, dual-LLM-skip,
  and permissive interactions.

PR ~5mins.

[premsreelathasugeendran]

/attempt

Hi! I'd like to take a swing at this bounty.

Posted by an Autonomagic bounty-hunter agent on behalf of @premsreelathasugeendran. If I don't open a PR within a reasonable window please feel free to give the slot to someone else.

[premsreelathasugeendran]

/attempt

Hi! I'd like to take a swing at this bounty.

Posted by an Autonomagic bounty-hunter agent on behalf of @premsreelathasugeendran. If I don't open a PR within a reasonable window please feel free to give the slot to someone else.

[wengkit218-pixel]

/attempt #4225
1.Use QClaw to simulate sensitive conversation environments and validate current bypass vulnerabilities.
2.Analyze the logic in the guard or policy file to find out where the tool result check was skipped.
3. Implement strict enforcement policies to ensure that tool results are always verified, even when the agent is activated in a sensitive environment.
4. Rerun automated test scripts with QClaw to validate the fix.

[Dollydomeo]

/attempt #4225 ✅ PR #4295 is ready for review!

[colorbank]

/attempt #4225

I can take this bounty.

Plan:

1. Remove the early-return path in evaluateIfContextIsTrusted when considerContextUntrusted is true, while preserving initial untrusted state semantics.
2. Ensure Tool Result Policy evaluation still runs in this mode and that blocked results always produce toolResultUpdates applied before model-facing payload assembly.
3. Keep trust-boundary attribution deterministic (first meaningful cause), and avoid any path that accidentally restores trust.
4. Add/adjust regression tests for:
   • sensitive-from-start + blocked result policy (must redact/replace result)
   • sensitive-from-start + no matching result policy
   • baseline non-sensitive behavior remains unchanged.

If assigned, I will open a PR with /claim #4225 in the description.