Docs
Concepts
Estates, findings, cases and actors, the agents, the event lane, response plans, the console, the footprint and release keys.
On this page
A few words carry most of the meaning in Warden. This page defines them.
Estate and hub
An estate is the AWS accounts and EKS clusters one hub watches: a single account, or an organization’s accounts. The hub is the one Warden install that watches the whole estate. There is one install per estate, and a license names the estate it is for.
Watch and Defend
Warden has two natures.
Watch is the default. It reads your accounts and clusters through read-only roles, records what it read, and reports what it can prove. The agents work in Watch too: they triage, investigate, hunt and propose fixes. Watch cannot change your resources, because the roles it holds do not allow writes.
Defend adds response. It prepares a response plan for each attack and carries it out when a keeper signs it. Its write roles live in their own stack, so with Defend off they do not exist.
Still by default. It acts only when you say so.
Evidence, receipts and findings
Evidence is what Warden reads from your accounts and clusters. A receipt is the record of a single read; there is one for every read.
A finding is a conclusion that rules reach from evidence. Rules decide what is a finding. Every finding links to the records that prove it, carries its severity with the reason for it, and is never changed by a model. Every run states plainly what it could not check.
Cases and actors
A case gathers the findings, events and identities that belong to one thing happening in your estate. Code gives it a status: active attack, suspected, contained or closed. The case page shows a timeline of verified events, the actors, what they can reach, what could not be checked and the response.
A keeper decides a case on its page: Close this case, or Lower this case to suspected, with a reason, signed with a passkey. Either covers what the keeper saw; anything Warden reads after that time is judged again and can raise the case again. A finding that a principal used a value outside its baseline, such as a new region or network, offers Teach this value: a signed record that teaches that one value for that one principal is normal, for 400 days, and nothing else.
An actor is anything the attacker holds: an access key, a role or user, a session, a machine, a network address, a tool fingerprint. Actors in the lineage were created, minted or used by the attacker, proved by fields AWS wrote. Actors joined only by behaviour are marked linked, and any step against them is held for a closer look.
A swarm is a lineage that copies itself: keys minting keys, roles creating roles. Warden finds swarms in code, across runs, at any branching factor, and draws the family tree back to the first stolen credential.
The agents
Four agents run on Amazon Bedrock in your account.
| Agent | When it runs | What it produces |
|---|---|---|
| Triage | On every new or changed finding and every lane hit | A call per finding: expected, needs a look, part of a case, or escalate. Suppressions are proposals a keeper signs. |
| Investigate | On every case over the bar, at once | More verified facts and actors, what they can reach, a narrative, and the request for a response plan. |
| Hunt | Hourly, daily, and across 30 days of memory | Leads that become suspected cases, swarm and replication findings, attribution of the attacker’s means. |
| Harden | Daily, and after a case closes | A short ranked list of fixes and tighter rules. |
A fifth job, chat, runs when a keeper asks a question in the console. A quiet tick with no new finding makes no model call. Agent spend has hard ceilings per call, per case and per day, enforced in code. See Bedrock access.
The agents read evidence through a closed list of read-only tools. They hold no credential except one that can call the pinned models. They see handles and fixed vocabulary, never raw names an attacker could have written.
The event lane
The event lane receives every write call in every watched account and region through EventBridge, as AWS delivers it, and runs a five-minute cycle. A lane hit becomes a case seed: within the cycle, code builds the case, its status and the request for a response plan, before any model call. An opt-in recon rule adds the read calls attackers use to enumerate an account, priced before you turn it on.
Alongside the lane, a tick every 15 minutes reads what changed and a sweep every hour reads everything. Rules run on every read.
Response plans
A response plan is what Defend proposes for a case. It has two stages.
- Contain every actor in the lineage. Fence their sessions so tokens minted before the plan stop working. Disable their access keys. Quarantine the principals they created. Isolate their instances. The order takes away the attacker’s means to spread and fight back first: the origin and anything that can create or assume, then what was active in the last 15 minutes.
- Secure the path they used. Each edge the timeline proves was used, such as an assumed role, a minted key, a shared snapshot or an opened bucket, maps to one step that closes it. A fix that would change a trust or permission policy becomes a keeper task with the exact change.
Every step is dry-run first, carries a time box, and has an undo in a ledger. Steps against linked actors, or against things that existed before the attack and run your workloads, are held for a second look. You sign the whole plan once with your passkey; the signature binds the exact plan. After you sign, a follow clause keeps containing what the swarm creates next, for two hours by default and up to six, without asking again.
The console
The console runs in your cluster, at a name under your domain. Its home page, Now, reads top to bottom:
- The state: under attack, blinded, suspected, watching or not watching.
- Chat: “Ask Warden, or tell it what to stop.”
- Needs you: plans waiting for a signature, contested proposals, keeper tasks, expiring holds.
- Handled by Warden: cases being investigated, holds running with time left, follow clauses armed, findings cleared as facts.
- Vulnerabilities: your top three risk stories, each with its fix and what it closes.
- What Warden costs: the install’s monthly estimate, model spend today against each ceiling, and a month estimate.
- See more: AWS features that would let Warden see or act more, each with what it adds and its price.
The line-by-line findings are one click down, never the front page. The other pages are Cases, Posture, Harden, Findings, Agents, Health, Footprint, Settings and Uninstall.
Chat
Your words are the only instruction the chat takes. “Block the attacker” on a case makes code build the response plan from the case’s lineage, and the plan appears in the chat with its steps and Sign. “Fix this” on a finding drafts a hardening proposal. “Is this safe?” gets the facts and their coverage, never a yes. A stolen console session can ask questions; it cannot sign.
Notifications
A new active attack, a blinded state, a plan ready to sign and a plan carried out are mailed at once, and sent to a Slack incoming webhook if you add one. An hourly digest covers the rest, only when there is something. Mail and Slack carry code words, counts and a link to the console, never names from your estate.
Footprint and uninstall
Everything Warden runs in Kubernetes lives in one namespace, wardensec: the console, the egress proxy, the event lane and the scheduled scan. Everything in AWS is in CloudFormation stacks named wardensec-<part>, tagged with the install id and grouped as one application in the AWS console.
The Footprint page, and warden footprint in a terminal, list every resource by place, why it exists and what it costs a month. Anything carrying the install tag that no template declares is raised as a finding.
The uninstall starts from the console. It lists every resource that goes and what stays, refuses to continue while Defend holds anything, and offers to undo every hold first. A keeper signs the decommission; warden uninstall carries it out and proves what is left. What stays is the ledger, under its retention lock, with the key that reads it.
Release keys
Every Warden release is signed. The installer and the program check each signature against a root key built into the installer before anything runs. Release keys may be software keys held in a password manager or security keys; each key’s class is printed wherever a release is trusted. The product root needs two release signatures of different custody, and a new release waits a fixed period after signing before an install adopts it, so a stolen key cannot ship a release unnoticed.
Licenses
A license is a signed file that names your estate. Warden checks it offline when it starts. See Licensing.