How to Set Up a View-Only Role for Sonar (and a Few Security Rules of Thumb for AI in NetSuite)

One of the first questions NetSuite admins ask us about Sonar, the free AI assistant that runs directly inside NetSuite as a Suitelet, is a fair one: how do I let my team use this without handing an AI tool the keys to my ERP?

The honest answer is that Sonar was built with this worry in mind. It runs through the authenticated session of whoever is logged in, which means by default it honors the roles and permissions that user already has. There is no separate database and nothing gets stored outside NetSuite. It simply passes data between your account and the AI provider you configured with your own API keys.

That said, we have been inside enough NetSuite environments to know that "it uses your existing permissions" is not always a comforting sentence. Plenty of admins are perfectly fine with a user creating records by hand but are not quite ready to extend that same power to an AI tool, and frankly, that instinct is a healthy one. The catch is that just creating a view-only role is not enough on its own. People forget things. Somebody will absolutely open Sonar one morning, pre-coffee, still logged into their full-access role, and now your careful plan depends on them clicking the right button in a confirmation dialog.

The good news is there are a few easy steps that solve this completely. By pairing a view-only role with a restriction on Sonar's script deployment itself, you can guarantee that Sonar only ever runs from the read-only role, no toggling discipline required. Here is how to set it up.

A Quick Word on What Sonar Already Does for You

Before the steps, it helps to know what is built in, because it explains why this setup holds together. Sonar operates entirely inside NetSuite's native permissions model, so it can only see and do whatever the logged-in role allows. Any action that would create, update, or delete a record triggers a confirmation dialog first, whether you are in sandbox or production, admin or not. And every SuiteQL query Sonar runs is visible in the app, so you can inspect, copy, or rerun anything it did. No smoke or mirrors.

Those defaults keep a human in the loop. The steps below go one better and remove the possibility of unintended writes altogether.

Step 1: Create a View-Only Role

Head to Setup > Users/Roles > Manage Roles and create a new role, or customize a copy of the existing role closest to what your team needs. Give it a name nobody could mistake for a working role, something like "Sonar View Only." Future you, six months from now, staring at a list of forty roles, will appreciate the clarity.

Step 2: Set Every Permission to "View" and Remove the Full-Only Permissions

Work through the role's permission subtabs (Transactions, Reports, Lists, Setup, and Custom Records) and modify each permission level to View.

Here is the part that trips people up. Some NetSuite permissions do not offer a View level at all. Their only option is Full, which rather defeats the purpose of a read-only role. For those, do not leave them sitting on the role hoping for the best. Remove them entirely. When you are done, the role should contain nothing but View-level permissions, full stop.

This is also a natural moment to practice a little least-privilege hygiene. If a category of data has no business being visible to this group (payroll comes to mind), leave it off the role, and Sonar will not be able to see it either.

Step 3: Restrict Sonar's Script Deployment to the View-Only Role

This is the step that makes the whole thing foolproof, and it is the one most people skip.

Open the script deployment record for the Sonar Suitelet and update the audience so it is set to trigger only for your view-only role. That includes removing the ability for an administrator to use it. Yes, even you. Especially you, honestly, since the admin role is the one with the most room to do damage in a distracted moment.

With the audience locked down this way, the "what if someone forgets to toggle roles" problem simply stops existing. A user sitting in their normal working role cannot launch Sonar at all. The only door into the tool is the view-only role, so there is no scenario where Sonar runs with create, edit, or delete permissions behind it.

Step 4: Assign the View-Only Role to Employee Records

Open the employee record for each person who should have Sonar access and assign them the view-only role on the Access tab, alongside their existing roles. Using Sonar now becomes a deliberate act: switch to the view-only role, open Sonar, and explore to your heart's content. When it is time to actually create or edit something, they switch back to their working role and make the change through the standard NetSuite UI, with their own hands on the keyboard.

Step 5: Run a Test to Confirm It Actually Works

We would never suggest you take a configuration's word for it, and neither should you. Two quick tests confirm both layers are doing their job.

First, confirm the write-enabled roles are locked out. While logged in under a role you removed from the deployment audience (your administrator role is the important one here), type "page: sonar" into NetSuite's global search and try to access the Suitelet. If Step 3 was done correctly, NetSuite should send back a notice that you are unable to access the page. That error message is the whole point, so enjoy it. If the Suitelet loads instead, go back and double-check the deployment's audience settings.

