Skip to content

Gate agent tools after external context with server-owned capabilities #6090

Description

@RaresKeY

Prerequisites

Area

Auth / Security

Problem or Motivation

Treating web, repository, document, email, memory, skill, integration, MCP, and tool-result content as untrusted model input is not itself an execution boundary. Once external content enters an agent run, a model can still request unknown or higher-impact tools in the same batch or on a later round unless the server carries explicit state and rechecks authority immediately before execution.

This is the first focused acceptance-criteria slice of #5815. It needs to establish the deterministic capability and external-context boundary without also absorbing process sandboxing, thread authority modes, exact approvals, or persistent cross-session provenance.

Proposed Solution

  • Define a server-owned capability registry that classifies agent tools by effects and execution needs, with unknown tools failing closed after untrusted external context enters the run.
  • Carry explicit external-context state through context assembly, model rounds, dispatch, and result folding instead of reconstructing authority from prompt text.
  • Update state as soon as a successful external result is available so later calls in the same batch and later model rounds are checked against it.
  • Block higher-impact execution, writes, private-data access, external side effects, and model-controlled egress before the underlying tool implementation runs unless a separate server-owned authorization path permits the exact action.
  • Add adversarial regression coverage for same-batch ordering, later rounds, model/provider paths, background or teacher continuations in scope, stored and live result folding, and unknown MCP tools.

Alternatives Considered

Keeping this only as one paragraph in the broad tracker makes completion and review state hard to track independently. Prompt-only hardening still asks the model to enforce the boundary. Process sandboxing alone does not cover non-process tools, and the later approval/provenance slices should build on this registry rather than replace it.

Prior Art / Related Issues

Parent tracker: #5815

Implemented by merged candidate PR #5817.

Related: #2605, #3709, #4754, and Discussion #335.

Are you willing to implement this?

Yes — I can open a PR

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions