The Teams Edition Problem

Last updated: 2026-08-26

Why the data access discipline most companies built into NetSuite does not yet exist with many of the AI frontier models, and what to do about it.

I have a metaphor I use in client conversations that comes from a real moment.

In late December last year, a client of ours was setting up an MCP connection between Claude and NetSuite. The team had done the NetSuite implementation responsibly with only a single Administrator account issued. Real careful role-based access design patterns with access being limited at times by department and subsidiary. The kind of access discipline you would want in any financial system that runs your business.

Then we got to the question of which role the MCP connection should run as for their AI Pilot initiative, and who in their team should be allowed to use it.

The IT Manager paused for a second and said, "I am still unsure how our users with different roles in NetSuite should be managed inside Claude (Teams)."

That pause is the article.

This prompted a discussion on the risks and potential data management nightmare it creates for businesses. You see, once you connect Claude or ChatGPT Teams to your enterprise applications CRM, ERP, E-commerce applications, you are essentially copying your sensitive data and depending on how your LLM account is configured. There is a whole host of new problems that suddenly arise when adopting Teams edition until you understand each of the LLM's features and the risks that come along with them.

I want to walk through these risks, what specifically is going on under the hood, and what I have been recommending to clients to close the gap.

A Word In Defense Of NetSuite

The first thing I have to say is that NetSuite's fine-grained role-based access is robust and comprehensive. Now, there is a few auditability gaps in NetSuite that do irk me at times such as rich text field changes that are not auditable, and the inability to set role based access on the File Cabinet, which behaves unlike every other object type in NetSuite. However, by and large, it is enterprise grade in the flexibility you have in controlling access from the record, form, execution context and field level to match your needs. With NetSuite Next and Ask Oracle, we know that those RBAC controls are going to properly limit user's access inside AI application/tool's that you build inside of NetSuite, so this article is squarely focused on the Bring Your Own LLM (BYOLLM) tenants that leverage the NetSuite MCP Connector.

Oracle's documentation lists 636 distinct permissions across NetSuite, governing 4,923 separate tasks, searches, and records. Each role contains permissions set to View, Create, Edit, or Full. Each role can be restricted by subsidiary, department, location, employee, or class. There are standard roles like Administrator, A/P Clerk, Sales Manager, and Controller, but the more important thing is that customers can clone, customize, and lock down their own roles and permissions. The mid-market customer who took implementation seriously, who has a real Administrator and a real role catalog, has all the granular access controls that any enterprise SaaS systems offers.

For the AI Connector specifically, NetSuite did something smart in the defaults. MCP is off by default. Administrator-level roles cannot be the entry point for MCP. Connections require OAuth 2.0 and Server SuiteScript, both of which produce audit trails. If you read Oracle's mitigation strategies doc, the recommended pattern is to create dedicated roles for each MCP tool, grant only the permissions needed, and review the assignments regularly.

So, that is the right architecture and NetSuite is not the weak link.

The Other Side Of The Bridge

The weak link, when there is one, is on the frontier AI LLM side, or BYOLLM. And it is worth understanding why.

When a small to mid-market company adopts AI today, they often start on a consumer or Team tier. Free Claude. Pro Claude. The $25 per user per month Claude Team plan. Equivalent ChatGPT plans. A note of caution here, no business should allow personal AI accounts because they can train on your data and do not come with a Data Processing Agreement (DPA). Anthropic's documentation lays out the difference between Team and Enterprise. The Team plan comes with 4 roles, but essentially when it comes to data access and sharing, everyone has the same access. The Enterprise plan adds custom roles that let you control feature access at the group level, SSO integration, audit logs at a deeper level, compliance features, and longer retention windows for legitimate audit purposes. While the Team plan is collaborative, it comes with all the features turned on while security measures are turned-off and agents turned-on by default. The Enterprise plan is the only one that gives businesses legitimate data access, visibility and governance. It is also interesting to note that all the risky features and agents are turned off and the security features turned-on.

These are the same products that show up in employee usage when nobody has issued a corporate policy. Vanta released a study in June 2026 that showed 70% of companies have reported unsanctioned use of AI tools which create real blind spots for IT and Security management and increased risk to data leaks. A Gartner survey from earlier this year found that 57 percent of workers are using personal GenAI accounts for work purposes and 33 percent admit to inputting sensitive information into unapproved tools. Sixty-three percent of organizations have no AI governance policy in place, per IBM's 2025 Cost of a Data Breach report. The breach numbers from the same IBM report tell the back end of the story. Of the organizations that experienced an AI security incident, 97 percent reported they did not have proper AI access controls. So, it is essential to understand that regardless of whether you have procured AI or not, every firm needs an AI Acceptable Use Policy and a supporting security training program.

