Why "can use / can't use" isn't enough
One scene from the OpenAI paper. Inside the same company, new hires send 8–9 more messages per week and executives send fewer than average. Executives ask briefly about topic overviews, fact-checks, legal and finance; new hires produce documents, code and email drafts. They're using the same tool in completely different ways.
So a single line — "all employees permitted to use ChatGPT" — decides nothing. Whether a new hire's draft can go straight to a customer, whether company revenue data can go into an executive's finance question, whether AI can change the booking system directly — these are all different questions.
That's why we split permissions into twenty. It looks like a lot, but they're things you already decide when hiring one human employee. Ask the AI the same questions.
The 20 permissions — five groups
| Group | Permissions | AI default |
|---|---|---|
| Touching data (5) | Read · Create · Edit · Delete · Download | Read O · Create (draft) O · Edit △ · Delete X · Download X |
| Moving data (3) | Share · External send · Customer contact | All X (a person presses send) |
| Execution and sign-off (5) | Execute · Approve · Sign off · Purchase · Contract | All X |
| Access (5) | Systems · Data · Models · Tools · Agents | Only what's listed (no default list = no access) |
| Time and delegation (2) | Temporary permission · Delegate/revoke | Temporary requires an expiry · Revoke must be immediate |
The reason the defaults are conservative is simple. You can always widen later, but narrowing after an incident is too late. Run the first month on "read + draft" only, and widen one cell at a time as the human edit rate drops.
The three-party matrix — why people, AI and agents are written separately
Even "AI" has to be split in two.
- AI (conversational) — answers when asked. Getting a draft in a ChatGPT window. It doesn't move on its own.
- Agent (executing) — given a goal, performs several steps on its own. Reads an inquiry → looks up the customer database → composes a reply → sends it. AI with execution rights.
The matrix looks like this. Twenty rows × three columns, O/△/X in each cell.
| Permission | Person (owner) | AI (conversational) | Agent (executing) |
|---|---|---|---|
| Read | O | O | O (designated scope) |
| Create | O | O (draft) | O (draft) |
| Edit | O | △ (suggest only) | △ (after human check) |
| Customer contact | O | X | △ — this is the fork |
| Execute | O | X | △ — only what's reversible |
| Sign off · Purchase · Contract | O (within limits) | X | X |
| Delete | O (after approval) | X | X |
The two highlighted cells are where every company deliberates longest. May the agent text customers directly? May it place orders? The answer comes from the three criteria in Part 3 (is it reversible · who gets hurt if it's wrong · is it judgment or processing).
Clinic scenario — the permission table for a booking-confirmation AI
Say a clinic decides "let AI send tomorrow's patients their confirmation texts." The permission table comes out like this.
- Read O — Tomorrow's booking list only (name, time, department). Medical records and test results aren't on the access list = no access.
- Create O — Confirmation text drafts. Template-based; only the patient's time is filled in.
- Customer contact △ — First month: drafts only, the front desk sends. From the second month, auto-send for "confirmations" only; "change and cancellation notices" stay with people.
- Edit X — AI doesn't change booking times. If a patient replies asking to change, it hands off to the desk (escalation).
- Delete · Sign off · Contract X — Not applicable; explicitly X in the list.
- Temporary permission — "Bulk holiday-closure notice" before a long weekend is a 3-day temporary permission.
This one table becomes the first page of a clinic CRM build (Korean). The system is built to this table, and what isn't in the table the system can't do.
When permissions change — keep just three things
- Version — The permission table is a dated document. When it goes from the "September 8 edition" to the "October 1 edition," one line should say what got wider.
- Revoke — A widened permission must be reversible immediately. If reversing needs a developer, the design is wrong. It should be a single switch.
- Log — There must be a record of what the AI did with that permission. "Who · when · with what data · did what." Part 9 (Korean) covers the minimum seven log types.
On MAEUM SaaS (managed), permission-table changes are included in the monthly fee. No separate quote for widening or narrowing — that's what makes you actually adjust it.
Sources — what the paper says / MAEUM's extension
- What the paper says: AI usage intensity and purpose differ systematically by level and role (new hires +8–9 messages/week; executives for briefings). Usage is spread across the organization but not uniform. (Chatterji et al., OpenAI 2026-08-11, original PDF)
- MAEUM's extension: The 20-permission classification, three-party matrix, default rules and clinic scenario. Not in the paper; our design method.
KRW is authoritative; USD figures are approximate. SEO and AI-search visibility work is included in every build at no charge. The demo is free — try it, and sign only if you like it.