Connecting AI to NetSuite data can be reasonably safe, but it is not risk free. Oracle's NetSuite AI Connector uses OAuth 2.0 and NetSuite roles, so an AI tool can only reach what the connected role allows, and it never runs as an Administrator. What you still own is the role you hand it, which tools you switch on, and what the outside AI provider does with data once it leaves NetSuite.
Key Takeaways
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.
There are two questions hiding inside this one. The first is whether NetSuite's own controls are sound. The second is whether your company's choices around them are. Oracle can answer the first. Only you can answer the second.
NetSuite offers an AI Connector Service that lets an outside AI assistant, such as the one your team may already pay for, ask questions of your NetSuite data and use approved tools. It does this through MCP, a standard way for AI tools to call external systems. Separately, Oracle's own assistant, Ask Oracle, lives inside NetSuite Next. Oracle's NetSuite Next FAQ says the AI Connector works alongside Ask Oracle, so they can coexist.
Only the outside connection raises the hard security questions, because the AI runs somewhere else. That is the focus of this post.
No. It can see what the connected role can see. Oracle's risks, controls, and mitigation documentation says MCP tools run with the user's permissions and are never run as the Administrator role or a full-permission role. It also says the "run as role" feature is disabled for these tools.
That makes the role you connect the real security boundary. A role built for a controller who can see every subsidiary gives the AI the same view. A role built for one narrow task gives it one narrow window. The AI is only as careful as the role you hand it.
According to the same Oracle document, external AI agents are disabled by default. MCP permission has to be granted to a role explicitly, so nobody gets it by accident. Tools cannot invoke elevated-privilege scripts or Suitelets, and they cannot make external HTTP requests. Every use of an MCP tool is logged, and each AI agent needs explicit OAuth 2.0 user consent before it connects.
That is a sensible set of defaults. It is also a set of defaults, which means it protects you from NetSuite's side of the connection and says little about yours.
Oracle lists them plainly: prompt injection, hallucination, tool poisoning, tool drift, and compromised external agents. It also states that prompt injection and hallucination are out of NetSuite's control.
Prompt injection is the one that surprises people. If the AI reads text that someone planted in a record, an email, or a document, that text can try to steer what the AI does next. Hallucination is simpler: the AI says something confident and wrong. Neither is a NetSuite bug. Both are properties of how AI assistants work, which is why Oracle puts them on the customer side of the line.
| What Oracle says is in place | What Oracle says is still your risk |
|---|---|
| External AI agents are disabled by default | Prompt injection, where hidden instructions in content steer the AI |
| MCP permission must be granted to a role explicitly | Hallucination, where the AI states something that is not true |
| Tools run with the user's permissions, never as Administrator or a full-permission role | Tool poisoning and tool drift, where a connected tool is altered or changes behavior |
| "Run as role" is disabled, and tools cannot call elevated-privilege scripts or Suitelets or make external HTTP requests | A compromised external AI agent |
| All MCP tool usage is logged | Anything the outside AI provider does with data after it leaves NetSuite |
| Each AI agent needs explicit OAuth 2.0 user consent |
Once the AI assistant has an answer, that answer sits in the provider's system under the provider's terms. NetSuite cannot see or control what happens next. Before you connect anything, read the provider's data retention and privacy terms, and find out whether your plan keeps your prompts and results out of model training. Those terms differ by provider and by plan tier, so a personal subscription and a business subscription from the same vendor are not the same thing.
It depends on the role and the tools you enable. Because tools run with the connected role's permissions, a role that can edit vendor bills means a tool could, in principle, be used to edit them. If you do not need writes, do not give the role write access. A read-only role is the cleanest way to get value without handing over the pen.
Treat it like onboarding a new hire with a short probation. Create a dedicated, non-Administrator role for AI access, scoped to the records and fields one use case needs. Switch on only the tools that use case requires. Start read-only. Run it for a few weeks and read the usage logs, since Oracle says all MCP tool usage is logged. According to Oracle's connection guide, the execution log on each integration record shows the time, duration, status, user email, HTTP status code, method, and URL path of every request. In production that data is kept for 21 days, so review it on a schedule shorter than that. Then widen access one step at a time, and only for a stated reason.
Three habits help regardless of setup. Keep a short list of who has connected which AI tool. Review that list on a schedule, such as quarterly. And require a human to verify any AI-generated number before it feeds a decision about money, inventory, or a customer.
The Vested Group's AI service called CONNECT builds a governed, least-privilege connection between a customer's NetSuite account and the AI assistant they already pay for. The AI works under a specific NetSuite role, so it can only see what that role is allowed to use. TVG does not provide the AI subscription itself. See the AI services page for the details.
Permissions come first, every time. An AI assistant should not suddenly have broad NetSuite access because somebody wants to experiment with AI. It works within the permissions of the NetSuite user who connects it, and Oracle prevents the AI Connector Service from operating through the Administrator role.
I would start with a narrowly defined role and one specific use case. What does this person need the AI to see? What does it need to do? Does it only need to query information, or does it need to create or update records? Where it is practical, I would create separate roles for different tools and different business functions. Then I would look at which tools are exposed, start with read-only or low-impact ones, and expand only after we have reviewed the behavior and the business need.
Logging is the other piece I would put in place from the start. I want that visibility before I expand access, not after something unexpected happens.
It can be, if you use NetSuite's AI Connector with a narrow, non-Administrator role and a provider whose data terms you have read. The AI can only reach what the role allows. Prompt injection and incorrect answers remain risks that your process, not NetSuite, has to cover.
No. Oracle says MCP tools run with the user's permissions and are never run as the Administrator role or a full-permission role. The run as role feature is also disabled for these tools. That is why the role you assign is your main security decision.
Prompt injection is when text hidden in content the AI reads, such as a record, email, or document, tries to steer what the AI does. Oracle lists it as a risk and states it is out of NetSuite's control, so limit tools and review outputs.
Oracle says all MCP tool usage is logged. The execution log on each integration record shows the time, user, status, and request details, and in production it keeps 21 days of data. Review it during a trial period and use what you find to decide whether to widen or narrow the role.
For an outside assistant, yes. The connection uses the AI tool your team already pays for. NetSuite Next's own assistant, Ask Oracle, is a separate feature that Oracle says is included with your NetSuite license. Check the provider's plan terms for data handling before you connect it.
Start there. Tools run with the connected role's permissions, so a role that can edit records means a tool could be used to edit them. Move to write access only for a specific need, with human review, and keep the tool list short.
The technical connection is the easy part. The harder work is choosing a role and a tool list that gives your team real answers without handing over more than a use case needs.
If you want a second opinion before you connect anything, TVG can help you design the role, the tool list, and the review habits. Start with the NetSuite Next guide for the wider picture, or talk to our team.
Ready to Get More From NetSuite?
Whether you are optimizing your current environment, planning your next project, or looking for a partner who does more than close tickets, our NetSuite team is ready to help.
Joseph Lang is the Director of inVESTED PRO at The Vested Group. With more than 13 years of NetSuite experience, he helps organizations maximize the value of their ERP investment through strategic guidance, operational improvements, and ongoing managed services. Joseph specializes in NetSuite optimization, manufacturing, warehouse management, inventory management, procurement, and SuiteCommerce, helping clients continuously improve their business processes and long-term ERP performance.