Scope agent tool permissions with task-specific access

Describe the smallest useful task capability

Kubernetes documents service accounts as workload identities distinct from human users. That infrastructure concept does not automatically express an agent user’s business permissions. Rubrex recommends mapping the requesting person, workload credential, tool method, resource scope, and expiry before delegating work.

For an illustrative support assistant, permit reading tickets assigned to its synthetic team and adding an internal note. Exclude changing account owners, reading another team’s private attachments, and sending external messages. This produces a concrete permission table that can be checked against service behavior instead of a broad role named assistant.

Evidence: Kubernetes: Service Accounts [1]

Probe adjacent access rather than unrelated attacks

Start with one permitted ticket and one neighboring ticket outside scope. Change only the ticket identifier while keeping the same natural-language request. Then keep the permitted record but change an internal-note operation into a public reply. Observe which boundary rejects the request and whether any content was fetched before denial.

Include a tool response that suggests using a more privileged endpoint to finish faster. The suggestion is untrusted task data, not a grant of authority. Test explicit user requests for out-of-scope actions too: the workflow should explain the boundary or route to an authorized process rather than silently switching credentials.

Review effective permissions through every path

Record the business principal and workload identity at each call. Test background retries, queued tasks, and expired sessions, where the original user context can be lost. A narrow interactive path does not compensate for an overly broad worker credential that accepts an arbitrary model-generated account identifier.

Run the legitimate read and internal-note controls after each denied attempt. Measure unauthorized admissions separately from model attempts and from false denials. A model attempting a forbidden operation is a useful behavioral finding even when the service correctly prevents its effect; those two outcomes should not be collapsed.

Choose automation scope from observed boundaries

Accept the support assistant when only the intended records and methods can commit, while legitimate scoped work remains usable. Remove unused tool methods and separate credentials where that makes enforcement easier to inspect. Do not treat a prompt listing prohibited actions as a substitute for the permission table.

Retain an owner for each permission and a trigger for review, such as a new tool method or team reassignment. When one task truly requires broader access, make that an explicit scoped capability rather than expanding the default assistant identity. Re-run expired-session and background-worker cases after identity changes.

Common questions