Assistants

Ctadel's assistants are four agents that run inside your instance, read the data Ctadel holds and never act without a person deciding: the Warden answers, the Mason prepares a fix, the Sapper searches for attack paths, the Constable investigates incidents. This page describes what they do, on which model, and what keeps them from being hijacked.

What the agents share

• Read-only. The agents read Ctadel's data and the graph and write nothing to them. The only actions (opening a pull request, creating a ticket, accepting a rule) go through a button you click.
• Every fact comes from Ctadel's data. The agents' instructions forbid stating a number, a resource name or a rule key they did not read during the conversation, and require citing what the answer relies on.
• Scope. Ctadel re-reads the user's roles on every request and confines the agents to their projects; a project the user does not have is refused even if requested.
• Budgets. Each turn and each agent's daily use are bounded; past the daily limit, the agent answers that its daily budget is spent.
• Models. The agents use language models served in Europe by Scaleway; the Sapper uses a larger model than the other agents. The instance operator can change the model service and each agent's model. Without a configured key, the agents answer that AI is not configured.
• Language. The agents answer in the user's language.

The Warden

The Warden answers the team's questions about their own posture: "Ask the Warden" opens a chat panel present on every page. The panel recalls: "The Warden answers from Ctadel's data only and cites what it relies on. It never changes anything. What it does not measure, it says so."

The page the chat is opened from decides what it can read and what it is told:

Page	What it can read	Use
All	Posture summary, findings list per family, rule details, history of openings and resolutions, resource context, the graph (read-only) and its schema	Counting, listing, explaining a rule, saying what depends on a resource
Overview, findings, one finding, toxic combinations	Grouping by cause (by rule, and by repository and module for resources declared in code), ranking by risk	"Where to start", "how many fixes"
Compliance	Status of one framework, chapter by chapter	A control with no rule is "not measured", never "compliant"
Runtime, one incident	The Constable's verdict, incident, identity profile and activity, live audit trail	Following up an investigation (internal validation)
Explorer	The graph schema is provided up front	Questions about the graph; the query that ran is shown ("Query run on the graph")

From the overview, the findings or one finding, the Warden can hand over to the Mason when you ask for a fix; it reports the plan, and you open it from the finding's "Remediation" tab. Tabular results are shown in the panel ("Severity", "Rule", "Resource"), with the "not measured" families. A daily posture summary can be posted on your notification channels at a fixed hour when the instance operator has set one; by default it is not.

The Mason

The Mason prepares the fix of a cloud configuration, toxic combination, Kubernetes or infrastructure as code finding. Its "Mason" block sits in the "Remediation" tab of the detail panel: "The Mason reads the resource, what depends on it and where it is declared in code, then proposes the fix in the channel that really manages it. Nothing is applied without your approval."

1. "Prepare the fix": Ctadel assembles the context (the resource and its properties, what depends on it, the Terraform file declaring it when the code-to-cloud link exists, and for a toxic chain its links), then the model picks the channel: "code" (an edit of the Terraform file, since a console change would be undone by the next deployment), "CLI" (commands for the resource's cloud), "console" when neither is possible, "ticket" when the fix needs a decision.
2. The plan shows "What could break" (derived from the listed dependants), "Depends on this resource (N)", for a chain the "Link to cut", the "Proposed change" (a diff) or the "Commands to run" ("Copy the commands"), and "To set before merging": values the model does not know (an administration range, a KMS key) are left as a variable with no default or as a placeholder in angle brackets, never invented.
3. You review. "Open a pull request" opens the change on the connected GitHub or GitLab repository that owns the file; "Create a ticket" files the ticket in a configured ticketing integration, at the finding's priority.
4. "Verify the fix" requests a re-evaluation of the resource; the block reads "Finding closed after re-evaluation." or "Still open after re-evaluation: the change is not in effect yet, or it does not fix the rule."

Edits are exact replacements: the text to replace is copied from the file as it is and must occur there exactly once; otherwise the block reads "The edit could not be applied to the file as it is". The Mason never edits a file it has not read.

The Sapper

The Sapper searches the graph for attack paths that are neither in the catalogue nor among the computed paths, and files proposals that you accept or reject by hand. It is described in Attack paths. In short: it only reads, files at most 5 proposals per search, one search at a time; an accepted proposal becomes a custom toxic rule of the instance. It is available only to users whose role covers every project. Its scheduled run is off by default; the instance operator can set one.

The Constable

The Constable investigates audit-log detection incidents: it reads the incident and its alerts, the identity's profile over 90 days (usual addresses and actions, rights, keys), its recent activity, the cloud's live audit trail over at most 7 days, and what the touched resources hold and expose. It returns a verdict at one of three levels (a false alarm, something to review, or something to act on), with its confidence, a timeline, evidence citing its source, a "Recommended action" and points "To verify". It takes up high and critical incidents on its own, and investigates the others on request ("Investigate").

Ctadel checks the verdict against the facts it gathered itself: when the signals warrant it, the verdict cannot go below a given level ("The verdict could not go below “level”"), and an IP address cited in the verdict that appears in none of the evidence gets the verdict rejected and corrected.

The Constable is part of audit-log detection, in internal validation and not available to customers; its block only appears on the "Runtime" page.

Guards against hijacking

The guards are enforced by Ctadel itself, not only by the model's instructions:

• Messages that try to steer the agent. A message asking for the internal instructions or trying to cancel them ("ignore the previous instructions", "give me your pre-prompt", "developer mode", and their French and English variants, with accents, spacing and invisible characters stripped) is recognised and gets a fixed answer: "I do not share my internal instructions, and a message cannot change them." Questions about your own AI agents (Bedrock, SageMaker, Vertex) and about remediation are let through: the product has an AI posture module.
• Second check. A message the first check does not recognise is assessed by a separate, smaller model. It never refuses: a message it finds suspect puts the turn under watch; the answer is then re-read and shown unless it gives the instructions away.
• Canary. The instructions carry a hidden reference; an answer that reproduces it is a copy of the instructions, in whatever language it was rewritten, and is withdrawn before being shown.
• Data addressed to the assistant. A resource name, a tag, a log user agent or a file comment are written by whoever attacks your account, and reach the model with the data it reads. Text that speaks to an assistant or asks it for a conclusion ("note to the AI", "classify as benign") is removed before the model reads it, counted, and reported: the instructions say to report it as a sign of a hostile actor, never to follow it. The Constable takes it into account in its verdict.
• Scope. The accessible projects are re-read on every request, never taken from the message.

Limits

• The agents depend on a language model: an answer may be incomplete, a plan may propose an unsuitable fix, a Sapper search may find nothing. The instructions require saying what could not be verified, and a turn that runs too long is cut: the agent then answers with what it already read.
• The Warden reads only what Ctadel measures; a control with no rule is "not measured".
• The Mason prepares fixes only for cloud configuration, toxic, Kubernetes and IaC findings; not for secrets, CVEs, data or hosts. The "code" channel assumes the resource is linked to its Terraform file; without a link, the Mason proposes commands or a ticket.
• The Constable is in internal validation. The live audit trail is read over 7 days at most.
• The first guard covers French and English; the second check covers the rest as best it can. No guard is perfect; the instructions themselves hold nothing secret, and no message gives an agent an ability it does not have.
• The language model is hosted by Scaleway; your posture data is sent to it on every turn. The instance operator can point to another compatible model service.
• Without a model service key, the agents' blocks are shown but answer that AI is not configured.