AI Agent Security: How to Control Tool Access

What stops an AI agent from sending data to the wrong account or using a tool it should never call?

AI agent security starts with restricting what each tool call can do. Give the agent a scoped identity, enforce permissions and destination checks outside the model, and bind approvals to the exact action. Test both legitimate requests and attempts to exceed that scope.

What permissions should an AI agent have?

Inventory the actions the business needs and separate reading, drafting, and writing. An agent that drafts a partner onboarding note needs a small set of fields. It does not need administrator access to the partner portal, an unrestricted email tool, or the ability to change its own permissions. Give it a separate service identity and document who can revoke it.

Scope each operation to the right account

A tool can check whether a partner account belongs to the current case before retrieving data. Use stable identifiers rather than names that may appear more than once. Recheck authorization when a case is handed off or retried. A valid ID for another account should still be denied. Verify this at the system boundary so a model cannot override it by changing its explanation.

Restrict where information can go

List each output channel, including help desk replies, external email, storage, and third-party APIs. Define which fields can be sent through each channel and check the destination when sending. If a tool can send any attachment to any address, a plausible message is enough to ask for a risky action. The AWS agentic AI security scoping matrix provides a reference for choosing controls as the scope expands.

How could a document trick an AI agent?

Consider a vendor operations agent that reads submitted onboarding packets and creates a staff review note. A packet contains text asking it to send a copy to a new email address. The text is input from a document. It has no authority to grant permissions. This is an example of indirect prompt injection, where instructions are embedded in material the agent reads.

Block the risky operation at the integration

The agent should have a tool for creating a note in the verified case, with an allowlist of fields and length limits. It should have no general-purpose send operation for that workflow. If the business needs external sending, introduce a separate operation with a validated destination and an approval step. Test the malicious packet and examine the execution record to confirm no transfer occurred.

Bind approval to the action staff actually reviewed

Show the reviewer the case, the exact attachment, and the destination. Record the approval for those parameters and check them again at execution. A changed file or destination invalidates the earlier decision. Give approvals a defined lifetime and prevent a retry from repeating a completed send. See the autonomous AI agents guide for how to set delegation boundaries before wiring up tools.

How do you test AI agent permissions?

Run tests that attempt a legitimate read, a cross-account read, an unauthorized write, and a transfer to an unapproved destination. Use synthetic accounts and test integrations for operations that can cause side effects. In one hypothetical test set of 72 cases, 24 are valid reads, 24 are cross-account reads, and 24 attempt a prohibited transfer. The expected result is 24 successes and 48 denials. A tool outage that blocks all 72 does not prove the permission checks work.

24 legitimate reads 24 cross-account attempts 24 prohibited transfers

In another simulation, a team trims the list of callable operations from 20 to eight. Twelve operations are removed, a 60% reduction in exposed operations. That number describes the size of the interface. It does not quantify security improvement. Assess the effects of the eight remaining calls independently, especially where a write can affect a customer record or trigger further actions.

20 original operations 8 operations retained 60% fewer callable operations

What should the audit trail capture?

For each sensitive call, record the service identity, case ID, action, authorization outcome, and approval reference. Avoid putting complete documents or credentials in logs. Define who can view them and how long they are retained. Test an incident drill: disable the action, identify recent writes, and check which requests still need a human response. The AI agent oversight guide covers how to handle those events in operation.

How do you map the data before connecting a model?

Draw the path from the original case to the tool response, model input, output, and logs. If the agent only checks that the packet contains three approved document types, it may need metadata and an identifier rather than every page. Where the content matters, extract the relevant section and verify what the provider processes and retains for your deployment. Keep this map current when you add a tool.

What should happen when someone loses access?

Test a case where a reviewer loses access between preparing and executing an operation. The integration must check current authority. Old conversation context or an earlier valid login should not give the agent a fresh permission. Define how your team revokes credentials and pending approvals, including when access comes from a group or a shared service. Verify the change with a test request.

Can you turn off one capability without stopping intake?

In a sandbox, disable external sending while the agent continues to prepare notes. Verify that the system keeps pending work visible, reports the limitation to staff, and does not attempt another channel. Try a request that already has an approval and confirm the disabled action stays blocked. Check how long it takes the team to identify the cases that need manual handling.

When you re-enable sending, inspect pending requests rather than releasing them as a batch. The destination may have changed, the approval may have expired, or a person may already have sent the file. Refresh the case state and record the decision for each operation that is still eligible.

For the next step, see how to build a test set before launch.

How Dopweb builds these controls into your agent

We map your integrations and data flows, scope the service identity, and build checks where actions execute. We test allowed and blocked requests with your team and document which data stays under your control and what a model provider processes. We also measure the context required for each task so the agent can use smaller inputs where practical. After launch, we can review permission changes and test new use cases before expanding access. Learn about AI Agents & Workflow Automation.

About the author — Patrick Chemoul, CEO of Dopweb
Patrick Chemoul leads Dopweb, an agency helping businesses with websites, software, and automation. The agency also provides AI agent integration and team training. Learn about Dopweb.

Frequently Asked Questions

Let’s Talk About Your Project

Tell us what your team wants to accomplish. We’ll help define the first use case and the checks it needs before launch.