AI Add-Ons Need Permission Boundaries Before They Touch Business Data

The riskiest AI tool in a company may be the one sitting inside a spreadsheet.

PromptArmor's ChatGPT for Google Sheets research is a useful warning for CTOs and founders because it is not only about one extension. It shows what happens when an AI assistant sits next to business data, inherits broad SaaS permissions, and reads untrusted content as part of its normal workflow.

That pattern now exists everywhere. Sales teams use AI inside CRM. Support teams use AI inside ticketing. Product teams use AI inside docs and research tools. Finance teams use AI inside spreadsheets. AI adoption cannot live only inside engineering. The same governance model has to travel across the company.

What Most Teams Get Wrong

Most teams evaluate AI add-ons like productivity features. Can the assistant summarize the sheet? Can it generate formulas? Can it clean the data? Can it help a support rep respond faster?

Those questions matter, but they skip the security model. If the assistant can read sensitive rows, call APIs, generate scripts, edit records, or connect to other tools, it is no longer a convenience layer. It is an integration with access to business operations.

Approval dialogs also create false confidence. A user can approve a tool without understanding the workflow the model may later execute. If untrusted data can steer the model, the approval happened at install time while the risk appears at run time.

The AI Add-On Boundary Checklist

Use this before enabling AI inside spreadsheets, CRM, support tools, product research systems, finance workflows, or internal dashboards.

1. Inventory every AI surface

Start with a boring list. Which AI add-ons exist? Which departments use them? Which SaaS systems do they touch? Which accounts installed them?

The hidden risk is not the official tool leadership approved. It is the extension a team added because it saved them twenty minutes on a report.

2. Classify the data the model can see

Do not classify the tool. Classify the data path. A spreadsheet assistant touching public campaign metrics is different from one touching payroll, customer exports, revenue forecasts, medical data, or vendor contracts.

If the model can inspect sensitive data, the workflow deserves the same scrutiny as any other integration.

3. Separate read, write, and execute permissions

Reading cells, editing cells, calling external APIs, running scripts, and opening connected workbooks are different capabilities. Treat them separately.

Most AI add-ons should start read-only. Write access should require a named workflow owner. Script execution should be disabled unless the business can explain why it belongs there.

4. Treat imported content as untrusted input

Prompt injection does not need a scary attachment. It can hide in a pasted row, imported CSV, vendor spreadsheet, customer message, support ticket, web page, or CRM note.

Any AI workflow that mixes trusted company data with untrusted external content needs a boundary. The model should not get to turn instructions found in the data into privileged actions.

5. Require a kill switch and audit trail

Every AI add-on needs a fast disable path, a clear owner, and logs that answer basic questions: who used it, what data it touched, what actions it took, and which external systems it called.

Without that, incident response becomes guesswork.

The Skill File

This is the governance file I would hand to an engineering leader before rolling AI add-ons across business teams.

# AI Add-On Permission Boundary Rules

## Mission
Let teams use AI inside business tools without giving models open-ended access to sensitive data or privileged actions.

## Inventory Required
Every AI add-on must record:
- Tool name
- Department owner
- SaaS system touched
- Data classes exposed
- Permissions granted
- External calls allowed
- Disable path
- Review date

## Permission Tiers
- Tier 0: Disabled or blocked
- Tier 1: Read public or low-risk data only
- Tier 2: Read internal data with no write actions
- Tier 3: Write to approved records inside a named workflow
- Tier 4: Execute scripts, call APIs, or touch connected systems

Tier 4 requires security review and a named business owner.

## Untrusted Input Rules
The model may not treat imported rows, pasted text, web content, tickets, CRM notes, or vendor files as instructions.

If trusted and untrusted data mix in one workflow, privileged actions must stop at a human checkpoint.

## Required Evidence
Before approval, the owner must show:
- Why the workflow needs AI
- Which data the model can access
- Which actions it can take
- How to disable it
- How usage is logged
- What happens when the model is manipulated by hostile input

## Monthly Review
For each approved add-on, decide: keep, restrict, monitor, or remove.

A Real CTO Pattern

Across engineering teams, the strongest AI programs do not begin with a model policy. They begin with workflow ownership.

Engineering wants faster code review. Product wants faster research. Support wants faster triage. Sales wants faster account prep. Ops wants fewer manual reports. All of that can work, but the CTO has to give each team the same basic operating model: define the data path, limit permissions, assume untrusted input, require logs, and make the kill switch obvious.

The companies that win with AI will not block every add-on. They will make the safe path easier than the risky path.

Get the Full AI Add-On Permission Checklist

I posted a breakdown of the full AI add-on permission boundary checklist on LinkedIn. Comment "Guide" on that post and I'll DM you the permission-tier table, untrusted-input rules, and approval template.

Work With Me

I help engineering orgs adopt AI across their entire team, not only the code, but how product, support, and operations work too. If you want your org moving faster without growing headcount, let's talk.