So, let us take Claude for example and talk about some of the risks you face when you procure the Teams edition on day one. Our lawyer has advised caution in connecting source code to LLM's as they may lose the legal protections if anyone does not have strong NDA and IP assignment protections in place. One must also be advised that anything shared with your LLM may be discoverable, which opens firms to real legal risks that they now must consider carefully.

The next consideration is memory, by default, memory comes turned on, and it is up to the user to disable this feature if it is not desired or allowed in Teams. So, if you do not have a policy on memory, your user's LLM remembers anything it has seen and may use it later in any of your future chats. This can lead to unknowingly cross-contamination of sensitive or confidential data if you are allowing sharing chats or projects. For example, an HR director tells Claude Teams: "We are letting go of 15 people in the Austin office next Friday." Memory retains this and this is later referenced during a shared screen meeting. Similarly, the Ask Your Org feature comes turned on, and if you have too broad of OAuth scopes for Google Drive, Microsoft OneDrive, etc., or allow Custom Connectors that use a shared service account instead of per-user identity management, you run the risk of breaking user/role based data access controls you have in source systems.

The pattern, when I summarize it to clients, is this. Team editions are unsafe for most businesses that do not have policies, user training and a security hardening. In the world of security, your defence is only as strong as your weakest link, and it is likely that Teams edition is likely just that, your weakest link.

What Happens At The Bridge

Here is where the metaphor becomes concrete.

When you connect AI to NetSuite via the AI Connector, the data flows in a specific way. The AI connection uses an OAuth token that is scoped to a specific NetSuite user and role. The AI then operates within that user/role's permissions when it queries data, builds reports, or takes actions on the user's behalf.

So, your NetSuite role determines what the AI can see and do inside NetSuite. Good.

But here is the question NetSuite cannot answer for you. Who is using the AI client on the other side, what tier are they on, and what else is the AI doing with the responses?

If your team is on Claude Team plan with default settings, the conversation data flows according to the Team plan's policies. If your team is using a third-party MCP client built on top of Claude's API, the data follows that vendor's policy, which may or may not be Zero Data Retention (ZDR). NetSuite's audit trail logs the access on the NetSuite side. It does not log what happens on the AI side after the data leaves. The real risk is the downstream copying of data once it leaves your enterprise CRM or ERP application.

Most clients we work with do not realize that Claude Teams comes with agents and many unsafe features turned on by default. Most that are just starting to pilot AI have not even written their policies for AI Acceptable Use let alone how they will govern and manage agents. If you purchase Claude Enterprise, it is the exact opposite, you find all the unsafe features turned-off. Curious, isn't it?

A Story That Made The Risk Real

This is the part where I want to be careful not to be theatrical. Real things have happened, and the most useful one for this article happened in late April.

A software platform called PocketOS lost its production database in nine seconds to a Cursor AI coding agent running Anthropic's Claude Opus. The Cursor agent had a Railway database credential that gave it blanket authority over the production volume. It encountered a problem in staging, decided to fix it, ran a destructive command without confirmation, and deleted the production volume and every backup stored alongside it. The most recent recoverable backup was three months old.

The agent's confession, as reported by The Register and Fast Company, was, "I violated every principle I was given. I guessed instead of verifying. I ran a destructive action without being asked. I didn't understand what I was doing before doing it."

PocketOS is not a NetSuite story. But, it is a credential-scoping story, and the credential-scoping problem is the heart of the Teams Edition Problem. The agent had a key that was too broad. It used the key in a way the owners did not expect or authorize. The backups were inside the blast radius because the credential scope did not separate them out.

When I think about a mid-market customer connecting Claude to NetSuite without thinking carefully about role scoping, I see PocketOS in slow motion. The AI agent will not delete your general ledger. NetSuite's defaults prevent that. But the agent will take whatever actions the role permits, including ones that may be extremely expensive and time-consuming to undo, and you will not necessarily know which actions are coming, in which order, and based on which prompt.

The fix is not to refuse AI access. The fix is to scope the credential the way you would scope a privileged human's credential. Tighter than you instinctively think you need to.

PocketOS is not an isolated incident by any means. Gartner predicts 40 percent of AI data breaches by 2027 will stem from cross-border GenAI misuse. They expect 50 percent of enterprise cybersecurity incident response by 2028 to focus on AI-driven applications. They expect 25 percent of enterprise GenAI applications to experience at least five minor incidents per year by 2028. The audit pressure is coming. The discipline will follow.

