Designing Least-Privilege Roles for AI Access in NetSuite

Design the role around the use case, not around everything the AI might do later. NetSuite requires a non-Administrator role with MCP Server Connection and OAuth 2.0 Access Tokens permissions, then adds only the read access the use case needs. Withhold create, edit, delete, approval, payment, and permission administration until a specific need and a review of the logs justify them. Oracle enforces some limits, but the role is yours to design.

Part of the NetSuite Next, Without the Nerves series.

Last reviewed October 5, 2026 against Oracle's published NetSuite Next documentation. NetSuite Next is changing often, so check Oracle's pages for the current state.

A connected AI tool can only do what its role allows. That is good news and a trap. It is good because NetSuite's permission model is mature. It is a trap because many companies will pick a role that already exists, one built for a person with a full day of different tasks, and hand it to a tool that needs one.

What does NetSuite enforce, and what is left to you?

Less is left to you than you might fear, and more than you might hope. Oracle's risks, controls, and mitigation document and its AI Connector FAQ set a floor. Above that floor, the design is your decision.

The takeaway is that Oracle has closed some doors, and the open ones depend on one object you control: the role.

What does a role need just to connect?

Per the FAQ, connecting needs three features enabled in NetSuite: Server SuiteScript, OAuth 2.0, and REST Web Services (required for the MCP Standard Tools SuiteApp). The role you connect with must be a non-Administrator role with the MCP Server Connection and OAuth 2.0 Access Tokens permissions, plus REST Web Services for some tools in the SuiteApp. Oracle's troubleshooting note flags a common slip: use the OAuth 2.0 Access Tokens permission, not Access Tokens.

Those permissions are about connecting. They say nothing about what the tools can read or change once connected. That comes from everything else on the role, which is where least privilege is won or lost. Oracle's getting started guide lists the required features and permissions if you want the full setup.

How do you design the role around the use case?

Write the use case in one sentence before you touch a permission. For example: answer questions about open customer invoices. Then ask what the tool must see to do that, whether it only queries or also creates and updates, and what the worst outcome would be if it misbehaved.

From there, build up from nothing, not down from an existing role. Grant the minimum read access the sentence requires. Add a permission only when you can name the task that needs it. Oracle's guidance points the same way: limit permissions to only those really needed, avoid high-privilege roles, and when trying a new tool, start with a limited scope.

Keep roles separate by purpose. Oracle advises creating separate roles for different MCP tools instead of reusing broad operational roles, separated by business function and risk level whenever practical. A role for finance questions and a role for purchasing questions should not be the same role with extra permissions bolted on.

Which permissions should you withhold?

Oracle's list of high-impact actions is a decent starting point: creating, modifying, deleting, approving, paying, exporting large data sets, changing permissions, and accessing new sensitive resources. Its risk document also names the damage that follows from them, such as an agent making payments or granting approvals the user never intended, or deleting and modifying data.

So the default answer for an AI-connected role is no. No approval authority, no payment or banking permissions, no ability to administer roles or permissions, and no unrestricted record modification. Each one can be added later for a defined reason. None should be added because somebody might want it.

How do you narrow the tools as well as the role?

A role limits what a tool can reach. The tool list limits what the AI can attempt. Oracle says to install and enable only the tools your business needs, and notes that the actions available to an external agent are strictly limited to the functionality of the installed tools. Users can also scope tools by namespace, and Oracle says not to try invoking tools outside the namespaces the administrator and user authorized.

Prefer read-only or low-impact tools during evaluation, expand only after reviewing behavior and logs, and review the whole set of tools an agent can reach. Oracle warns against combining NetSuite tools with tools that give broad access to local files, browsers, email, or internal networks outside trusted, isolated environments.

How do you test that the role is tight enough?

Try to break it. With the role connected, ask the AI to do things it should not be able to do: approve a bill, change a vendor's bank detail, read a subsidiary the role should not see. If it succeeds, the role is too wide. If it fails, check that the failure is clean and shows up in the log.

That log is your evidence. Oracle's FAQ says the execution log on the integration record shows request time, duration, status, user, HTTP response, and request details, retained 21 days in production and 7 in sandbox. Review it on a schedule shorter than the retention window, and look for unexpected tools, unusual activity, and repeated failures.

Joe's take: if you can't say what it needs, you're not ready

I design the role around the use case, not around everything the AI might someday be able to do. If the first use case is asking questions about customer or transaction data, the role should have the minimum read access necessary to answer those questions. I wouldn't give it edit, create, delete, approve, or financial transaction permissions just because we might want them later.

NetSuite itself enforces part of this philosophy. The AI Connector can't operate through the Administrator role, and it needs a non-Administrator role with the specific permissions necessary to connect, including MCP Server Connection and OAuth 2.0 access. Additional permissions depend on the tools being exposed. I would be extremely reluctant to give an AI-connected role broad transaction approval, payment, banking, role administration, permission administration, or unrestricted record modification capabilities.

The question should always be what is the minimum this tool needs to accomplish this use case. If we cannot answer that clearly, we're not ready to give it access.

Frequently Asked Questions

What role should an AI client use to connect to NetSuite?

A non-Administrator role built for the use case. Per Oracle, it needs the MCP Server Connection and OAuth 2.0 Access Tokens permissions, plus REST Web Services for some MCP Standard Tools. Beyond that, grant only the minimum access the use case needs, and keep it separate from broad operational roles.

Can the NetSuite AI Connector use the Administrator role?

No. Oracle says the AI Connector does not support Administrator roles, and its risk document adds that MCP tools are never executed with roles that have full permissions. Create a custom role or use an existing non-administrator role, and assign the permissions needed to connect, then limit everything else.

What permissions should I never give an AI-connected role?

Start by withholding approval, payment, banking, role administration, permission administration, and unrestricted record modification. Oracle lists creating, modifying, deleting, approving, paying, changing permissions, and exporting large data sets as high-impact actions. You can add one later for a specific, reviewed need, not just in case.

Should I use separate roles for different AI tools?

Yes, where practical. Oracle advises creating separate roles for different MCP tools instead of reusing broad operational roles, separated by business function and risk level. It limits what an external agent can do and makes access reviews simpler, because each role has one purpose you can check against what it actually does.

How do I test whether an AI role is too permissive?

Connect with the role and ask the AI to do things it should not be able to do, such as approving a transaction or reading a restricted subsidiary. Then check the integration record's execution log for the attempts. If anything succeeds that should not, tighten the role before you widen access.

How often should I review AI access roles?

Regularly. Oracle advises periodic review of users with MCP permission, assigned roles, installed tools, enabled namespaces, authorized AI agents, and consent grants, removing anything no longer required. The execution log keeps 21 days in production, so review activity inside that window and not after it.

Not sure what your AI role should look like?

Most companies find the hard part is not NetSuite's controls but the existing roles. Years of added permissions make it difficult to tell what a role really allows.

TVG can review your roles, define the use case, and build a role that fits it. See our AI services, ask about a NetSuite Health Assessment, or start with the NetSuite Next guide.