Allowing changes

Sometimes the fix for a ticket is a change, not a reply: a wrong value in a database row, a stuck pod, a bug in the code. The agent can propose these changes. Each one is shown to an approver with exactly what will run, and nothing happens unless they approve it.

Every kind of change is off until you switch it on. Settings › Approved changes has one row per kind, each with its own switch, and a Terms row. The label at the top of the page lists the kinds that are on, for example Database · Cluster, or says Off.

The kinds#

Microsoft 365 and Google Workspace changes never touch apps, admin roles or policies, even if the account could. See Microsoft 365 and Google Workspace.

Three gates#

A change can only happen when all three are open:

1. Cerberius makes the kind available to your organisation. Until then, its switch can't be turned on, and the row says Not available to this platform yet. Ask Cerberius to make it available.
2. An owner or admin switches it on for this platform. The first time anyone in your organisation switches a kind on, they accept the terms for the whole organisation.
3. A person approves each change. One at a time, after reading exactly what will run. If you ask for it, two different people must approve each change. See Two people to approve.

The agent's own logins stay read-only throughout. Changes run with separate logins that the agent never sees.

Switch a kind on#

1. 1

   Go to Settings › Approved changes.

2. 2

   Turn on the switch in the row for the kind you want.

3. 3

   The first time anyone in your organisation does this, a pop-up shows the terms. Read them, and tick I have read and accept these terms for the whole organisation.

4. 4

   Click Accept and switch on.

Once your organisation has accepted the terms, the Terms row shows Accepted, with the date and who accepted them. After that, the switch turns a kind on straight away, on any platform, without the terms again. Click Read the terms in the Terms row to read them at any time.

When a kind is on, the line under its switch says which login to add next.

Only owners and admins can switch a kind on or off.

The terms#

By switching a kind on, you confirm, for your company, that:

• Changes are proposed by an AI agent. Each one is carried out only after someone at your company approves it, exactly as shown.
• You are responsible for reviewing every change before approving it, and for its consequences.
• Cerberius provides this feature as is, without any warranty, and accepts no responsibility or liability for any change made through it, including data loss, downtime or any other damage.
• You keep your own backups, and give the change logins only the access they need.

If the terms change, kinds switched on under the old terms stop working. The row says The terms have changed. Accept them again to switch this back on.

Then add the login it needs#

Switching a kind on lets the agent propose it. The change still needs a login to run with:

The agent only proposes changes it can actually make. A database change needs a database with a change login. A cluster change needs the changes login, and must stay within the namespaces it may look at. Anything else is dropped before an approver sees it.

What an approver sees#

A change arrives on the ticket as a Change to approve, separate from the reply. It shows what the agent wants to do, where, how risky it is, and Exactly what will run: the SQL statements (on MongoDB, JSON operations) and the most rows they may change, or the steps in your cluster. A change to approve is never sent to the requester.

To change it first, click Review and approve, then Edit before approving. Every part of the change that runs can be edited: the statements, the steps, the requests or the records. You can also leave one out or add another. Undo my edits puts back what the agent proposed. Your edit is checked exactly like the agent's, and what you approve is what is made. The ticket marks it as edited.

After the change runs, the result goes back to the agent, which drafts the reply to the requester. That reply then waits for approval as usual.

See Approving a change and Approving a fix.

Two people to approve#

For database, cluster, Microsoft 365, Google Workspace and DNS changes, you can ask for two different people to approve each change before it runs. This is off until you turn it on. Code changes don't have it: their pull request is reviewed and merged by your team anyway.

1. 1

   Go to Settings › Approved changes.

2. 2

   In the row for the kind, tick Needs two people to approve. It saves at once.

Only owners and admins can turn it on or off, and only when signed in. An API key can't, even one that may change settings. Each change of the setting is recorded in the audit log. Switching the kind off and on again keeps it.

How it works#

• The first approval doesn't run the change. It is recorded, with who and when, and the change waits. Under the change, the ticket says, for example, Approved by Ann at 10:42. Needs a second person.
• A second, different person runs it. When they approve, the change runs as usual. Both names are kept with the change, and the ticket's What happened shows both.
• Nobody can approve twice. The person who approved first sees Approve greyed out, with You approved it. A second person must approve it before it runs. The same holds on the phone app, and through an API key acting for them.
• An API key counts as one approver. A key is a different approver from your people. But two approvals through the same key count once, whoever it says it acts for.
• Editing starts again. If someone edits the change before it runs, earlier approvals no longer count. The person who edits it gives the first approval of the new version, and it needs a second person after them.
• Anyone can stop it. If anyone clicks Skip, the change stops and its first approval no longer counts. Approving it later starts again with two people.
• A change that failed needs two people again before it is tried again.
• The agent can't approve a change. If you ask it to in the chat, it tells you who approved first, and that a different person must approve it on the ticket.

The people who can approve are told when a change needs a second person, in your notification channels and on their phones. The person who approved first isn't told on their phone.

Turning it off#

Turning it off doesn't run a change that is already waiting. It still needs one more approval, from anyone, including the person who approved first. The ticket then says, for example, Approved by Ann at 10:42. Two people are no longer needed: one more approval makes it.

Switch a kind off#

1. 1

   Turn off the switch in the kind's row.

2. 2

   Confirm by clicking Switch off.

The agent stops proposing that kind at once. No change login for it is used, even one that is saved, and a change that was approved but hasn't run yet is refused. The saved logins stay, so you can switch it back on later. Remove them under Databases or Live system if you no longer need them.

See also Changes and terms.