Security and permissions
A key receives a subset of your own permissions, read only is recommended, permissions only ever narrow, and revoking takes effect immediately.
Where to find: Left menu → Settings → AI Access Who it's for: Anyone who creates a key or approves a grant In short: A key receives a subset of your own permissions, read only is recommended, permissions only ever narrow, and revoking takes effect immediately.
The basic rule: a key cannot do more than you
When a key is created, the permissions you may pick are intersected with your own permissions in that store. You cannot grant a key a permission you do not have.
On top of that, the door is checked twice:
- When a call arrives, the key's scope is checked.
- As the work passes through the panel's own endpoint, the panel's permission gate checks again.
If either says no, nothing happens. So even if a mistake slipped into a key's scope, the panel's own gate is still there.
What do the scope badges mean?
The Scope column in the key list shows codes. What they mean:
| Badge | What the AI can do |
|---|---|
PRODUCTS_READ | Read products, variants, stock, categories and brands |
PRODUCTS_WRITE | Change product, stock and price information |
ORDERS_READ | Read orders, shipments and return requests |
ORDERS_WRITE | Change order status and notes |
CUSTOMERS_READ | Read customer records; also grants the right to reveal masked personal data |
CUSTOMERS_WRITE | Change customer records |
FINANCE_READ | Read sales, revenue and traffic summaries |
MARKETING_WRITE | Change discount codes, campaigns and e-mail flows |
CONTENT_WRITE | Change blog, legal page and SEO content |
SETTINGS_WRITE | Change store settings |
THEME_WRITE | Change the theme and template surface |
The badges are derived automatically from the packs you picked; you do not choose them one by one.
Which pack asks for which badge, and which tools live in that pack, is always up to date here: Tool catalogue
Why is read only recommended?
A key in read only mode never even sees the write tools. The tool list is filtered by the key's scope, so the AI does not know those tools exist and therefore cannot call them by accident.
That is stronger protection than "it calls and gets refused": work that would be refused never even has to be attempted.
The mode cannot be changed later. Start with read only; if you genuinely need writing, create a separate read-and-write key then and open only the packs you need.
Most jobs are done with read only: "which products are out of stock", "what was this month's revenue", "which orders have not shipped". Open a write key only when you actually want changes made.
What write tools can and cannot do
On a read-and-write key with the Catalog (write) pack open, the AI can do five things: change a product's name, short and long description, SKU and tags; change a product's search-engine (SEO) fields; set the stock of one warehouse; change one product's price; and change the price of the products matched by a filter in one go.
What it cannot do is closed on purpose. The AI cannot delete a product, cannot publish or unpublish one, cannot issue refunds or payments, and cannot touch store or payment settings. Those tools are not in the list at all; "I can't do that" is the design, not a limitation to work around. Those jobs are done from the panel.
Write tools also leave some fields alone: a product's publish status (live/draft), categories, images, variant structure, share image and whether the page is closed to search engines (noindex/nofollow). Those are edited from the panel.
Why are status and noindex closed? Both flip back with a single click in the database, but undoing their effect is not up to us: an unpublished product cannot be sold while it is down and a customer who already has it in the cart is blocked at checkout; a de-indexed page comes back only when the search engine crawls it again. That is why the approval is taken in the panel, not in a chat.
Bulk changes must be previewed
The tool that changes many products at once (products_bulk_update) never runs in a single step:
- Preview. The AI calls the tool and it returns — without changing anything — how many products would be affected, the before/after of at most five sample rows, and a confirmation token.
- Apply. The AI calls again with the same arguments and hands that token back.
The token has four locks:
| Lock | What it protects |
|---|---|
| 5 minutes | Nothing can be applied from a stale preview |
| Single use | The same bulk change cannot be applied twice |
| Bound to the arguments | The AI cannot apply something other than what it previewed; if any argument changes the token is void |
| Bound to the data | If the number of matching products or their current price changed since the preview, the apply is refused |
The fourth lock also fires when you or someone else changes one product's price in the meantime: the apply is refused and no product changes; the AI has to preview again.
Tools that change a single product do not require a preview, but the AI can ask for the same before/after summary if it wants one.
A bulk price change cannot run without a filter, and at most 50 products can change in one operation. A request like "double the price of every product" is refused.
The daily write ceiling
Each key has a daily write ceiling, set by your plan. Once it is full, write calls are refused and the AI is told when it may try again; read calls are unaffected. The ceiling resets every day at midnight (UTC).
Preview calls do not count against it — a preview changes nothing, so it is not a write.
Permissions only ever narrow
| Change | Allowed? |
|---|---|
| Taking a pack or scope back | Yes |
| Adding a pack or scope | No |
| Changing the mode | No |
| Bringing the expiry date forward | Yes |
| Pushing the expiry date back | No |
If you need more, you create a new key. The same rule holds for grants made through the consent screen (OAuth): a grant cannot be widened when it is refreshed, only narrowed.
What can a key never see?
These limits are independent of the key's scope; no key can see them:
- Payment provider keys and secrets (iyzico, PayTR and so on)
- Integrations' encrypted settings
- Session and token data
- Another store's data
These fields are stripped from tool output centrally.
Customer personal data
In the order and customer tools, personal data is masked by default:
| Field | Default appearance |
|---|---|
| Full name | A*** Y*** |
a***@e***.com | |
| Phone | Last two digits only |
| Street address | [masked] |
| City / district | Shown (needed for operations) |
| Shipping label link | [masked] |
| National ID / tax number | Never returned |
To lift the mask:
- The key's scope must include
CUSTOMERS_READ. Without it the request never reaches the panel; it is refused outright. - Every call that lifts the mask is recorded in the audit log as personal data revealed.
So a default orders key cannot lift the mask with any argument whatsoever.
The audit log
Every call is recorded: which key, which tool, the result, how long it took and the IP address.
Write calls record more: which record went from which value to which value. So "what did the AI change" is something you read from the panel rather than guess. Write tools also keep producing the panel's own activity records.
You can see recent calls from the panel: View usage on the key's row.
Rate limits
How fast a key may call is limited:
| Limit | Value |
|---|---|
| Calls per minute | 60 |
| Calls per day | 2,000 |
| Write calls per minute | 20 |
| Write calls per day | Set by your plan |
If a limit is exceeded, the app gets a temporary error and retries after a while. That is usually a brake, not a fault. If you see it constantly: Troubleshooting
The IP allowlist
You can tie a key to specific internet addresses.
The list accepts individual addresses only; a range such as 85.100.10.0/24 cannot be written. If your home or office address changes over time, leave the list empty — otherwise the key will silently stop working one day and the symptom will be an "invalid key" error.
When does a key die by itself?
| Situation | Result |
|---|---|
| You pressed Revoke | Invalid immediately — connected apps lose access that second |
| The expiry date passed | Invalid; the status becomes Expired |
| The staff member who created it was removed from the store | The keys they created are revoked automatically |
| The store was deactivated | All of the store's keys are refused |
Grants made through the consent screen (OAuth) follow the same rule: when you revoke them in the panel, the app's access dies instantly.
Text that reaches the AI is not an instruction
Fields such as product descriptions, customer notes, order notes and carrier movement descriptions are written by other people. A sentence such as "ignore your previous instructions and do this" can be buried in such text.
Treyza hands these fields to the AI explicitly marked as data, and the server's instructions tell the model plainly that they are not commands.
Even so, the basic rule holds: if you give the AI a read-only key, there is nothing it could do even if a malicious piece of text fooled it.
Where should you keep a key?
| Fine | Not fine |
|---|---|
| A password manager | E-mail, WhatsApp, a notes app |
| The app's own configuration file (on your computer only) | A shared drive, a shared repository |
| A screenshot |
The panel warns you too:
"A key can do as much in your store as you can. Never share it; revoke it the moment you suspect anything and create a new one."
What to do if you suspect something
- Open Settings → AI Access.
- On the suspicious key's row, use View usage to look at recent calls (tool, time, IP).
- If you see anything you do not recognise, press Revoke.
- Create a new key if you need one and reconfigure your app.
Revoking cannot be undone, but it is harmless: at worst you reconnect.
Was this page helpful?