Least Agency

Security engineers have a very old rule. Least privilege. Give each thing only the access that it needs. Agents need a stronger version, because they make their own decisions. The newest guidance calls it least agency. Don't give an agent more freedom than the task requires.

• Least privilege is an old rule
• Agents make their own decisions
• Least agency

Tools by role

Remember routing? Here's the safety benefit. Each route only gets the tools that it needs. A tracking request can't call refund, however it's tricked, because that tool simply doesn't exist for it. Run it. The tracking role is refused. Only the refunds role can use the refund tool. A tool that an agent doesn't have can't be misused.

ROLES = {
    "tracking": {"get_order"},
    "returns": {"get_order", "search_policy"},
    "refunds": {"get_order", "search_policy", "refund"},
}

def allowed(role, tool):
    return tool in ROLES.get(role, set())

for role, tool in [("tracking", "get_order"), ("tracking", "refund"), ("refunds", "refund")]:
    print(f"{role:<9} {tool:<10} {allowed(role, tool)}")

tracking  get_order  True
tracking  refund     False
refunds   refund     True

Practical least agency

Here's how to apply it. Give read only access by default. Use separate credentials for each agent, with narrow scopes, so that a leak is contained. Use short lived tokens. Limit amounts and rates. Log every action to a place that the agent can't edit. And prefer a small set of purposeful tools over a general one, such as run any SQL.

Too much power, or just enough

Compare these two tools. Run any SQL gives the model your entire database. Get order summary does one safe thing. One shell command tool can do anything. A run tests tool does exactly one thing. Every powerful general tool is a risk that you've chosen to take.

Summary