Second, confirm the view-only role cannot write. Toggle over to the view-only role, open Sonar, and ask it to create a test record. Something like "create a new lead record called Test" works fine. Sonar will attempt the action, but the output should show it was unable to create the record, because the permission simply is not there. The AI can try all it wants. NetSuite's permissions model gets the final say, which is exactly how it should be.

If both tests pass, your lockdown is airtight. The roles that can write cannot reach Sonar, and the role that can reach Sonar cannot write.

The End Result

What you have built is restricted access to Sonar where the tool can only be used from the view-only role and cannot accidentally be used with the role holding real write permissions. Even if a user never thinks about role toggling again in their life, the script deployment audience does the enforcement for them. Your team keeps all the upside (fast answers, on-demand reports, the freedom to poke around their own data without filing a ticket) while the write-access risk in production is removed by design rather than by hoping everyone stays vigilant.

A Few Security Rules of Thumb for Sonar and AI in NetSuite

The view-only setup is the foundation. Here are the habits we recommend building on top of it, learned from watching a lot of teams adopt AI tools with varying levels of caution.

• Keep production read-only and save the write actions for sandbox. If you want to experiment with Sonar creating records, drafting scripts, or modifying files, do it in a sandbox or test drive account first. Never allow anything beyond read-only in production until a workflow has been thoroughly tested somewhere consequence-free, and even then, keep write access rare and deliberate. Bravery is a fine quality in many areas of life. Production ERP data is not one of them.
• Practice least privilege, even for AI. Sonar inherits whatever the active role can do, so the question of what a role should see matters just as much for AI use as it does for regular use. Resist the urge to build one giant read-only role for the whole company. Build view-only roles scoped appropriately for each team, the same way you would for anything else.
• Actually read the confirmation dialogs. For anyone who does retain write access through Sonar (in sandbox, ideally), treat the confirmation dialog as a real control rather than a formality. Be stingy with the "always allow" option. Approving one action at a time keeps a human meaningfully in the loop, which is the entire point.
• Inspect the queries. Sonar shows you every SuiteQL query it runs to answer a prompt. Make reviewing them part of your workflow, especially for reports that will inform real decisions. Once you have verified a query is pulling exactly what you think it is pulling, you can save it and reuse it with full confidence in what is included and what is not.
• Verify outputs against native NetSuite reports. AI is genuinely useful, but it is not guaranteed to be right every time, and it will occasionally be wrong with tremendous confidence. Tie AI-generated figures back to NetSuite's own reports, ask Sonar to walk through its methodology and assumptions, or get a second opinion from a different model when the stakes are high.
• Know what your audit trail will and will not show. Actions taken through Sonar run through the user's authenticated session, so system notes attribute changes to the user, the same as any other Suitelet-driven change. There is no separate flag marking a change as AI-assisted. That is one more argument for restricting write access, since your audit trail treats these changes exactly like human ones.
• Keep a human in every script deployment. Sonar is legitimately good at drafting and troubleshooting SuiteScript, but by design it cannot create script records or deployments on its own. A person has to do that part, and we would encourage you to keep it that way in spirit as well as in mechanics. Use Sonar to write and iterate on script files in sandbox, and keep yourself in the middle of every deployment decision. Anchor Group is a NetSuite consulting partner that helps ensure proper deployment of NetSuite customizations.
• Know where your data goes. Sonar passes data between NetSuite and your chosen AI provider using your own API keys, and it stores nothing outside NetSuite. Make sure your team understands your provider's data handling terms, and choose your provider and model in Sonar's settings on purpose rather than by default.

The Bottom Line

The safest way to adopt AI inside your ERP is to lean harder on the security model you already have, and that is exactly how Sonar was built. It respects NetSuite's native roles and permissions, confirms every write, and shows its work. A view-only role plus a locked-down script deployment takes it one step further, turning "please remember to switch roles" from a policy you have to enforce into a guarantee you never have to think about again.

Ready to try it?

Request the free Sonar bundle on the Anchor Group Sonar landing page and we will get it provisioned to your account, then walk through setup with you (role configuration included) on a short install call. Bring your questions. We have probably heard them before, and we are happy to answer the ones we have not.