Delegated Authorization for Agents Constrained to Semantic Task-to-Scope Matching

An application's eligibility to access a tool does not mean that the tool is needed for every request. Broad or persistent grants can therefore give a delegated agent access unrelated to its current task. Conversely, an overly restrictive task matcher can deny tools needed to complete a legitimate workflow.

The paper studies this relevance decision inside a proposed authorization architecture. The empirical question is whether task and tool descriptions support useful matching decisions, including tasks that require several tools; it is distinct from checking the correctness of concrete tool arguments or a completed execution.

A delegated-authorization architecture that carries the original task through a trusted proxy to a task-aware authorization server.

Two semantic matching approaches: an embedding-based ideal-tool comparison and a direct language-model judgment of a task–tool pair.

The ASTRA task-generation and incorrect-match simulation pipeline, with evaluation on ASTRA and a cleaned Toucan subset.

The trusted proxy captures the user's prompt and context and conveys them to the agent and authorization infrastructure. Requests for delegated authority pass through this proxy. The authorization server combines the original task, requested tool descriptions, and applicable policy constraints; the design also proposes isolated authorization instances for individual applications.

SemSimM asks a trusted model to describe an ideal tool for the task, embeds that description and the available tools, and finds the closest match. It accepts the requested tool only when that tool is the selected match and similarity exceeds a calibrated threshold. This implementation targets single-tool matching.

LLM-ResM instead presents the task and the requested tool's name and description directly to a trusted language model, which returns a structured suitability decision. It does not require embedding the entire registry. The proposed infrastructure uses such decisions to constrain task-scoped grants, while the experiments test the matcher rather than a full token lifecycle.

ASTRA synthesizes tasks from discovered enterprise MCP tool definitions. Positive examples use the tools associated with a task; negative examples substitute tools from the same server or a different server. Toucan is filtered for description quality, language, duplicate tools, and sufficient alternatives before applying the same simulation.

Validation and test partitions separate tools and MCP servers. Validation calibrates the similarity threshold and prompts; held-out evaluation uses accuracy, precision, recall, and F1 to describe over- and under-scoping. Both matchers handle single-tool cases, while the reasoning matcher also handles tasks requiring two or three tools. This protocol measures matching decisions rather than end-to-end adversarial workflow resistance.