How should teams design tools for LLMs that act on behalf of users?

Teams should design for the job the model needs to complete, not mirror an existing API one to one. That means choosing tool names, arguments, and response shapes around the task, then adding guardrails that leave enough freedom for success while preventing common failure modes. The goal is reliable action, not generic integration.

Design tools around the action, not the interface

Tools for LLMs should be shaped by the work the model is trying to complete, not by a legacy API contract copied one field at a time. That usually means choosing names, inputs, and outputs that make the intended task obvious to the model, while still keeping the function narrow enough to be predictable. The best tool is the one the model can use safely and successfully with minimal interpretation.

A task-first design also reduces brittle prompting. When a tool mirrors an existing backend API too closely, it can expose internal implementation details that are irrelevant to the model and make the action harder to select correctly. By contrast, a tool that reflects the user outcome usually improves routing, reduces argument confusion, and makes it easier to add policy checks around the exact action being requested.

Good tool design treats the model as an operator with bounded intent, not as a developer reading an SDK. That means exposing only the choices the model genuinely needs, using defaults where they are safe, and avoiding low-level options that invite error or overreach. If the model must chain steps, each step should be explicit and meaningful to the task rather than a mechanical wrapper around the underlying system.

Boundaries, guardrails, and failure modes

The hard part is not just making the tool usable, but making misuse difficult. LLM-facing tools should constrain side effects, validate inputs, and return responses that let the model recover when something fails. A narrow, well-typed interface is often more reliable than a rich one, because it gives the model fewer ways to drift into unsafe or ambiguous action.

Tool responses should tell the model what happened in business terms, not dump raw internals unless that detail is truly needed. Clear success, partial failure, and retry signals help the model choose the next action without guessing. In practice, the most common failure modes are overbroad permissions, unclear argument semantics, and responses that are too verbose or too technical for the model to use well.

Where a tool can act on behalf of a user, the design should make authority explicit. The model should not be forced to infer whether it is operating as the user, for the user, or with a delegated scope. That distinction matters because delegation, token exchange, and session scoping change the safe shape of the tool and the consequences of a mistake. For an identity-centric view of that problem, Agentic AI Identity Guide is a useful reference point, and the delegation mechanics are well covered by RFC 8693: OAuth 2.0 Token Exchange.

What good looks like in practice

Well-designed tools usually have a small number of obvious actions, stable schemas, and response shapes that support decision-making instead of forcing interpretation. They also separate read, write, and high-impact actions so the model can be given more freedom for low-risk tasks and tighter control for irreversible ones. That separation is especially important when the tool can create, delete, pay, publish, or otherwise change external state.

The model should receive enough context to succeed, but not so much that it can improvise beyond its mandate. A good pattern is to provide task-specific parameters, clearly scoped defaults, and a way to request clarification when the user intent is underspecified. For agentic systems, this design approach aligns with broader guidance on tool misuse and identity abuse in OWASP Agentic AI Top 10 and with practical threat modeling in MITRE ATLAS adversarial AI threat matrix.

Teams should also design for observability. Every meaningful tool call should be attributable, reviewable, and easy to correlate with the user request that caused it. If a tool cannot explain what it did in a way an operator can audit later, the interface is usually too loose for production use.

Risk and Threat Considerations

Tools that act on behalf of users can turn a small prompting mistake into a real-world action, so the main risk is not just bad output, it is delegated misuse at scale. If the interface is too permissive, an attacker or a confused model can trigger actions beyond the user’s intent, reuse the wrong authority, or amplify a single compromised session into broader damage.

Failure mechanism: Overbroad tool scopes, ambiguous arguments, and weak response design let the model select or repeat actions it should not take. When delegation is implicit instead of explicit, the system can also blur user authority with agent authority and make misuse harder to detect.

Impact: The result can be unauthorized state change, data exposure, privilege abuse, or automation that persists after the original user intent has ended. In agentic systems, those errors can cascade across chained tools and create a larger blast radius than a human operator would normally create.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Tool design for acting on behalf of users depends on delegated authority and scoped privilege.
Recommendation — Scope agent authority tightly and separate user-delegated actions from ambient privileges.
MITRE ATT&CK	T1078 — Valid Accounts	User-behalf tools are abused when stolen or misused valid credentials drive actions.
Recommendation — Monitor and constrain valid-account use for tool-triggered actions.
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	Tools acting for users often rely on authenticated non-human service interactions and delegation.
	AC-6 — Least Privilege	Tool guardrails depend on limiting the actions a model can invoke on a user's behalf.
	AU-2 — Event Logging	User-behalf automation needs traceable records of action selection and execution.
Recommendation — Require strong authentication for service-to-service tool calls and delegated actions. Limit each tool to the minimum permissions needed for its task. Log tool calls, arguments, outcomes, and delegation context for review.

Practitioner Guidance

What to prioritise: Start with the smallest action surface that still completes the job. Prefer a few task-aligned tools over a single broad endpoint, because broad endpoints make both policy enforcement and model behavior harder to control.

What to verify: Check that each tool has a clear owner, a defined authority boundary, and a response format the model can reliably consume. If the model needs to infer scope, retry conditions, or delegation state, the interface is not ready.

Decision rule: If the action is reversible and low impact, allow more model flexibility; if it can change user data, permissions, money, or external systems, tighten the schema, the scope, and the approval path before release.

Practitioner takeaway: The safest design is not the most general one, it is the one that makes the intended action easy, the unsafe action awkward, and the model’s authority unmistakable.