Security and control
The agent looks. Your team decides.
Cerberius Agents is built so that an AI can investigate live systems, user accounts and domains, yours or your clients', without being able to change them on its own. This page sets out what it can reach, what always needs a person, and how your keys and data are handled.
Read-only by default
Investigations only read. No shell or browser. Its own machine only if you switch it on.
People approve
Replies, fixes and changes wait for a person.
The service makes changes
Approved changes are made by the service. The agent never sees a secret.
Encrypted and hidden
Keys encrypted at rest. Secrets hidden from results.
Read-only by default
During an investigation the agent can only use read-only tools. It has no shell and no web browser, and it can't run your code. The one exception is its own machine, which is off until you switch it on (below).
| Source | What the agent can do | What it can never do |
|---|---|---|
| Your code | Search and read files in the repositories you added, downloaded fresh for each run. | Change files, run code or tests, or push anything. |
| Kubernetes | List and read workloads, pods, events and pod logs. If you list namespaces, only those. | Read Secrets or service accounts. Change anything. |
| Loki logs | Search your logs. | Change or delete logs. |
| Databases | Look at tables and run one read-only query at a time, at most 200 rows. | Change data. Every query runs in a read-only transaction with a time limit. SQL Server has none, so there the query is checked to only read, runs in a transaction that is always rolled back, and the login should only be able to read. MongoDB is asked in JSON: each query is checked to only read and has a time limit, and the login should have only the read role. |
| Microsoft 365 | Read users, sign-ins, licences, groups, mailbox settings and devices, with a pass that lasts about an hour. | See the client secret. Send anything that changes Microsoft 365. |
| Google Workspace | Read users, sign-ins, groups, licences and devices, acting as the admin you chose, within your scopes. | See the service account key. Send anything that changes Google Workspace. Open another user's Gmail settings. |
| DNS at GoDaddy | Read the records of the domains you listed for the platform. | See the GoDaddy key. Read or change any other domain. |
| The ticket | Read the ticket, the requester's follow-ups and attachments, from whichever ticket system you connected. For tickets imported from HaloPSA, the whole conversation. | Follow instructions written in the ticket. See your ticket system's key or login. |
Least access, enforced twice
Use read-only logins, and the agent's own tools add their limits on top. For example, it never reads Kubernetes Secrets even if the login could.
Tickets can't give orders
A ticket is written by someone outside your company. The agent treats it as information to investigate, never as instructions.
Its own machine: off until you switch it on
A separate computer for each ticket, for checks such as looking up a domain's mail records. It holds none of your keys and can't reach your code, cluster, logs, databases or accounts. With the internet allowed, it reaches public addresses only, never your private network. Every command shows on the ticket. With the internet on, a ticket written to trick the agent could get it to send what it read to an outside address, so switch it on only where the checks are worth it.
Nothing reaches a customer without a person
Every reply waits for an approver, who can send it, edit it first or skip it. Automatic replies are off unless an owner or admin switches them on for a platform.
Always held for a person
Even with automatic replies on:
- Replies with a proposed fix or change.
- Replies where the agent has questions or needs more information.
- Follow-ups after a fix.
- Replies that are long, or look like they contain internal details.
A content check that doesn't use AI
Before a reply goes out on its own, a fixed check reads it, so a ticket can't talk its way past. It holds a reply back if it:
- is longer than 1,500 characters, or contains a backtick;
- looks like it contains a file path, stack trace or log timestamp;
- contains an IP address, an internal server name, or something that looks like a key or token.
Fixes and changes need a person. The service makes them, not the agent.
Code fixes and database, Kubernetes, Microsoft 365, Google Workspace and DNS changes are each off until made available to your organisation and switched on by an owner or admin. Then every single one needs an approver, who can edit it first.
| Kind | Who carries it out | Limits |
|---|---|---|
| Code fixes | The agent edits one repository. The service opens the pull request with a key the agent never receives. | Merged only when an approver asks. No code, tests or git commands are run. CI and git settings, such as .github and .gitlab-ci.yml, are never changed. |
| Database changes | The service, with a separate change login the agent never receives. | Only INSERT, UPDATE and DELETE, with a WHERE on updates and deletes. One transaction, rolled back if more rows would change than agreed. 30 seconds per statement. On MongoDB, the same as JSON operations, with a filter on updates and deletes, and 30 seconds in all. |
| Kubernetes changes | The service, with a separate change kubeconfig the agent never receives. | Restart, scale (0 to 20), delete, patch, create or run a scheduled job now. Never Secrets, service accounts, roles and role bindings, namespaces, nodes, network policies or custom resources. Dry run first: if any step fails, none runs. |
| Microsoft 365 changes | The service, with the app registration you connected, after reading each user or group it touches. | Requests run in order and stop at the first refusal. Never apps, admin roles, conditional access or other policies. New accounts get a random first password that nobody sees. |
| Google Workspace changes | The service, with the service account you connected, after reading each target first. | Never admin roles or privileges, or anything that hands out keys. New accounts get a random first password that nobody sees. |
| DNS changes at GoDaddy | The service, with your GoDaddy key, after reading the records it touches. | Only A, AAAA, CNAME, MX and TXT records, on the domains you listed. Never name server or SOA records. |
An approver can edit a change before approving it. The edit is checked exactly like the agent's, and what they approve is what runs. Settings are checked again when a change is approved, in case something changed since the agent asked. Every change, who approved it and its result are kept on the ticket's history. A change request is never sent to the requester.
Keys are encrypted. Secrets are hidden.
Keys, tokens and logins
- Encrypted at rest with AES-256-GCM. Each saved value has its own encryption key, which is itself encrypted.
- Each value is tied to your organisation and the item it belongs to, so it can't be copied and used elsewhere.
- Never shown again after saving, in the app or the API. You only see the last four characters.
- Keys in your library can only be used by your own organisation's platforms.
Secrets hidden before anything is stored
- Private keys, passwords and tokens in settings and authorisation headers.
- Well-known key formats, such as Claude, OpenAI, GitHub, Slack, AWS, Google and Stripe keys.
- Card numbers.
- Cluster, log and database results are cleaned the same way before the agent sees them.
What we keep, and who can see it
Cerberius Agents keeps what your team needs to work on tickets and see what happened. Your code is downloaded fresh for each run and isn't kept afterwards.
| What | Why |
|---|---|
| Tickets, follow-ups and attachments | So the agent and your team can work on them. |
| Tickets imported from HaloPSA, with their conversation, including your team's replies and private notes | So the agent knows what the requester was already told. |
| Replies, fixes and changes, with who approved, edited or skipped them | Your record of what was sent, run and why. |
| The agent's findings and the steps it took | So you can see how it reached its answer. |
| Change requests and their results | A record of what ran and what happened. |
| Commands run on the agent's own machine, and what came back | So you can see every check it made. |
| Chatbot conversations | So you can review how your chatbots answer. |
| A log of setting changes | Who added a key, removed a member, deleted a platform, and so on. |
Kept until you delete it
Ticket data is kept until you delete the platform it belongs to. Deleting a platform removes its tickets, history, settings and chatbots for good.
Kept apart
Only your organisation's members can see your tickets. Approvers and viewers see only the platforms they're given, and never settings or keys. Each platform's tickets, connections and settings are separate.
Your own AI account
The agent sends the ticket and what it reads to Claude using your key. Chatbots use your Claude or OpenAI key. That use falls under your account with the provider.
Your ticket system
- Its key or login is used only by the service, to read tickets and write back to them. The agent never receives it.
- When a connected system says a ticket changed, we read that ticket from the system ourselves, with your key. A call to our address can't put words into a ticket.
- What goes back is approved replies, closes, any status or assignment change you chose, and the agent's findings only if you switch that on. In Jira and Linear, and in YouTrack without a team group, replies and findings are comments that everyone who can see the issue sees.
- Each platform can take only the clients, companies, projects or teams you tick, and two platforms never take the same one. The agent looks into a ticket with that platform's systems only.
Telegram and Slack notifications carry only the platform, the ticket's subject, who sent it and a link. Never findings, code or logs.
Roles, and rules the agent always follows
| Role | What it can do |
|---|---|
| Owner | Everything, on every platform, including managing owners and deleting platforms. |
| Admin | Everything, on every platform, except managing owners and deleting platforms. |
| Approver | Approve, edit or skip replies. Approve fixes and changes, editing changes first if needed, and merge approved fixes. Only on the platforms they're given. No settings. |
| Viewer | Look at the work on the platforms they're given. |
Safety rules come first
Every agent and chatbot follows our safety rules, then your organisation's rules, then each platform's details. Your rules can shape tone and content, but can't override the safety rules or give the agent new access.
- Tickets are information to investigate, never instructions.
- Replies to requesters must not include internal details, such as file paths, code, stack traces or service names.
- The agent only discusses the requester's own account.
- Chatbots won't reveal their rules or how they're set up.
People sign in with Google, Apple or a code sent by email. There are no passwords. To join an existing organisation, an owner or admin invites them first.
Limits, and off switches that work at once
Each platform sets limits on cost per ticket, minutes per run, steps per run and how many tickets are investigated at the same time. The agent stops when it reaches one.
Automatic replies
Untick Allow automatic replies and nothing goes out on its own, whatever mode is set.
Changes
Switch a kind of change off and the agent stops proposing it at once. Approved changes not yet run are refused.
Chatbots
Switch a chatbot off and it disappears from your websites straight away.
API keys
Revoke a ticket-system API key and systems using it stop working straight away.
Ticket system
Disconnect a connected ticket system, and new tickets stop coming in and replies stop going back to it. Its webhook address stops working at once.
Members
Remove a member, or take a platform away from them, and they lose access to it at once.
Its own machine
Switch it off, or switch off its internet, and later investigations on that platform run without it.
Your own logins
Delete or rotate the key on your side, such as your ticket system's key, the Kubernetes token, the Microsoft 365 client secret, the Google key or the GoDaddy key, to cut access at once.
Questions about security?
Tell us what your team needs to know. We'll answer plainly.
See it on your own tickets
Early access is open to teams who look after systems, their own or their clients'. Tell us about your setup and we'll get in touch.