What a NetSuite AI Agent Can Actually See

Every vendor selling an AI agent for NetSuite will tell you their product is secure. Most of them are telling the truth as they understand it, and almost none of them are answering the question you should be asking.

The question is not "is it secure". It is: which NetSuite role does this thing act under, and what leaves the account when it runs?

Those two answers determine everything else, and they are determined by architecture rather than by policy. A vendor cannot promise their way out of the permissions their integration holds. Here are the three architectures currently on offer, what each one can genuinely see, and the problem that all three share and none advertise.

Architecture one: the server-side integration

The tool lives on the vendor's infrastructure and connects to your account through an integration record, usually with token-based authentication or OAuth 2.0. Oracle's own NetSuite AI Connector works this way, exposing NetSuite through MCP to whatever model you point at it.

The integration acts under a role you assign. That is the whole security boundary, and it is a real one, because you control the role.

In practice you control it in theory. Building a minimal role for an AI integration means enumerating in advance every record type and permission the agent will ever need. Get it wrong and the tool fails on a Tuesday with a permission error that names a record nobody expected to be involved. The path of least resistance is to widen the role until the errors stop, and the widening is permanent because nobody goes back to tighten it once it works.

So the real question for this architecture is not what the role can do on paper. It is: has anyone looked at that role in the last six months, and does it still reflect what the tool actually needs?

The genuine advantage is that the boundary exists at all and can be inspected. You can open the role, read the permission list, and know. That is more than the other two architectures offer.

Architecture two: the browser extension in your session

The tool runs as an extension in your browser, inside the NetSuite tab you are already logged into. It reads data by issuing SuiteQL and REST calls with the session cookies your browser already holds.

This has one strong property and one that gets misread as strong.

The strong property: the agent cannot exceed your permissions. There is no separate integration role to configure, no possibility of the tool holding access you did not intend to grant, and no standing credential that keeps working after you leave the company. When your access is revoked, the agent's access is revoked, because they are the same access. If you switch to a restricted role, the agent switches with you and its queries start failing the way yours would.

The property that gets misread: "your session cookies never leave the browser". This is true of a well-built extension and it is worth confirming, but it is not the interesting risk. Nobody's realistic threat model is a vendor stealing session cookies. The interesting risk is what happens to the data the agent reads, which we will get to.

The real limitation of this architecture is the inverse of its strength. The agent has exactly your permissions, and if you are an administrator, so is it. There is no way to run it with less access than you have while you are the one running it. The mitigation is not technical. It is that you should not be doing routine work as Administrator, which was true before AI agents existed and is now more expensive to ignore.

Architecture three: the desktop MCP client

You connect a desktop AI application to NetSuite over MCP and work from there. Depending on the implementation, the bridge either holds its own credentials, which makes this architecture one wearing a different coat, or it proxies through an authenticated browser session, which makes it architecture two with a longer wire.

Find out which. The answer is usually in the setup instructions: if configuration asks you for a consumer key and a token, credentials are being stored somewhere and the security question is where. If it asks you to be signed in to NetSuite in your browser, you are in the second model.

Neither is wrong. But the two have completely different answers to "what happens when I leave the company", and you should know which one you bought.

The question that actually matters

Set the connection aside. The agent reads a saved search result, a customer record, a script. That data has to reach the model, and the model is not in your account.

This is the exfiltration surface. It is not the session cookie, not the integration token, and not the connection protocol. It is the payload.

So ask, in this order:

1. Which model provider receives the data? Anthropic, OpenAI, a self-hosted model, or the vendor's own gateway that forwards to one of the above.
2. Does the vendor retain the payload? "We don't store your data" needs a follow-up: not stored where, and for how long? A stateless proxy that forwards and forgets is a meaningfully different claim from a system that logs requests for debugging with a thirty-day retention.
3. What does the vendor keep instead? There is always something. Usage counts, account identifiers, an email address for billing. Get the actual list.
4. Is the provider's zero-retention or no-training policy in place, and is it the vendor's contract or yours? If the vendor holds it, you inherit whatever they negotiated, and you inherit it silently if they change providers.
5. Can you supply your own API key? If so, the payload goes from your browser to a provider you have a contract with, and the vendor is out of the data path entirely. This is the cleanest answer available, and it is usually an enterprise-tier feature because it costs the vendor their margin on inference.

None of these questions are hostile. Any vendor who has thought about the problem can answer all five in a sentence each. A vendor who deflects to a compliance badge has told you something.

The audit trail problem

Here is the one nobody puts on a product page, and it applies to every architecture above that runs under a human's identity.

NetSuite records who changed a record. System Notes will show that a field was modified, when, and by which user. If an agent acts inside your session, System Notes says you did it. Not "an agent acting for you". You.

That is fine right up to the moment it is not. Six months from now, someone asks why a vendor record's payment terms changed on a specific date. The audit trail names a person. That person genuinely does not remember, because they approved a batch of agent-proposed changes in a side panel on a busy afternoon and the specific one is not in their memory at all.

There is no clean fix inside NetSuite. The mitigations are all partial and all worth doing:

• Keep the agent read-only by default and require explicit approval per write. This is table stakes and any tool that does not do it should be disqualified. It does not solve the attribution problem, but it means every change was at least seen by a human at the moment it happened.
• Give the agent a distinct role, and use it for agent sessions. You lose some convenience. You gain a filterable identity in System Notes, which is the only mechanism NetSuite gives you for separating the two.
• Prefer tools that write a durable local log of what they proposed and what you approved. This is outside NetSuite's audit trail, so it will not satisfy an auditor on its own, but it will answer the question six months later.
• Never let an agent write to production under a role that can also change permissions. If a mistake compounds into a permission change, you have lost the ability to reason about everything after it.

The pattern to internalise: an agent that acts as you inherits your accountability along with your access, and NetSuite has no vocabulary for the difference.

A checklist you can send to a vendor

Copy this into an email. The answers should take one reply.

1. Which NetSuite role does the agent act under, and who configures it?
2. Are credentials stored anywhere outside my browser? If yes, where and in what form?
3. What happens to the agent's access when my NetSuite user is disabled?
4. Which model provider receives record data, and under whose contract?
5. Is request content retained by you at any point, including for debugging or abuse monitoring? For how long?
6. What data about my account do you keep, exactly?
7. Can I supply my own model API key, and on which plan?
8. Are writes read-only by default with per-action approval, or is there a mode that writes without confirmation?
9. Does the agent's activity appear in NetSuite's audit trail as a distinct identity, or as me?

Question nine is the one that will get the vaguest answer, and it is currently the most honest test of whether a vendor has thought past the demo.

Where we stand

We build one of these tools. MokuBot is architecture two: it runs in the Chrome side panel inside your NetSuite session, under your role, read-only until you approve a write. Which means our answer to question nine is the same uncomfortable answer as everyone else's in this category, and we would rather say so than pretend the problem is solved.

The reason to prefer the in-session model is not that it is invulnerable. It is that it removes a class of question entirely: there is no standing integration role to audit, no credential to rotate, and no access that outlives your employment. What it leaves you with is a smaller, sharper problem, which is the payload and the audit trail.

Small and sharp is a better place to be than broad and vague. But it is not the same as solved, and any vendor telling you otherwise, including us, should be made to answer the nine questions.