Tool Access Changes The Risk
An AI agent that only drafts text creates a different risk from one that can query a database, change a cloud configuration, or trigger a deployment. Once the agent can use tools, a bad model output can become an operational action.
The useful security question is therefore not whether the agent appears autonomous, it’s which identity it uses, which tools and data it can reach, and which actions it may execute under current conditions. Broad permissions or a shared service account make both prevention and investigation harder.
The Risk Of Excessive Agency
OWASP defines Excessive Agency (LLM06:2025) as the ability of an LLM-based system to perform damaging actions after an unexpected, ambiguous, or manipulated output. OWASP identifies three common causes:
- Excessive functionality: Access to tools or integrations that exceed the agent’s defined role.
- Excessive permission: Read or write access to data and systems outside the agent’s intended scope.
- Unbounded autonomy: The ability to execute high-impact actions without secondary authorization or validation.
For example, a support agent that only needs to check order status shouldn’t connect with credentials that can update or delete records. The permission exceeds the action’s purpose, regardless of how well the model performs in a test.
Identity-First Agent Architecture
Treat each agent as an identity-bearing system component. Apply identity and access management controls as you would to a service account, then add policy conditions that reflect the decision the agent supports.
1. Agents Require Explicit Identity
An agent should not inherit a developer’s credentials or every permission held by its host application. Assign a distinct service identity, scope it to one operational role, and make revocation possible without disabling unrelated services.
2. Least Privilege Applies To Agents
Restrict each agent to the data, tools, environments, and actions required for its function. Separate read, recommend, approve, and execute permissions. Logical separation limits the effect of compromise or error.
3. Require Informed Approval For High-Consequence Actions
For an action such as deleting data or changing production configuration, use staged execution until representative evidence supports a narrower automated boundary:
- The agent prepares or drafts the action.
- The proposal goes to a named approver with the evidence, expected effect, and recovery option.
- Execution proceeds only after explicit approval and is captured in a decision record.
Approval isn’t useful when the reviewer lacks authority, context, or time. The workflow must specify who approves what and what happens when that person is unavailable.
Governance At Machine Speed
Governance should be part of the execution path, not a policy checked after deployment. For every action, the system should be able to show the agent’s identity, the evidence and policy in force, the source of delegated authority, and the resulting outcome.
Start with decision support or decision augmentation when the boundary is uncertain. Expand to bounded automation only when policy enforcement, monitoring, and recovery have been tested under representative conditions.
Defining an agent’s tool authority? Book a Consultation.