Role-Restricted AI Agent Tool Access

Problem/Feature Description

A fintech startup is building an AI-powered operations assistant using Spring AI. The assistant can call a suite of internal tools to help users do their work. However, not all tools should be available to all users — different staff roles have different capabilities:

• Regular users can search the company knowledge base and look up their own account details.
• Agents (automated service accounts and senior staff) can additionally run read-only database queries.
• Admins can additionally trigger deployments to production environments.

The engineering team wants to enforce these restrictions at the tool level, so that even if the AI model tries to invoke a tool on behalf of a low-privilege user, the call will be rejected by the framework before the tool logic runs. The team also wants the solution to be maintainable as new tools are added — groups of tools sharing the same role requirement should not require duplicating boilerplate security declarations.

The system should also maintain a role hierarchy so that admins inherit agent capabilities, and agents inherit user capabilities — without having to list every inherited role explicitly on every rule.

The chat endpoint must pass the authenticated user's identity and roles into the AI model's system context, so the model understands who it is assisting and what it is permitted to do. If a tool call is denied, the model should explain the access restriction to the user.

Output Specification

Produce the following Java source files:

• AgentTools.java — a Spring component with at least four @Tool-annotated methods protected at different role levels. At least one tool that returns user-owned data should ensure the caller can only retrieve their own records.
• SecurityConfig.java — includes the role hierarchy and method security configuration.
• ChatController.java — REST controller with a chat endpoint that wires authenticated user context into the ChatClient system prompt.

Include a DESIGN.md explaining which role can call which tool and why you structured the annotations as you did.