Over-Broad Tools, Permissions and Autonomy

Too much functionality, permission or autonomy

Excessive agency has three forms. Excess functionality: the tool can do more than the task needs (a "manage mailbox" tool where "read subject lines" would do; a generic "run SQL" tool). Excess permissions: the tool's credentials are broader than needed (an admin database login for a read-only lookup; one shared API key for every user). Excess autonomy: the assistant takes high-impact actions with no human check. Fixes: expose narrow, purpose-built tools with validated arguments; give each tool the minimum credentials, ideally scoped to the current user rather than a super-account; remove tools that are not used; and apply approval gates for anything irreversible, costly, external or security-relevant. Review the tool list like you review firewall rules: every entry needs a reason.

Power should be earned, narrow and approved

The more an assistant can do, the more a successful attack can do; give tools narrowly, authorise per user, and approve risky actions.

Trimming a tool set

Before and after for a customer-support assistant.

BEFORE (excessive)                      AFTER (narrow)
run_sql(query)  -- any SQL, admin login   get_order(order_id) -- one fixed query, read-only account, current user only
send_email(to, body) -- any recipient     draft_reply(order_id) -- returns text; a human clicks Send
file_tool(path) -- whole disk             (removed; not needed for support)
refund(order, amount) -- no limit         propose_refund(order, amount<=5000) -- queued for human approval
autonomy: acts immediately                autonomy: reads freely; every write needs approval

Review tools like firewall rules

Every tool should have a written reason to exist and an owner.

Quick check: Which is an example of excess permissions?

• A human approval step
• A tool that reads one order for the current user
• A tool with a clear schema
• An admin database login used for a read-only lookup