What the agent can reach, how it is granted, and what breaks at the boundary.
37documents on this topic
23organizations represented
2issues named
4sourced citations
0sourced statistics
The state of it
One of 6 topics within Agent orchestration.
37 documents from 23 organizations address what an agent can reach. This is where the governance and engineering literatures actually meet, because a tool definition is simultaneously a capability and a permission.
The consistent engineering advice is that tools should be few, well-described and purpose-built rather than a general grant of access to systems. The consistent security advice is that every tool call happens under an identity, and that most organizations cannot say which. Accenture's identity work and Anthropic's risk framework arrive at the same requirement from opposite directions: you cannot attribute an action you cannot bound.
The issues, by agreement
How many independent organizations name each issue as a problem. An issue is only as real as the number of separate publishers that identify it, so the count is the ranking. Bars are organizations, not documents. Where the count reads ours, no publisher here states the issue and the analysis is our own.
Each issue carries the organizations that name it, the numbers behind it, and the remedies proposed - with the concrete steps under each. Every citation points at a section of a named document, so any count here can be checked.
Issue 012 organizations name it2026 evidence
Tool definitions are permission grants, and are being designed as features
Every tool an agent holds is a standing grant of capability. They are specified by engineers optimising for task success and reviewed, if at all, as functionality rather than as access.
Route every new tool through the same review as a service account requesting the same permission, because that is what it is.
Done when Each production agent has an inventory of its tools and the permission each implies, everything granting write access, code execution or network egress carries a security review, and unused tools are removed on a stated schedule.
Inventory the tools available to each production agent and the permission each implies.0-30 daysCISO
Require security review for any tool granting write access, code execution or network egress.0-30 daysCISO
Remove tools the agent has not used in production, on a schedule.ongoingCTO
Give every agent its own identity
Shared service accounts make attribution impossible and over-grant by construction.
Done when No agent shares an account with another agent or a person, each has permissions scoped to its own identity, and those credentials rotate on the same schedule as human ones.
Provision a distinct identity per agent, never a shared account.0-30 daysCISO
Scope permissions to that identity and rotate on the human schedule.30-90 daysCISO
The evidence — 4 documents
Organization
Document
Position
AnthropicFrontier lab · July 2026
Anthropic’s CISO guide to agentic AIOur reading States that read-only is a different concern from read/write and that tool calls, code execution and network egress each widen the aperture, with every action happening under some identity you need to know.Four questions: what actions can it take, and on whose behalf
names it
CISAOther · April 2026
Careful adoption of agentic AI servicesOur reading Names when the grant actually happens and why it is too early: permissions get set broadly at deployment to keep the thing from stalling, which is the point at which least is known about what the agent will do in practice. Adds the direction of travel nobody designs for - the tool is not only something the agent calls, it can return instructions to the agent - so a definition written as a capability is also an inbound channel.A tool definition is an entitlement, and it is granted at the wrong moment
names it
OpenAIFrontier lab
Practical guide to building agentsOur reading Defines the agent as model, tools and instructions, making the tool set an explicit design surface rather than an incidental integration detail.Agent design foundations: tools
proposes a fix
PalantirEnterprise · June 2026
Palantir: Governing AI agentsOur reading Proposes governing at the permission and action layer so the action space is bounded and enumerable rather than inferred after the fact.Governing AI agents
proposes a fix
Issue 02Our analysis
Three different kinds of tool are being governed as one
Retrieval from a data store, a function that computes, and an extension that acts on an external system carry completely different risk. They are specified in the same list and reviewed with the same rigour, which is to say none.
Three buckets: reads only, computes, or acts on an external system. Review depth follows the bucket.
Done when Every tool in the registry is tagged read, compute or act, everything in the act bucket has a security review and an approval gate, and the risk committee receives the act-class count per agent.
Tag every tool in the registry as read, compute, or act.0-30 daysCTO
Require security review and an approval gate for anything in the act bucket.0-30 daysCISO
Report the count of act-class tools per agent to the risk committee.ongoingRisk
The evidence — 0 documents
Organization
Document
Position
Who is represented
This dossier is drawn from 24 organizations working on the subject, 4 of which are cited directly in the issues above.
Consultancy — 6
KPMG 2McKinsey & Company 2Accenture 1Deloitte 1QuantumBlack, AI by McKinsey 1UST 1
Institution — 4
Cloud Security Alliance 1FinOps Foundation 1NIST 1World Economic Forum 1