Your Integration Token Is an Admin

The Railway customer who lost his database this week had a CLI token created for one purpose: adding and removing custom domains.

That same token had permission to delete production volumes.

He didn’t know.

The token-creation flow didn’t tell him.

NetSuite works the same way.

How NetSuite tokens actually get their permissions

NetSuite's auth model is a chain:

Integration Record → Token → User → Role → Permissions

The token itself has no permissions.

It inherits them.

In most NetSuite accounts, that role is Administrator — or close enough that the difference doesn’t matter.

That means anything holding that token — your CI pipeline, your integrations, your AI agents — effectively has full control over your account.

The failure mode

A developer needs an integration to pull invoices and post payments.

They generate a token.

They’re asked which role to use.

They pick the one they already have.

Administrator.

The integration works.

It gets deployed.

Now that token can:

• delete records
• modify scripts
• change permissions
• create new tokens
• alter system configuration

The integration only needed to read invoices and create payments.

The token can do everything.

Why this keeps happening

The UI doesn’t show consequence.

When you create a token, NetSuite:

• asks for a role
• does not summarize permissions
• does not warn about scope
• does not highlight risk

So teams take the path of least resistance.

They use a role that works.

Custom roles take time.

Most teams skip it.

And nobody audits tokens after they ship.

M2M doesn’t fix this

OAuth 2.0 M2M flows are cleaner than TBA.

Certificates are more secure than shared secrets.

None of that changes the role.

A perfectly implemented M2M integration can still run as Administrator.

The authentication improved.

The authorization didn’t.

What “scoped” actually means

A properly scoped role answers four questions:

What records can it access?
Only the specific record types it needs.

What actions can it perform?
View, Create, Edit — rarely Delete.

What system-level access does it have?
None. No setup permissions.

What restrictions apply?
Subsidiary, department, or segmentation.

If you can’t answer those questions for every token in your account, you don’t know your blast radius.

The 20-minute audit

Go to:

Setup → Integration → Manage Integrations

For every integration:

• Does it still need to exist?
• What role is it using?
• What does it actually do?

If you don’t know what a token does, disable it.

If something breaks, you just found a hidden dependency.

If nothing breaks, you just removed unnecessary risk.

Takeaway

This isn’t an edge case.

This is normal.

A token that can do everything will eventually be used to do everything.

Not because someone intended to.

Because nothing stopped it.

Scope your roles.

Audit your tokens.

Assume every token will eventually be used in a way you didn’t anticipate — and design so the worst-case call is survivable.

Written by Adaptive Solutions Group — NetSuite consultants who audit integrations, permissions, and system risk as part of every SuiteRX review.