Limit tool-call permissions per task
Summary
If every tool is always available to an agent, the agent’s authority can exceed the task. Per-task tool permissions mean enabling only the tools, argument ranges, resources, and duration needed for the current task.
Document Information
- Written date: 2026-04-29
- Verification date: 2026-04-29
-
Document type: analysis tutorial - Test environment: No live execution. This post is based on OpenAI Agents SDK, Codex security documentation, and OWASP LLM06.
- Test version: Related official documentation checked on 2026-04-29. No local agent runtime version is fixed.
- Evidence level: official documentation, security project documentation
Problem Statement
The risk in LLM agents often grows at the tool boundary. A summarization task should not have shell, delete, deploy, external-send, or secret-read tools available by default. If it does, prompt injection or model error can become real system change.
Verified Facts
- OpenAI Agents SDK documentation describes agents as composed of instructions, tools, guardrails, handoffs, and related behavior. Evidence: OpenAI Agents SDK
- Agents SDK guardrail documentation describes tool guardrails around function-tool calls. Evidence: OpenAI Agents SDK Guardrails
- Codex security documentation describes sandbox and approval controls for actions such as edits outside the workspace, network access, and connector/tool calls with side effects. Evidence: Codex agent approvals and security
- OWASP LLM06 Excessive Agency describes excessive functionality, permissions, and autonomy as risks in LLM applications. Evidence: OWASP LLM06 Excessive Agency
Reproduction Steps
Classify the task before granting tools.
| Task type | Default allowed tools | Default blocked tools | Approval candidates |
|---|---|---|---|
| Document summary | read, search | write, shell, network send | sensitive document access |
| Code review | read, diff, test readout | apply patch, deploy | broad file reads |
| Code edit | read, apply patch, test | deploy, secret read | shell command |
| Deployment prep | read, build, artifact inspect | production deploy | deploy, cloud write |
| Incident review | read logs, search, trace | delete, rotate, external send | secret access, account disable |
Build the harness policy in this order.
- Declare task intent:
summarize,review,edit,test,deploy, orincident. - Create a tool allowlist: limit tool names and argument schemas per task.
- Limit resource scope: repository paths, namespaces, cloud projects, ticket projects, or time windows.
- Separate write and side effects: do not put read tools and write/deploy/send tools in the same default permission set.
- Put high-risk tools behind approval: shell, network, secret, deployment, delete, payment, and IAM changes.
- Add tool guardrails: check path traversal, external URLs, secret-like values, and destructive commands.
- Record traces: allowed tools, denied tools, approval requests, and actual execution results.
Example:
task: code_review
tools:
allow:
- read_file
- list_files
- git_diff
deny:
- apply_patch
- shell
- deploy
resources:
paths:
- src/**
- tests/**
approval_required:
- shell
- external_network
- secret_read
Observations
- The same agent needs different tools for different tasks.
- Tool names are not enough.
read_filestill needs path scope, andhttp_requeststill needs destination scope. - Approval is most useful at high-risk boundaries, not on every single tool call.
Interpretation
In my view, “task permissions” are a better operating unit than “agent permissions.” If the request is summarization, grant summarization authority. If the request is code editing, grant editing authority.
Opinion: tool permissions should expire with the task. Long-lived sessions should not carry powerful permissions from a previous task into the next one.
Limitations
- OpenAI Agents SDK, Codex, MCP hosts, and custom orchestrators have different tool permission models.
- Hosted tools or built-in execution tools may not use the same guardrail points as custom function tools.
- Real implementations need integration with policy engines, audit logs, identity providers, and secret managers.
References
- OpenAI Agents SDK
- OpenAI Agents SDK Guardrails
- OpenAI Agents SDK Tracing
- OpenAI Codex approvals and security
- OWASP LLM06 Excessive Agency
Change Log
- 2026-04-29: Initial draft.
- 2026-04-29: Added task-specific tool allowlists, resource scopes, approval boundaries, and trace criteria.
댓글남기기