What the assistant can and can't do

This page is the short answer to the most important question about an AI that can take actions: what, exactly, is it allowed to do? Here is the whole picture in one place — what the assistant can do, what it can never do, and the checks in between.

What it can do

Working from the catalog of capabilities you approve, the assistant can:

• Answer questions about your product, grounded in the knowledge and documentation you give it.
• Look things up for the user — reading data they're already allowed to see.
• Take actions from your API that you've enabled — the same actions the user could take by hand.
• Show rich results — cards, tables, and components you've registered — right inside the chat.
• Remember useful context across a conversation, and across sessions only if you turn that on.

What it can't do

These aren't settings you have to get right — they're built into how Syncanix works:

• It can't exceed the user's own permissions. If they can't do something in your app, neither can the assistant.
• It can't act as someone else, or as an admin or service account — every action carries the real user's identity.
• It can't run a destructive action you haven't explicitly enabled — those are blocked by default.
• It can't skip a required confirmation or re-authentication check to push an action through.
• It can't see your source code, environment variables, database, or secrets — it works from a structured catalog, not your internals.
• It can't read your page, your users' cookies, or anything on screen it wasn't handed — the widget is sealed off from the host page.
• The language model never holds a long-lived credential — identity is resolved fresh, per action, by your systems.

How risky actions are gated

Not every action is treated the same. Each capability has a risk level you set, and that level decides what happens before it runs:

Read — runs automatically

Looking something up doesn't interrupt the user, so answers stay fast.

Write — asks first

Anything that changes data pauses and shows the user exactly what will happen, and waits for their yes.

Destructive — blocked by default

Deleting or irreversibly changing data is off unless you allow it, and can require re-authentication and a typed confirmation.

A conversation, step by step

Here's what actually happens when one of your users asks the assistant to do something:

1. 1
   The user asksThey type a request in the chat — say, "cancel my most recent order."
2. 2
   Identity is resolvedSyncanix confirms who they are through your identity provider, in their own browser — no shared login, no stored password.
3. 3
   The assistant plansIt works out which of your approved capabilities answer the request, and in what order.
4. 4
   Risky steps ask firstA read runs straight away; a write shows a clear summary and waits for a yes; a destructive step stays blocked unless you've allowed it.
5. 5
   The action runs as the userYour API receives the call with the user’s own identity and decides, using their real permissions, whether it happens.
6. 6
   It's recordedThe action lands in the audit trail, attributable to the user who ran it.

What if it's tricked or gets it wrong?

AI can be manipulated, and it can misunderstand. Syncanix is designed so that when that happens, the damage is contained — because being clever was never what let an action through in the first place:

• Permissions are the real limit. Even a perfectly manipulated prompt can only attempt what that user could already do — it can’t unlock anything new.
• Content the assistant reads (a document, a tool result) is treated as untrusted — it can inform an answer, but it can’t trigger a write or a sensitive action on its own without a fresh confirmation.
• Writes are user-approved and destructive actions are blocked, so a wrong turn asks before it acts rather than acting silently.
• Reversible actions can be undone, and every action is logged, so a mistake is visible and recoverable.

Next steps