AI Agents With Access: How to Limit What They Can Do

The risk is excessive agency

OWASP calls it excessive agency (LLM06 in its 2025 list): an agent with too much functionality, too many permissions or too much autonomy can do real damage when a prompt, a file or its own mistake steers it wrong. The same model can be low risk in one setup and high risk in another. What it is connected to and allowed to do decides the danger.

Treat an agent like a fast, tireless intern: useful, but not handed the keys to every department on day one.

Write the agent a job description

"Help with email" leads to broad access. "Read incoming support emails, look up the customer in the CRM, draft a reply and send it to a person for approval" shows exactly what it needs: read email, limited CRM lookup, create drafts. It does not need to send, issue credits or delete.

Purpose: the one business problem it solves.
Systems and data: which inbox, folder, CRM objects or repository.
Actions: read, create, edit, send, pay, delete or deploy?
Approvals, limits and the stop plan.

Least privilege and separate keys

Give each agent only what its job needs. Read-only calendar access to check availability. One project folder, not the whole drive. Invoice status, not the power to release payments. Repository read access or pull-request comments, not merge rights. Avoid admin and owner roles.

Give every agent its own account or API key, never an employee's login or a shared company integration. Separate identities make it clear which agent did what, and you can revoke one without breaking the others. Name them plainly, such as "ai-support-drafter".

Human approval for irreversible actions

The safe pattern is draft, then approve. The agent prepares the email, refund, deletion or code change; a person confirms. Sending external email, paying, refunding, deleting, changing permissions and deploying code all wait for a named approver. A good approval screen shows the action, the system, the record or customer involved, what the agent based it on and lets the approver edit before confirming.

Limits, logs and credentials

Spending caps per transaction and per day, and budget caps on paid tools.
Rate limits on emails, record changes, file operations and API calls, so one bad instruction cannot hit hundreds of customers.
Logs of who triggered the agent, what it accessed, what it did, approvals and refusals, without logging passwords or full card numbers.
Credentials in a secrets manager, never in prompts, spreadsheets or code; rotate them and delete old test keys.

Start with low limits and raise them only when the agent has proved reliable.

Test in a sandbox with hostile inputs

Try the agent on test inboxes, dummy calendars, fake invoices and staging repositories before it touches anything real. Feed it messy emails, vague requests and documents containing instructions to ignore its rules. That is how you find prompt injection and other failure modes before customers do.

Review connectors and keep a kill switch

A plugin sold as a "file helper" may also share and delete. Check what each connector can reach and do, whether it supports read-only modes, and remove ones you tested and abandoned.

A kill switch pauses the agent, revokes its key or blocks outbound actions in one step. Decide who can use it, test it before launch and make sure nobody has to hunt through vendor settings during an incident.

A rollout plan

Pick one low-risk job, such as drafting support replies.
Map the exact access it needs and grant only that.
Create its own credentials.
Require approval for sending, paying, deleting, exporting and deploying.
Set spending and rate limits.
Test in a sandbox with hostile inputs.
Turn on logging and prepare the kill switch.
Expand slowly.

Where ASL fits

Every product on the ASL platform fails closed: when authorization is missing, expired or uncertain, the product refuses. Audit trails are hash-chained so records prove their own integrity. Our custom software development team builds AI agents the same way, with narrow permissions, approvals and logs from the first release. Contact us to talk it through.

Frequently asked questions

What is excessive agency in AI?

OWASP's term for an AI system that has too much functionality, permission or autonomy, so a mistake or manipulation can cause real damage through the tools it can reach.

Should an AI agent use an employee's login?

No. Give each agent its own account or API key with narrow permissions, so you can track its actions and revoke it without affecting anyone else.

Which agent actions need human approval?

Anything hard to undo: sending external email, payments and refunds, deletions, permission changes, legal documents and code deployments.

What is an AI agent kill switch?

A fast way to pause the agent, revoke its credentials or block its outbound actions when something looks wrong. Test it before launch.

How should we test an AI agent before going live?

In a sandbox with test data, including messy and hostile inputs such as documents that tell it to ignore its rules.

Related guides

Explore the complete product

Read features, current access and limitations