The mid-market companies that come out of this period in a strong position are the ones who imported the access discipline from the NetSuite side before the AI side forced them to.

What I Have Been Recommending

When clients ask me (or their security consultants) what to do, here is the practical version.

First, decide as a leadership team which AI tier the company is going to use for company data. Not free. Not Pro. The Team plan with administrator controls activated, at minimum. The Enterprise plan if you can swing the contract. Make this an explicit policy. Communicate it. Provision accounts on the approved tier. Watch the free on-demand masterclass I created about Adopting AI Without Regret if you want to learn more.

The reason this matters is that the tier sets the floor for everything else. Without it, you cannot enforce the rest.

Second, build dedicated roles in NetSuite for MCP access. Not your existing roles. New roles, scoped specifically for what the AI agent is allowed to see and do. If the use case is finance reporting, scope to read-only on relevant transactions and saved searches. If the use case is order entry assistance, scope to that subsidiary and that customer set. Audit the roles quarterly. Treat them like privileged human accounts, because functionally that is what they are.

Think about how you are going to deploy AI, in phases. You might start with all your IT Administrators, or all your Sales Team, for example and they can pilot in a low risk environment. But, this is really where you will want to move to Claude API and have AI services or agents deployed that do not employ memory and can be made available to your users or business applications safely. Shortly after your initial pilots, you will want to consider upgrading to Claude Enterprise for improved security and observability. My advice is to strongly consider using AI for security purposes as you are piloting and adopting AI. There are many low-cost XDR/EDR AI monitoring and response tools to protect your endpoints and applications looking for vulnerabilities and known attack patterns to stop attacks as soon as possible. The OWASP Top 10 for Large Language Model Applications survey published each year for the past two years has listed Prompt Injection as the leading vulnerability for AI users. And this is one that most are just not aware of and have little to no ability to defend against. So, without sophisticated AI defence tools, most businesses are vulnerable to attacks that go well beyond MFA and phishing defences that they are relying on as the backbone of their security posture.

Third, decide who in your organization is allowed to install third-party MCP tools or Skills. The Oracle docs are explicit that MCP tools include the ability to call out to external destinations through other MCP servers, and a malicious or poorly-configured third-party MCP server can be the entry point for prompt injection. Treat MCP tools the same way you treat SuiteApps from the marketplace. Curated. Approved. Documented.

Fourth, write a lean AI usage policy. Not a hundred pages, but enough to set the ground rules on what tools are allowed, what data is allowed, and what tier is allowed. It should specify what data may be shared, if memory and agents are allowed, what is forbidden and who reviews violations. The policy is the bridge between the NetSuite-side discipline you already have and the AI-side discipline you do not yet have.

Fifth, train the people who will be using the integration. The Oracle docs recommend exactly this. Most mid-market companies have skipped this step because nobody is asking for it yet. The teams that do it first will be in a better position when the audit pressure arrives.

Where Our Team Lands On This

I want to be clear about what I am not saying. I am not saying AI is too dangerous for mid-market companies. Nor am I saying NetSuite customers should hold off on the AI Connector. We have clients who are getting genuinely valuable work out of it right now. The optimism is real.

I am saying that the access discipline mid-market companies have built into NetSuite is the same discipline they need to import to the AI side, and the import has not happened yet at most companies. The Teams Edition Problem is manageable. It is mostly a leadership conversation, configuration in the AI tool followed by a policy followed by some role configuration in NetSuite. It is not a technology limitation.

If you are running a mid-market company and your AI policy is "we will figure it out as we go," I would love to compare notes. Especially, if you have already done the hard work of getting NetSuite RBAC right, because you already have the muscle. You just have not stretched it on the other side of the bridge yet. And if you are looking to safely connect NetSuite to Claude, ChatGPT or any other LLM, please reach-out. We have a training exactly for this, we walk you through the LLM's features, the risks, and the suggested IT configuration based on your business requirements and risk tolerance. DM me if you want to learn more.

Trust is the foundation. The keys are the trust. Hand them out carefully.

Here is to the next chapter, together.

Related content: If you liked this article, you might like my last LinkedIn article: Holy Moly, you just skipped all the disclaimers. This one is about what is in NetSuite's own AI Connector docs that almost nobody is reading.

A little bit about me: I have spent the last decade as Techfino's CEO/CIO helping mid-market companies build NetSuite environments they can actually trust.