Approvals and safety
An assistant that can change your instance should not be able to delete things on its own initiative. Gigantics makes sure that a person decides before anything destructive happens.
Dry run first
Reading is always allowed. Changes that cannot be easily undone, such as deleting a project, a datasource or a user, changing the authentication settings, resetting a password, or writing into a real destination, are destructive tools. A destructive tool never runs on the first call: it returns what it would change, and changes nothing.
The assistant also reads the result back to you, so you can say yes or no knowing exactly what will happen.
Some tools are destructive only for some requests. Granting an owner-level role, updating an existing datasource or pipeline, or running a rule with a destination, ask for approval; a harmless change does not.
Who approves, and how
The assistant cannot approve for you. Typing "yes, I confirm" in the conversation, or the assistant setting confirm: true by itself, is not an approval. What happens next depends on what your AI client can show:
| Your client can... | What you see |
|---|---|
| Ask a question (a dialog) | A dialog describing the change, which you approve or decline. If you approve, the change is made as part of the same request |
| Show a panel | The result of the dry run with a panel under it, with Cancel and a button named after the action, for example Create user. Click it and the change is made |
| Neither | The assistant tells you that the change was not made, and gives you the gig admin command to run it yourself |
Which one applies depends on the client you use and on its version. For example, some clients show a panel, others show a dialog, and some can show neither. You do not have to choose: Gigantics picks the safest one that your client supports.
Example: creating a user with an approval panel
- You ask: "Create a user for x@y.com."
- The assistant prepares the change. Nothing is created yet. The result says Create user x@y.com has not run yet: it needs the user's approval, and shows a panel with Cancel and Create user.
- You click Create user. The panel shows Running "Create user"... and then the result.
- The result is posted to the conversation (Approved and ran "Create user": User x@y.com created) and the assistant carries on without you typing anything.
Some details that protect you:
- The panel runs exactly the change you saw, with the same values. The assistant cannot change them after you look at them.
- A panel is good for one change and is valid for 5 minutes.
- A dialog answered in less than half a second is treated as an automatic answer of the client, not as a person, and is refused.
- Deleting an organization or a project can ask you to type its name.
- If the panel's click never reaches the client, the panel says so after 60 seconds.
When the assistant cannot ask you
If your client cannot show a dialog or a panel, or automatically declines dialogs, the change is refused and nothing is done. You still have two ways to get it done:
- Run the same operation yourself with
gig adminand--yes. - With the remote endpoint, do it in the Gigantics interface.
The assistant is told not to look for a way around a refusal, and not to suggest changing the approval mode.
Agent mode
In agent mode, the assistant can confirm its own destructive changes: no person is asked. It exists for clients that cannot show a dialog, for clients that decline them automatically, and for automation that you fully trust.
With agent mode, an assistant can delete projects, users and datasources by itself. Turn it on only for automation you trust, and prefer a dedicated key or process for it.
How to turn it on:
| Connection | Where |
|---|---|
| Remote endpoint | Check Allow agent mode when you create the key. The key list shows Agent mode in orange. The mode belongs to the key and cannot be changed afterwards: create another key to change it |
| Local server | Start gig mcp with --confirm-mode agent, or set GIG_MCP_CONFIRM_MODE=agent |
The choice is always made by the person who configures the connection, never by the assistant.
What the assistant is allowed to do
- Only what the account may do. Every call is checked by the Gigantics server against the roles of the account: a locally signed-in user, or the Root user behind an MCP key. Tool descriptions and instructions never extend them.
- A forbidden operation ends there. If it gets Access denied, the assistant reports which role is missing and who could grant it. It does not try a different account.
- Instance-wide actions need your word first. Deleting organizations and projects, changing Global Settings, making a user Root, deleting users or resetting passwords are also confirmed with you in the conversation before the approval is requested.
- Secrets stay hidden. Passwords, session cookies, API keys, OAuth secrets, LDAP passwords and SSH keys are replaced by
<redacted>in the results. When a secret is set, the assistant only learns that it is set. Dialogs and panels never ask for a secret: a secret has to come from your own message. - One change at a time. After a change, the assistant reads the state back to check that it happened.
Auditing what happened
Open Events in the user menu to review the activity of the instance. Creating and deleting MCP API keys is recorded with the source Auth, and the key itself is never recorded. You can also ask the assistant to search the events for you.
Best Practices
- Keep the default. Use Person approves unless you have a real reason.
- One key per assistant or per person, with a name you will recognize, and an expiry date.
- Use the shortest expiry that works for you, and delete keys you do not use anymore. The Last used column helps you find them.
- Read the dry run. Check the organization and project it names before you approve something destructive.
- Try on a test project first when you are learning what your assistant can do.
- Do not share keys in chat, tickets or repositories. If one is exposed, delete it in Global Settings → MCP.