c4.1 Scope tool roles with least privilege and permission boundaries

Each tool is a new privilege the agent gains

When an agent can call tools, each tool integration is a role with permissions. The risk is twofold: an individual tool role that is too broad, and — more subtly — privilege combination, where an agent chaining several tools achieves something no single tool was meant to allow. Least-privilege per tool handles the first; permission boundaries handle the second by capping what any tool role can ever do, regardless of the policies attached to it.

Scope each tool role tightly

Give every tool its own role with only the actions and resources that tool needs — a "read customer record" tool should read one DynamoDB table, not hold dynamodb:*. This is the same least-privilege discipline as the model-invocation role, applied per tool.

Cap the ceiling with a permission boundary

A permission boundary is a managed policy attached to a role that sets its maximum permissions. The role's effective permissions become the intersection of its identity policy AND the boundary — so even if a tool's policy is later widened (or an attacker tries to attach a broader one), it can never exceed the boundary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ToolMaxPermissions",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "s3:GetObject"
      ],
      "Resource": "*"
    },
    {
      "Sid": "NeverTouchIdentityOrSecurity",
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "kms:ScheduleKeyDeletion",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

Attach it when you create the tool role:

aws iam create-role \
  --role-name agent-tool-read-customer \
  --assume-role-policy-document file://trust.json \
  --permissions-boundary arn:aws:iam::111122223333:policy/AgentToolBoundary

Make the boundary mandatory for tool roles

The boundary is only effective if it is always attached. Enforce it with an SCP or IAM condition (iam:PermissionsBoundary) so any role created for a tool must carry the boundary — otherwise a developer can create an unbounded tool role by omitting it. This is how you stop privilege combination across a growing set of tools.

Naming note: the boundary grants nothing on its own — you still need each tool's identity policy. The Deny block is the real value: actions no tool should ever perform (touch IAM, delete keys, manage the org).