Set Up a Dedicated, Least-Privilege Account for Your AI Agent

Alex, who runs order entry at a made-up promo supplier, has an AI pilot starting Monday. On Friday afternoon, Alex messages Taylor in IT: "Can we just give the agent admin for the pilot? We'll tighten it up later." Taylor has heard "later" before, and replies with a question instead: "What does it actually need to do?"

That question is the whole method. A least-privilege account isn't a special product feature or a role with "agent" in its name. It's the result of writing down the agent's job as specific actions, granting only those, and then proving that everything else is denied.

Give the agent a dedicated identity, supported by the vendor, whose permissions match its approved job, with a named business owner and a tested way to revoke it. Choose an application identity or a dedicated user account according to the system's supported authentication and licensing model. Don't grant administrator rights just to get a pilot running.

A good setup proves both sides of the boundary: the account can do what it's allowed to do, and it's refused when it tries anything outside that. Naming the account carefully doesn't make it limited.

Write the job as a list of actions

"Automate order processing" is too broad to turn into permissions, so break it into operations and the data each one needs. For Alex's order-entry pilot, the list reads: look up approved customer records, look up product options, create a draft sales order, attach the submitted artwork, and add an internal exception note.

Releasing the order to production, changing customer credit terms, issuing refunds, and managing users are separate actions, and none of them are on that list. Ask the administrator to map the list to the application's actual roles, record restrictions, and API scopes, and write down every mismatch. If the system bundles a needed permission with broader access, document what that exposes and decide whether a different route or a human handoff is the better choice.

Start with the smallest access that's still useful

Begin with read access where you can, then add the specific write permission needed for the next approved test. Restrict access to the relevant companies, subsidiaries, queues, or records if the system supports it, and keep test and production identities separate.

When the agent hits a permission error, treat it as information about what the workflow needs rather than an obstacle to clear with admin rights. Look at the denied operation and decide whether it belongs in scope before expanding anything.

OWASP's AI Agent Security Cheat Sheet recommends granting agents the minimum tools their task requires, scoping each tool's permissions, and enforcing authorization outside the agent's own reasoning. In practice that means putting the limits in the connected application and the system that carries out actions, instead of relying on an instruction in the prompt telling the agent to stay away from powerful actions. See the OWASP AI Agent Security Cheat Sheet.

Map each action to a permission and a denial test

Here's how Taylor turns Alex's list into an access spec. The administrator translates each line into the ERP's real permissions, rather than creating a role name and assuming it's restricted.

Keep the expected permission, the observed result, the test record, and the application role together in an access-review record. If the application can't separate creating a draft from releasing it, record that gap and choose an approved compensating control or a human handoff before going to production. Telling the agent in plain language not to release orders is not the same as the system refusing to let it.

Keep an access-review record

Give the account a recognizable name and description that follow your organization's naming standards. Keep an inventory of which workflows use it, the environments it's approved for, its permission set, the denial tests it passed, and the date of its next access review. Credentials never go in that inventory.

Don't hand every agent the same powerful identity by default, since that makes it hard to revoke one workflow or tell which one made a change. Creating a separate account for every small task can become unmanageable in the other direction. Group workflows under one identity only when they share compatible permissions, owners, and risk, and make individual run IDs visible in the application record or audit log where you can.

The review covers more than the ERP role. Ask your automation provider who on their side can reach the connection or your production data, under what conditions, and how that access is recorded, since support tools, exports, and stored attachments can open other routes to the same information. Who owns the connection, how its sessions end and recover, and how its credentials are handled are covered in our post on using two-factor authentication without removing it, and the same ownership and handoff plan applies to this account.

Make revocation something you've tested

Revocation and access review draw on the same record. Before production, the account's owners should be able to answer each of these:

• Which exact actions and records can this identity reach?
• Which high-consequence actions are outside its permissions?
• Can a reviewer tell which workflow and which run made a given change?
• What happens if the identity is disabled in the middle of a task?
• Which connected grants and sessions have to be revoked when the workflow is retired?

Run the revocation test in a safe environment. Confirm that pending work stops, the owners are notified, and restoring access doesn't quietly repeat an earlier change.

What a dedicated account can't prove

Back at the supplier, the pilot starts on Tuesday instead of Monday, because mapping the actions took a day. The agent can draft orders and attach artwork, and the first time it tries to release a test order, the ERP refuses. Alex counts that as the pilot's first successful test.

A dedicated account is useful when it creates a clear operational boundary, and that boundary needs upkeep as the workflow changes. Review unused permissions on the schedule in the access-review record, remove the ones the workflow no longer needs, and retire connections that no longer have an owner or a purpose.