Skip to lesson

AnthropicClaude Certified Architect – Professional2026-103.1 Evaluate tool/agent configuration for capability bloat

Remove privilege without breaking the workflow

Completed by the knowledge check

Learning objective

Apply least privilege by removing capabilities a role does not need and splitting broad agents into scoped specialists without fragmenting critical workflows.

Core idea

An explicit role menu and a constrained tool implementation establish the capability boundary. The architect’s next decision is what to remove, where retained authority belongs, and whether a specialist split preserves the work the business actually needs.

Remove unnecessary authority before adding controls around it. Logging can expose misuse, and confirmation can constrain a retained action, but neither explains why a document reader should hold a write capability. Conversely, splitting every operation into a separate agent can turn one coherent transaction into a chain of incomplete handoffs. Least privilege must preserve a complete, authorized route to the required outcome.

How it works

Turn audit findings into removal decisions

Use the dispositions from 3.1.1 to produce an explicit role-to-capability configuration. For a Messages application, the enforced artifact is the tools array the trusted request builder supplies. Exclude unneeded definitions there. Derive role selection from the application’s verified caller context rather than a sentence in the conversation claiming a privileged job.

Make unknown roles resolve to an application-defined no-tool path or a rejected request. That default is your request-builder policy, not a special Anthropic role field. Assign ownership of the builder and its role table to the platform team, while business operation owners approve the required capabilities.

For tools exposed through the Messages API MCP connector, set the mcp_toolset entry’s default_config to { "enabled": false } and enable only required names through configs: { "REQUIRED_TOOL": { "enabled": true } }, replacing REQUIRED_TOOL with the server’s tool name. Because enabled defaults to true, an unconfigured toolset exposes every tool the server offers. The connector is beta on the Claude API, Claude Platform on AWS, and Microsoft Foundry, requires anthropic-beta: mcp-client-2025-11-20, and is not eligible for zero data retention (ZDR).

Check alternate routes before accepting the cut. If a removed write remains possible through an unrestricted administrative tool or a callable specialist, the workflow still holds that authority. Follow the implementation to the side effect, then remove or narrow every route the role does not need. Backend resource authorization remains necessary for retained operations; the role menu does not establish which individual record the caller may access.

The workflow still holds a removed write while an unrestricted administrative tool or a callable specialist reaches its side effect.

The workflow still holds a removed write while another route reaches its side effectStarts at the role. Its direct route to the side effect is the removed write, drawn dotted. Two other routes, through an unrestricted administrative tool and through a callable specialist, still reach the same side effect, so each must be removed or narrowed before the cut is accepted.removed writeRoleUnrestrictedadministrative toolCallable specialistSide effect

Choose removal rather than approval settings

Recall that bare-name disallowedTools (Python: disallowed_tools) removes a definition, while pre-approval and permissionMode: "dontAsk" (Python: permission_mode="dontAsk") do not.

These distinctions matter when defending a production decision. “The role cannot receive the tool definition” is a narrower, inspectable claim than “the role normally asks before using it.” Keep confirmation for high-impact actions the role genuinely needs, and keep an execution record for those actions. Neither is the primary remedy for surplus authority.

Split around responsibility and complete outcomes

Give a specialist the smallest coherent assignment that can produce a useful result. A read-only case reviewer and a separately authorized scheduler can be sensible roles because their authority differs. A different agent for each field lookup usually adds handoffs without establishing a meaningful authority boundary.

Implement the split through explicit AgentDefinition.tools menus; the broader delegation design belongs to 1.4.3.

Review dependencies before drawing the boundary. Which evidence does the writer require? Who accepts a missing fact? Which component owns the final transaction? Anthropic’s tool-design guidance supports consolidating related operations into a useful workflow tool rather than wrapping every low-level endpoint. Preserve that advantage where the same authority applies, instead of requiring separate agents to coordinate each API call.

Use an application-owned narrow operation when a specialist needs a small piece of another domain. For example, a case reviewer can receive an approved appointment-availability lookup without inheriting all scheduling administration. Do not restore a general-purpose tool to repair one missing input.

Price the split and assign its recovery owner

Anthropic documents that a subagent’s intermediate calls and results stay in its own conversation; the parent receives its final message. That isolates working context, but creates a handoff obligation. Specify what the parent must receive to continue, and what it does when the specialist returns an unresolved dependency instead of a completed result.

Compare complete-workflow success and time with the unsplit configuration. If the narrower specialist forces the coordinator to repeat investigations or loses a required identifier, repair the handoff or change the boundary. Do not count a successful local subtask as successful business delivery. Use 3.1.4 to validate the whole redesigned route, including rejection and recovery.

Key distinctions and trade-offs

Removal versus monitoring: Removal eliminates that exposed capability from the role. Monitoring records activity on the capabilities that remain. Retain both where appropriate, with different acceptance criteria.

Specialist isolation versus workflow fragmentation: Separate authority and independent work justify a boundary. Repeated transfers of the same transaction state are a cost that the architect must measure and accept.

Narrow tool versus generic convenience: A coherent workflow tool can reduce calls without broadening privilege. A generic administrative wrapper reduces names while expanding possible actions. Judge the reachable operations, not the visual size of the menu.

Architecture / decision scenario

A healthcare provider’s referral service must prepare a referral and offer an appointment within 90 seconds. Its intake agent can read submitted records, cancel appointments, edit clinical notes, and change scheduling rules. Intake needs none of the latter three operations. All tool names in this scenario are application-defined.

The service owner proposes keeping the broad agent and asking for confirmation on every write. The architect removes the unneeded operations from intake’s Messages tools array instead. A referral reviewer prepares the required facts; a scheduling specialist receives only the appointment operations needed for this route. The scheduling implementation still authorizes the selected patient’s appointment.

A proposed four-agent split assigns one agent to each lookup. In a hypothetical pilot it raises complete-workflow time from 62 to 104 seconds, exceeding the target. The architect keeps related referral lookups together behind a narrow workflow operation and preserves the authority boundary around scheduling. The clinical operations owner accepts referral completeness; the scheduling owner accepts the authorized booking path.

A missing appointment identifier produces an unresolved handoff, not permission for intake to regain scheduling administration. The coordinator requests the missing lookup through the retained narrow route. This design removes surplus writes while preserving a complete path to a useful appointment offer.

Common exam traps

  • Adding confirmation to an operation the role never needs.
  • Leaving an MCP toolset unconfigured and exposing every operation from its server.
  • Accepting a smaller direct menu without tracing the authority retained through specialists.
  • Removing a direct operation while leaving an equivalent delegate reachable.
  • Splitting by low-level endpoint and ignoring transaction completion time.
  • Restoring an entire administrative menu to repair one missing lookup.

What to remember

Enforce removal where the role’s capabilities are assembled. Split around meaningful authority and complete responsibilities, then measure the full workflow. A narrower configuration succeeds when prohibited actions are absent and legitimate work still reaches an authorized outcome.

Knowledge check

References