Docs
Overview
What Warden is, what its agents do in your AWS account, and how one passkey signature ends an attack.
On this page
Warden is a security agent that lives in your own AWS account. It reads everything your accounts and EKS clusters record, does the work a good security engineer would do when something looks wrong, and stops the attacker when you say so. Nothing runs on our side, and nothing about your estate leaves your account.
One question, answered first
The console’s first screen answers one question: is anything happening to me right now? It gives one of five answers.
| State | What it means |
|---|---|
| Under attack | A case has code status active attack. The band says what, who, since when, what it can reach, and where the response stands. |
| Blinded | A log source that covered an attacker went dark. The band names the source and when it stopped. |
| Suspected | Something looks wrong and is being worked, with no active attack proven. |
| Watching | No active or suspected case, with the measured scope of the last read and what this install cannot see. |
| Not watching | The last full read is too old, or the watch stopped. The band says why and how to fix it. |
Below the answer: what needs you, what Warden is already handling, your top vulnerabilities as stories, what Warden costs to run, and which AWS features would let it see more. See The console.
Agents that work the case
Four agents run on Amazon Bedrock, in your account, under a role that can only call the models you enabled.
- Triage weighs every new finding. It proposes the expected ones away and catches quiet ones that belong to something bigger.
- Investigate works every case that matters. It reads CloudTrail itself, and EKS audit logs and VPC flow logs where you have them, and builds the case: a timeline, the actors, and what they can reach.
- Hunt looks for what no rule names: the family tree of an attacker’s identities back to the first stolen credential, attributed from fields AWS recorded, and self-replicating swarms of AI agents at any branching factor.
- Harden turns findings into a short list of fixes and tighter rules, ranked by what an attacker could reach.
Every sentence an agent shows is checked by code against the records it cites, and checked again by a model from a different maker. What cannot be proven is dropped and counted. See Bedrock access.
Minutes, not hours
An event lane reads every write call in every watched account as it arrives and runs a five-minute cycle. A case, its status and a plan request exist within that cycle, before any model has answered. A focused read every 15 minutes and a full read every hour keep the posture current.
One signature stops them
For each attack, Warden prepares a response plan. It contains every attacker identity first: their sessions fenced, the principals and machines they created quarantined, their keys disabled, their instances isolated, in the order that takes away their means to fight back. Then it closes the path they used. Every step is dry-run first, time-boxed and undoable. You read the steps in plain words and sign the whole plan once with your passkey. You can also type “block them” in the console’s chat: the plan appears in the chat, and you sign it there.
One install per estate
An estate is the AWS accounts and EKS clusters one hub watches: a single account, or an organization’s accounts. You install Warden once per estate. Everything it runs lives in one Kubernetes namespace and in tagged CloudFormation stacks, and the Footprint page lists every resource with what it costs. The uninstall is guided and removes everything except the tamper-evident ledger.
What no model can do
No model can act, suppress a finding or excuse an actor. Models propose; code checks; a person signs. That is why an attacker who talks to the agent, through a tag, a role name or the chat, cannot talk it into anything.
Plans
Watch is read-only: the scan, the agents, cases, hunting and hardening proposals. Its license is free. Defend adds response plans and is a paid plan, issued by request. See Licensing.
Where to go next
- Concepts: cases, actors, response plans, the event lane, the console and the footprint.
- Security model: what Warden can touch, why a model cannot act, and what leaves your account.
- Install: the one-line installer, what setup creates, and what it costs.
- Install checks: the steps AWS makes you do yourself, each with a Check button, and the install steps behind setup.
- Onboarding: the five screens after setup, and the one signature that sets them.
- Settings: the console’s seven sections, and how to verify a webhook.
- Recovery: getting the console back, a new door password, and signing without a console.
- Bedrock access: which models to enable for each agent, and what they cost.