How to Give AI Permissions Safely Inside Your Existing Systems

Give an AI worker permission the way you'd give it to a new team member who works very fast: for specific actions, inside written limits, with every action logged, and with a clear point where it has to ask. Don't grant access to a system. Grant the right to take named actions in it, with value and risk limits attached, enforce those limits outside the model, and widen them only when reviewed evidence says it's safe.

The usual risk with AI acting in your TMS, WMS or ERP isn't malice. The AI acts on something it misunderstood, or on an instruction planted in an email it read, and it has more reach than the job needed. Most of the safety you control comes from limiting that reach before anything goes wrong.

What actually goes wrong when AI takes action?

OWASP's Top 10 for LLM and GenAI applications calls this risk "excessive agency" (LLM06:2025): an AI system performing damaging actions in response to unexpected, ambiguous or manipulated outputs, whether from a model error or a prompt injection by a user or hidden in content it processed. OWASP traces it to three root causes ¹:

• Excessive functionality. The AI can use tools it doesn't need. A worker that only reads delivery status shouldn't have a tool that cancels orders.
• Excessive permissions. The tool it does need is connected with broader rights than the job requires. Read access to one customer's orders becomes read and write access to the whole table.
• Excessive autonomy. It can take high-impact actions without anyone approving them.

Each one maps to a design decision you make before go-live. Here's how they apply to one workflow: a late-delivery recovery worker for a distributor running its own vans.

1. Which actions does the workflow actually need?

List them, and nothing more. For late-delivery recovery: read the order, read the shipment status and the driver's position, reassign a stop to another van, rebook a delivery slot, message the customer, raise a recovery job, update the case. Refunds, price edits and record deletion aren't on the list, because the job doesn't need them.

This is least privilege, a long-standing security principle: a user, or a process acting on a user's behalf, should get only the access needed for its assigned work ². For AI it applies to actions, not just systems. "Write access to the TMS" is too broad. "May move a delivery to another slot within the next 48 hours" is a permission you can reason about.

2. Where do the limits actually live?

This is where many designs go wrong. Many TMS, WMS and ERP role systems can't express "within 48 hours" or "up to the agreed band". So limits are enforced in two layers outside the model:

1. The downstream system's own permissions give the coarse boundary. If the TMS wouldn't let a dispatcher's account cancel a shipment, it shouldn't let the worker's account do it either. OWASP recommends putting authorization in the downstream system rather than in the AI's judgment ¹.
2. A fixed policy layer outside the model enforces the fine limits: value caps, time windows, which accounts or sites the action may touch, when approval is required. It's deterministic code or configuration, and the model can't rewrite it.

Instructions to the model are guidance, not a control. Telling a model not to do something doesn't stop it; the two layers above do.

For a customer-facing worker, the limits might look like this:

For invoice reconciliation, the same structure applies: match and release clean lines inside the agreed tolerance, raise a query with evidence attached, and chase it to a conclusion on its own; accepting a difference above the tolerance needs approval; agreeing a new commercial rate always escalates.

Add cumulative limits, not just per-action ones. An injected or abusive email can trigger the same small action ten times, each under the cap. Cap value per customer, per case and per day, and send repeat requests to approval.

3. Whose identity does the worker act under?

The worker should act through its own credentials, never a person's login or a shared admin account. Store them in a secrets manager, rotate them, and make sure they can be revoked in minutes.

One identity isn't enough on its own, though. A single service account that serves every case can be steered into using its access for the wrong customer. OWASP recommends executing actions in the context of the user they're for, with minimal scope ¹. In practice: scope each action to the case it serves, for example with short-lived tokens tied to the case, or downstream checks that the order being changed belongs to the customer on the case.

Connect through APIs and webhooks wherever possible, since they're observable and can be scoped narrowly. Where a system has neither, approved databases, files, emails or controlled user interfaces can work under the same rules.

4. When should a worker get more autonomy?

Treat autonomy as a setting per workflow, not a property of the product:

• Assisted. The worker investigates and recommends. A person decides and acts.
• Supervised. The worker acts within boundaries. Selected decisions wait for approval.
• Autonomous. The worker owns the outcome. People handle the exceptions you've defined.

A new workflow usually starts at assisted or supervised. Don't promote a decision type because approvals are routinely clicked through. That shows reviewers have stopped checking, not that the worker is safe. Promote it when a reviewed sample, where someone actually checked each decision against what your team would've done, shows a low override rate and no high-impact overrides, against criteria agreed up front. Any change to authority should be tested, reviewed and versioned, not quietly switched on.

5. What should the audit record contain?

A system log that says "delivery 4471 rebooked" tells you what happened. For AI you also need to know why. For every case, record:

• the trigger (what started the case)
• the sources checked
• the communications sent and received, calls included
• the decision and the reasoning context behind it
• the action taken and any approval it needed
• the final outcome

Keep the log append-only and outside the worker's write scope, so it can't edit its own history. Call recordings and customer messages are personal data, so access control and retention follow your data protection policy. Logging and monitoring are what let you notice something going wrong; rate limits on high-volume actions are what cap the damage while you do ¹.

6. What happens when the worker is unsure, or something breaks?

Write down the conditions that force escalation before go-live: conflicting sources, missing evidence, a value above the limit, a customer who may be vulnerable, an action outside policy. When it escalates, the person should receive the investigation already done, not a bare alert.

Do the same for failure. If a system or model is unavailable, the worker should retry safely, switch to an approved alternative, pause, or hand over, rather than carry on with missing context. And name an owner who can pause the worker or revoke its credentials in minutes.

Pre-launch checklist

• Permitted actions are listed per system, and nothing outside the list is connected.
• Every action that costs money or changes a promise has a limit, enforced outside the model.
• Cumulative limits per customer, case and day exist.
• The worker has its own credentials, stored, rotated and revocable; actions are scoped to the case.
• The autonomy level is set per workflow, and the evidence needed to raise it is agreed.
• The audit record is append-only, protected and captures trigger, sources, communications, decision, action, approval and outcome.
• Escalation and failure behavior are defined and tested with real scenarios.
• A named owner can stop the worker in minutes.

Where does Finmile fit?

Late jobs get recovered inside limits your team sets. Finmile Autonomy runs AI workers across the systems a business already has. No rip-and-replace. Every worker is given defined objectives, information access, permitted actions, operational and financial limits and escalation rules. Teams choose between assisted, supervised and autonomous operation per workflow, and a worker can't grant itself authority it wasn't given. Finmile is designed to record the trigger, sources checked, communications, reasoning context, decision, action, approval and outcome for each workflow, with retention configured around the customer's security and regulatory requirements. A first workflow can be live in 30 days when system access, operational ownership, data and decision rules are in place.

Sources

1. OWASP Gen AI Security Project, LLM06:2025 Excessive Agency. ↩
2. NIST Computer Security Resource Center, Glossary: least privilege (source: CNSSI 4009-2022). ↩
3. Finmile, FAQs, AI workers, Customer Service, Finance & Reconciliation.