🔄 Topic

I reviewed what capabilities a messaging-facing agent could actually reach. The lesson was simple but important: describing a tool in a prompt does not grant a capability, while attaching a tool schema can make that capability real.

🎯 Goal

Apply least-privilege thinking to an AI agent: expose only the tools required for the task, keep credential-bearing capabilities out of an untrusted message surface, and verify the effective runtime tool set instead of trusting a configuration label.

🛠 What I Did

The surface initially declared a placeholder toolset that resolved to no usable tools. That meant the model could talk about capabilities but could not perform them. Once real toolsets were attached, the behavior changed: the model could execute a permitted lookup and continue to a useful answer.

That change also exposed a second risk. Attaching every available tool would have included browser-vault operations capable of reaching saved credentials. I removed that category from the messaging surface while keeping the narrower capabilities needed for the tested workflow. The effective surface had 19 tools instead of 29.

I also separated two kinds of prompt content. A short note can tell the persona to call a tool rather than guess and not to mention internal tool use. Long process instructions written in an assistant voice were removed from the impersonation path because they changed the persona’s register without providing the capability itself. The tool schema is the interface; prose is not a substitute for authorization.

🔗 Key Cybersecurity Connections

This is least privilege applied to software composition:

  • a tool that reads files has a different boundary from a tool that fills credentials
  • a web lookup is different from a browser session with stored secrets
  • a capability needed by one operator does not automatically belong on every inbound surface
  • effective runtime resolution matters more than a friendly name in a YAML file

🔍 Investigation Questions

  • Which actor can invoke the surface?
  • Which tools can it call, and what data can each tool reach?
  • Does the effective tool list match the declared policy?
  • Are credentials, browser sessions, or unattended writes exposed unnecessarily?
  • What happens when a tool is described in text but absent from the schema?

🚨 Detection Opportunities

Monitor for unexpected tool calls, a toolset changing after deployment, credential-related schemas appearing on a messaging surface, and a model repeatedly attempting a tool that is not available. These are useful signals of configuration drift or prompt/interface mismatch.

Example review record:

surface=inbound_messaging
effective_tools=19
credential_tools=0
unknown_tool_calls=0
policy=least_privilege

🧭 MITRE ATT&CK Techniques

No direct ATT&CK mapping is claimed. The work is preventive capability scoping. If an exposed credential tool were later abused, investigators would choose techniques from the observed activity rather than from the existence of the tool alone.

🗺 Visual Investigation Diagram

Inbound message
    ↓
Agent identity and surface policy
    ↓
Effective tool resolution
    ↓
Allow only task-required capabilities
    ↓
Remove credential-bearing tools
    ↓
Run a local canary and inspect the final output

⚠ Challenges

The confusing part was that the configuration could look active while the effective tool list was empty. The opposite mistake is just as dangerous: treating “attach everything” as a quick way to make the agent useful. Capability discovery must include the data and authority each tool carries.

📚 What I Learned

The model does not decide what it is authorized to do. The runtime tool schema, the caller identity, and the delivery boundary decide that. Prompt instructions can improve behavior, but they are not a permission system.

➡ Next Steps

  • Keep an effective-tool inspection in the deployment checklist
  • Review every new tool for credential, network, persistence, and write access
  • Test unavailable-tool behavior as a negative control
  • Prefer small task-specific tool bundles over a universal tool list

🧠 Reflection

Security architecture becomes clearer when I ask “what can this caller reach?” instead of “what does the agent know how to do?” The answer has to come from the running resolver and schema, not from a paragraph in a prompt.

🧩 Lessons Learned

What worked

Inspecting the effective runtime list and removing the browser-vault category from the messaging surface.

What could go wrong

Assuming a placeholder toolset is active, or exposing saved credentials because a tool bundle was convenient.

Takeaway

Tool attachment is an authorization decision and should be reviewed like any other access-control change.

📈 Skill Progression Context

This connects my Google Cybersecurity Certificate work on authentication and authorization to modern agent systems. The vocabulary changes, but least privilege, scope, attribution, and review remain the same.

😄 TL;DR

Prompt prose can describe a capability, but only the effective tool schema grants one. Expose the smallest safe bundle.