Changes and terms

The three kinds of change the agent can propose, the three gates each one must pass, and the safety limits on what runs.

In the appPlatformSettingsApproved changes

Besides answering tickets, the agent can propose changes that would fix a problem. Each change must pass three gates before anything happens. This page explains the gates and the limits on what can run.

Kinds of change#

Kind	What the agent can propose	What happens when approved
Code changes	A code fix in one repository.	The agent edits the code and the service opens a pull request (GitLab: merge request). Your team reviews it. It is merged only if an approver asks.
Database changes	Exact `INSERT`, `UPDATE` or `DELETE` statements for one database (on MongoDB, insert, update or delete operations in JSON).	The service runs exactly those statements, in one transaction, with a row limit.
Cluster changes	Exact steps in your Kubernetes cluster, such as restarting a deployment, scaling it, deleting a stuck pod or running a scheduled job now.	The service tries every operation first without changing anything, then runs them in order.

The three gates#

1
Cerberius makes the kind available to your organisation. Until we do, its switch under Settings › Approved changes can't be turned on, and the row says it isn't available yet. Ask us if you'd like it.
2
An owner or admin switches it on for the platform. Under Settings › Approved changes, they turn on its switch. The first time anyone in your organisation does this, they must read and accept the terms, for the whole organisation.
3
A person approves each change. Every change is shown to an approver with exactly what will run. Nothing happens unless they approve it. For database, cluster, Microsoft 365, Google Workspace and DNS changes, an owner or admin can ask for two different people to approve each one: the first approval only records it, and the change runs when someone else approves it too. See Two people to approve.

If either of the first two gates is off, the agent isn't told it can propose that kind, and no change login is ever used, even one that's saved.

The terms#

The terms are accepted once, for your whole organisation. After that, any platform can switch a kind on without accepting again. Only a signed-in owner or admin can accept them. An API key can't.

In short, by accepting, your organisation confirms that:

changes are proposed by an AI agent, and each one runs only after someone at your organisation approves it, exactly as shown;
you're responsible for reviewing every change before approving it, and for its consequences;
Cerberius provides the feature as is, without warranty, and accepts no liability for changes made through it, including data loss or downtime;
you keep your own backups, and give change logins only the access they need.

The full text is shown before you accept. The Terms row on Settings › Approved changes shows who accepted and when. Click Read the terms there to read the full text at any time.

If we update the terms, kinds that were switched on stop working until someone accepts the new terms. You'll see The terms have changed. Accept them again to switch this back on.

Change logins#

Approved changes are carried out with logins that are separate from the read-only ones the agent uses. The agent never receives them.

Kind	Login it needs	Where to add it
Code changes	A repository key with write access (GitHub: Contents and Pull requests read and write; GitLab: `api`).	Organisation › Keys, then pick it under Settings › Code
Database changes	A change login on the database connection.	Settings › Databases, in the connection's form (only once database changes are on)
Cluster changes	A second kubeconfig, the changes login.	Settings › Live system, in the Changes login row under Kubernetes (only once cluster changes are on)

Give each change login only what it needs. For your cluster, its service account shouldn't be able to read Secrets or change permissions. See Allowing changes.

Limits on what can run#

The service checks every proposal before an approver sees it. Anything outside these limits is dropped, and the agent says why in the ticket's conversation.

Database changes#

Only INSERT, UPDATE and DELETE. No changes to tables or permissions.
One statement per entry. UPDATE and DELETE must have a WHERE clause.
The agent states the most rows the change may touch. If more would change, everything is rolled back and nothing changes.
Every statement has a 30-second time limit.
The database must be one you've added, with a change login.
On MongoDB: each entry is one insert, update or delete on one collection. Updates and deletes need a filter that names the documents. Updates change fields and never replace a whole document. All the entries run in one transaction, with 30 seconds for all of them, so the server must be a replica set: a server kept as several copies, as MongoDB Atlas always is.

Cluster changes#

Only these actions: restart, scale (0 to 20 replicas), delete, patch, create, and run a scheduled job now.
Only ordinary object types, such as deployments, pods, jobs, config maps, services and ingresses. Never Secrets, service accounts, permissions, namespaces or nodes.
Patches and new objects can't ask for extra privileges, host access or a different service account.
If you've listed namespaces for the platform, only those.
Every operation is tried first without changing anything. If any fails that trial, none runs. If one fails during the real run, the service stops there and reports what was already done.

Code changes#

One repository per fix.
CI and git settings are never changed, such as the .github folder, .gitlab-ci.yml, Jenkinsfile and .gitmodules.
No code, tests or git commands are run. The service builds the commit and opens the pull request itself.

Switch a kind off#

Turn off the kind's switch, and confirm with Switch off. The agent stops proposing it at once, and no change login is used. Changes already approved but not yet run are refused.