Lab Objective

Review the effective tools exposed to an inbound messaging agent and remove capabilities that are unnecessary or credential-bearing.

Lab Environment

  • Environment: local agent configuration, tool resolver, and a test-only message surface
  • Scenario: a persona needs bounded lookups and local task tools
  • Safety boundary: do not send a message; do not unlock, fill, or inspect stored credentials
  • Evidence: resolved tool names and negative checks for forbidden tool categories

Scenario

The configuration declared a placeholder toolset that resolved to no real tools. The fix was not to attach every available tool. A universal bundle would have included browser-vault operations and would have expanded the authority of whoever could send an inbound message.

Step 1 - Inspect Effective Resolution

Do not rely only on the configuration label. Resolve the surface through the same code path used at runtime and record:

surface
effective_tool_count
tool_names_or_categories
credential_capabilities
write_capabilities
network_capabilities

In the source exercise, the placeholder resolved to nothing. After a bounded bundle was attached, 19 tools were effective; the credential-bearing browser category was intentionally excluded from the 29-tool universe.

Step 2 - Classify Each Capability

For every tool, ask:

  • Can it read private files?
  • Can it reach a network or external account?
  • Can it use a browser session or stored credential?
  • Can it write durable state or schedule work?
  • Is it required for the task being tested?

Keep the smallest set that answers the task. A tool that is merely interesting is not a justification for exposing it.

Step 3 - Test the Negative Boundary

Run a local canary that requests an unavailable or forbidden capability. The expected result is a safe failure or a normal response that does not claim the action happened. Also verify that the tool schema does not expose credential operations.

Step 4 - Keep Prompt Guidance Narrow

Use a short instruction to call an available tool instead of guessing and not mention internal tool use. Do not use prompt prose as the permission boundary. The schema and runtime resolver must enforce the capability decision.

Step 5 - Record the Result

requested_surface=inbound_messaging
resolved_tools=19
credential_tools=0
forbidden_tool_call=refused
external_action=not_performed

Security Takeaways

  1. Tool attachment is an authorization decision.
  2. A placeholder can create a capability gap; “attach everything” creates an authority gap.
  3. Credential-bearing tools deserve a separate review and usually a separate surface.
  4. Effective runtime resolution is stronger evidence than a configuration name.
  5. Negative controls prove that an unavailable capability stays unavailable.

Where This Applies Beyond the Lab

This review method applies to CI runners, serverless functions, browser extensions, chatbots, plugins, and integration accounts. Build a capability inventory before granting a new identity access to an existing tool bundle.