An AI agent used by a customer support team can retrieve order details, check a refund policy, update a customer record and initiate a refund. Each capability may have a legitimate business purpose. The agent may have valid credentials, use approved APIs and pass every authentication check.
Yet the same combination of capabilities can create a problem. The agent might initiate a refund that requires additional review, modify a record before verification is complete, or use information obtained from one system to trigger an inappropriate action in another. No individual tool necessarily needs to be compromised for the overall workflow to produce an unwanted result.
This is the challenge with AI agent access control: granting an agent legitimate access does not automatically make every action it can perform appropriate. Organizations need to control not only which systems an agent can reach, but also the operations it can perform, the circumstances in which it can perform them and the conditions that must be satisfied before an action is allowed.
Why conventional access control is not enough
Traditional access control answers an important question: which identity is allowed to access a resource? An application might allow a user to read customer records but restrict the ability to modify them. An API might require authentication and check whether the calling identity has permission to submit a request.AI agents introduce a more complicated operating pattern. They can interpret instructions, select tools, combine information from different sources and decide which action to take next. Their behavior may therefore involve several individually valid operations whose combined effect was never explicitly considered when access was granted.
Consider a support agent with access to an order-management system and a refund API. It can retrieve an order, inspect the refund policy and initiate a payment reversal. Those permissions may be appropriate for routine cases. But a disputed transaction, a high-value refund or a case with incomplete verification may require a human decision.
If the agent has unrestricted access to the refund operation, the API may accept a technically valid request even when the business circumstances make that refund inappropriate. Authentication can establish who made the request. Permission checks can establish whether the identity is allowed to use the endpoint. Neither necessarily establishes whether the action is appropriate for that customer, transaction or stage of the process.
This is why the distinction between identity, permission and authority matters. Identity establishes which agent is acting. Permission defines which resources and operations it can access. Authority concerns whether a particular action is justified under the current circumstances, including applicable business rules, approval requirements and the limits of the agent's delegated responsibility. Access control remains essential, but it must be designed around the actions an agent can take, not just the systems it can reach.
The risk is in how approved tools combine
The problem becomes harder when an agent has access to several connected tools. A document-retrieval tool, a customer database and an external API may each be approved independently. However, their combination can create a workflow with consequences that no individual tool owner intended.For example, an agent might retrieve a customer document, extract information from it, use that information to change an internal record and then trigger a downstream workflow. The document could contain misleading instructions, the record change could bypass a required review, or the downstream system could treat the updated record as a trusted signal.
The relevant question is not simply whether each tool is permitted. It is whether the agent can combine those tools to reach an outcome that exceeds its intended role.
This is especially important when untrusted content can influence an agent's decisions. An email, uploaded document or retrieved webpage may contain instructions that attempt to redirect the agent. If the agent can act on those instructions using broad permissions, the consequences can extend beyond the original content. The risk depends on the agent's design, the tools available, the controls around those tools and the protections enforced by connected systems.
The principle is straightforward: a tool should not grant an agent more practical power than the task requires, and the agent's reasoning should not be the only barrier preventing misuse of that power.
Design access around actions, not just applications
A practical approach begins by mapping what the agent is expected to do in its actual business workflow. Listing connected applications is useful, but it does not reveal the full range of possible consequences.For each tool, identify the operations available to the agent. A customer-support agent may need to read an order, prepare a refund recommendation and update a case status. It may not need unrestricted authority to issue refunds, change customer identity details or override a dispute status.
Separate read access from write access wherever possible. Distinguish low-impact, reversible actions from actions that move money, expose sensitive information, change important records or trigger further activity. If an agent needs to recommend a consequential action, that does not automatically mean it should be able to execute it without review.
This is also where Segregation of Duties (SoD) becomes relevant. An agent that identifies a problem, recommends a remedy and executes that remedy should not automatically control every stage of a consequential transaction. Where the business process requires independent review, the architecture should preserve that separation even when the workflow is automated. The principle of least delegated authority provides a useful design rule: give the agent only the capabilities needed for its assigned task, and reserve consequential decisions or execution rights when the circumstances require independent approval.
Permissions should also be scoped to the specific task and resources involved. An agent handling one customer's case should not automatically receive broad access to unrelated customer records. A tool that only needs to update a particular field should not expose a general-purpose operation that can modify the entire record.
Microsoft's guidance on securing AI agents emphasizes least privilege, careful binding of tools to identities, and authorization checks at the point of action. The practical implication is that access should be limited to the minimum capabilities required for the task, rather than inherited from a broad service account simply because that account is convenient to configure.
This does not mean every action needs a human approval. Routine, low-risk operations can remain automated where the boundaries are well defined. High-impact, irreversible or exceptional actions may require an additional approval or a separate control enforced by the receiving system.
A practical method for reviewing agent capabilities
Before deploying an agent, or when its tools and responsibilities change, conduct a tool-chain review. The objective is to identify not only excessive permissions but also combinations of permitted operations that could produce an inappropriate outcome.- Define the agent's intended job: Describe the business task in terms of outcomes, not vague capabilities. For example, “prepare eligible refund requests for processing” is more precise than “manage customer refunds.” Establish which decisions the agent may make independently and which remain with a human or another control.
- Inventory the tools and operations: For every connected application, list the actual operations the agent can invoke: reading records, editing fields, submitting requests, issuing transactions, changing permissions or triggering downstream workflows. Include the identity under which each operation runs. A tool may appear limited in the agent's interface while its underlying credential grants broader access.
- Trace combinations from input to outcome: Map how information moves between tools and what each operation enables next. Ask whether untrusted input could influence a later action, whether a record change could trigger another process, or whether two individually reasonable permissions combine to bypass a required review. Focus on plausible paths to consequential outcomes rather than attempting to enumerate every theoretical possibility.
- Set an enforceable boundary for each consequential action: Decide which actions can run automatically, which require conditions to be met and which need explicit approval. Enforce those conditions in the tool, API or receiving business system wherever possible. For example, a refund operation might enforce transaction limits and eligibility rules independently of the agent's reasoning. A high-value or disputed refund might require a separate approval before execution.
- Test the boundary, not just the normal workflow: Test what happens when the agent receives misleading instructions, encounters incomplete data, retries a failed request or tries to perform an operation outside its intended role. Verify that the receiving system rejects prohibited actions and that approval requirements cannot be bypassed by switching tools or changing the sequence of operations. Include failure and retry scenarios in these tests. If an API request times out after a transaction has been processed but before the agent receives confirmation, the agent may attempt the same action again. For operations such as refunds, payments or record creation, test whether the receiving system can recognize duplicate requests and prevent unintended repeated effects. Idempotency controls, transaction identifiers and explicit confirmation of execution status can help ensure that a retry does not become a second transaction.
- Reassess when capabilities change: A new tool, wider API scope, changed service identity or altered workflow can expand what an agent is able to do without any change to the underlying model. Review whether the original access design remains appropriate whenever those dependencies change. Retain the review decision and the evidence supporting it.
Where access control must be enforced
A policy stating that an agent must not issue an inappropriate refund is not enough if the agent can still call an API that will execute the transaction. The restriction needs to exist at a point where it can actually prevent the action.The model can be instructed to request approval. The orchestration layer can require a human sign-off. The API can enforce transaction limits. The business system can reject an action when verification is incomplete. These controls serve different purposes, and their suitability depends on the workflow and its risks.
For more complex environments, these boundaries can be expressed as machine-readable authorization policies rather than informal instructions alone. Policy engines and frameworks such as Open Policy Agent (OPA) or Cedar can help teams define and evaluate access decisions against attributes such as the agent's identity, requested action, resource, transaction value and approval status. The appropriate implementation depends on the architecture; adopting a policy engine does not automatically make a workflow safe. Teams still need to define the rules correctly, enforce them at the relevant execution points and test that prohibited actions are rejected.
For consequential operations, relying only on the agent to recognize when it should stop is a weak boundary. The same system being constrained is also the system interpreting the instructions and selecting the next action. Independent enforcement reduces the consequences of an incorrect decision, misleading input or unexpected sequence of tool calls.
Organizations should also preserve evidence of what the agent attempted, which identity and permissions were used, which controls were evaluated, whether approval was obtained and what the receiving system actually did. This helps distinguish a blocked attempt from a completed action and makes later investigation more reliable.
NIST's work on the identity and authority of software agents reflects the growing importance of defining how agents are identified and what authority they can exercise. Microsoft's guidance similarly highlights least privilege, action-level authorization and human approval for high-impact actions. OWASP's Top 10 for Agentic Applications also provides a security framework for assessing risks that emerge as agents use tools and act across systems.
These sources point toward a common design principle: agent autonomy needs boundaries that are defined, enforced and reviewable. The exact controls should reflect the agent's function, the sensitivity of the resources it can access and the potential impact of its actions.
Access control is not a one-time configuration
An agent's capabilities can expand over time. A team may add a new tool to improve efficiency, connect another data source or grant a service identity broader access to simplify integration. Each change may appear reasonable in isolation, but it can alter the range of actions the agent can perform.That makes access review an ongoing assurance question. When a tool or permission changes, the organization needs to establish what new actions are possible, which existing controls might be affected and whether the previous assessment remains valid. It should be possible to show what changed, who reviewed the change, what decision was made and what evidence supports it.
This is where continuous AI assurance complements technical security controls. Runtime protection and API authorization help prevent or restrict unsafe actions. An assurance process connects changes in capabilities to risk assessments, accountable owners, corrective actions and evidence of review. KlaritiQ's intended role is to support that traceability and follow-through, not to replace runtime security controls or independently block agent actions.
The result is a more defensible way to manage change. A new integration does not simply become another line in a configuration file; it becomes a change whose implications can be assessed and whose approval can be evidenced.
The test every AI agent owner should be able to pass
Take one agent that can act across multiple business systems. List its tools and the operations available through each one. Then trace a realistic sequence from an incoming instruction to a consequential outcome. Ask three questions:- Can the agent combine individually permitted tools to bypass an important business control? Where is that outcome technically prevented, rather than merely discouraged by a prompt? And when a permission or integration changes, can the organization demonstrate that the agent's boundaries were reviewed and remain appropriate?
- If the answers depend entirely on the agent choosing correctly, the access design needs stronger controls. If nobody can explain the practical effect of a new permission, the organization does not have a complete view of the agent's capabilities.
- The objective is not to eliminate autonomy. It is to make autonomy proportionate to the task, constrain consequential actions through enforceable boundaries and preserve evidence that those boundaries were deliberately designed.
AI agent access control is not simply about deciding which tools an agent can use. It is about ensuring that the capabilities those tools provide, individually and in combination, remain within the authority the organization intended to delegate.