Product
A security engineer that never leaves your account.
Warden reads everything your AWS accounts and EKS clusters record, does the legwork a good security engineer would do when something looks wrong, and stops the attacker when you say so, with one passkey signature.
What it reads
Three cadences, one estate.
Warden reads through read-only roles you create, one per account, and an access entry per cluster. An estate is the AWS accounts and EKS clusters one hub watches: a single account, or an organization's accounts.
| Cadence | What happens |
|---|---|
| The event lane | Every write call in every account is read as AWS delivers it. Within the five-minute cycle the case exists, and with Defend on, its response plan is ready to sign. |
| Every 15 minutes | A focused read, the rules, triage of everything new. |
| Every hour | A full read of the estate, the log profile and the hunt. |
What it is not. Warden is not an in-workload sensor: it does not see processes or files inside a container or instance. It sees the calls an attacker makes to the cloud's API, which is where a cloud attacker has to go to escalate, spread, persist or take data, and that is where it contains them.
The agents
Four jobs, on Bedrock in your account.
One runtime runs every job as a bounded loop over read-only tools. The models run on Amazon Bedrock in your own account, one model per role, chosen at install from what your account has enabled. A quiet 15 minutes, with nothing new, makes no model call at all.
| Job | Runs | Produces |
|---|---|---|
| Triage | Every 15 minutes, on new, changed and reopened findings | A call per finding: expected, needs a look, part of a case, or escalate. False positives become suppression proposals, never silent mutes. |
| Investigate | At once, for any case or event-lane hit over the bar | Follow-up reads of CloudTrail, and of EKS audit logs and VPC flow logs where you have them; more verified facts and actors; what they can reach; the response request. |
| Hunt | Every hour, every day, and across 30 days of memory | Leads that become suspected cases: breadth bursts, denied-then-allowed retries, mint fan-out, machine and agent pace, swarms. |
| Harden | Daily, and after a case closes | A short list of fixes and tighter rules, ranked by what an attacker could reach through each one. |
| Chat | When a keeper asks | Answers from the evidence, with what it could not check. "Block them" drafts the response plan, which you sign in the chat. |
Spending has hard ceilings, enforced in code: $15 a day for the agents plus a $30 reserve for an attack, lowerable at install and raised only by a signed decision. The console shows today's spend against each one.
Cases and attribution
Who they are, by what they hold.
Findings arrive grouped into cases. A case carries its timeline, its actors, its confidence and its basis, and what the actors can reach: your signing key, a database secret, a bucket. Severity always comes with its reason.
Warden identifies the attacker's means: the keys, roles, sessions, machines, networks and tooling they hold, and the family tree back to the first stolen credential, built from fields AWS itself recorded. A swarm of AI agents that copy themselves is one case with one lineage, however wide it branches. It never guesses a person's name.
The line-by-line findings are one click down, grouped by what code confirmed, with the control that shows every row always on the page.
The console
The first screen answers one question.
"Is anything happening to me right now?" The answer is one of five states.
- Not watchingThe last full read is too old. Nothing below claims quiet until it reads again.
- BlindedA log source covering an open case went dark. The band names it, and when.
- Under attackOne band per active case: what, who, since when, what it can reach, the response, and one button to review and sign.
- SuspectedA card per suspected case, ranked, with its confidence and reach.
- WatchingNo case, and the measured scope: last full read, accounts, regions and clusters, and what this install cannot see.
Below the state: the chat, what needs you, what Warden is handling, your vulnerabilities as stories with their fixes, what Warden costs to run, and the AWS features that would let it see more, each with what it adds and its price. Notices go by e-mail and to a Slack webhook, in code words and counts only, with a link to the console.
A key from outside your network is minting roles in account 1111…
- Who
- 1 origin key, 7 principals it created, 2 networks, 1 tool fingerprint
- Reach
- your signing key, ‹prod/db›, 3 buckets
- Response
- ready to sign: 5 steps
Youblock them
I drafted the response for case k/7Q3F from its lineage: deactivate the origin key, fence ‹ci-deploy›, quarantine the 7 roles it created, isolate i-0c94…e1, then fence ‹deploy-prod›. Each step passed its dry run.
- Plan k/7Q3F waiting for your signature
- Rotate ‹prod/db› outside AWS
- 1 contested suppression to decide
- Investigating 1 case, 41 follow-up reads
- 38 findings triaged today, 31 match 22 of 30 days of history
- 2 hardening proposals drafted
- ‹ci-deploy› can reach your signing key in 2 steps from the internet
- A snapshot is shared with an outside account
- 2 clusters accept public API traffic
- $130 a month for this install, plus models
- Models today $2.10 of $15, reserve $30
- Month estimate from 7 days: $61
- S3 data eventsonce on, object reads become visibleabout $9/mo
- EKS audit log, cluster 3once on, who did what in Kubernetesabout $4/mo
- VPC flow logsonce on, where an instance talks toabout $11/mo
Response plans
Contain every actor, then close the path.
Code builds the plan from the case, never from chat text or model words. Steps are ordered so the attacker loses the means to spread and fight back first: the lineage root and anything that can create or assume, then the actors seen in the last 15 minutes, then the rest, then isolations, then the path.
| Actor | Step |
|---|---|
| An access key | Deactivated, and its user fenced so the sessions already minted from it end too. |
| A user or role the attacker created | Quarantined. |
| A role your workloads use | A perimeter that keeps your workload running and refuses stolen copies of its credentials. |
| An instance acting for the attacker | Isolated, and its role quarantined or fenced. |
| An address | Joined to every fence in the plan, so the attacker's sessions are refused from it. |
Every step is dry-run first, time-boxed and undoable on its own, and written to the ledger before it is applied, read back after, and confirmed in CloudTrail. One passkey signature binds the whole plan. After you sign, the follow clause contains what the lineage creates next, for two hours by default and up to six, without asking again.
Response plans are Defend. Defend ships in every release and stays off until a Defend license turns it on. We issue those licenses by request.
Under attack: 1 key, 7 principals it created, can reach your signing key.
Proven: 9 facts from 23 records, 2 sources.
- 01 Contain Deactivate access key
AKIA…7QF2origin of the lineage - 02 Contain Fence user, refuse sessions issued before apply
‹ci-deploy›ends tokens the key already minted - 03 Contain Quarantine 7 roles the key created
‹gen-1›…‹gen-3›created by the attacker - 04 Contain Isolate instance
i-0c94…e1calls from its own address - 05 Secure Fence the role they assumed
‹deploy-prod›the path they used
‹prod/db› the key read. Remove the 7 roles after forensics. Footprint
One namespace, every resource priced.
Everything in your cluster runs in the wardensec namespace:
the CronJob wardensec and the Deployment wardensec-console. In AWS, every resource is in a wardensec-
stack, tagged with the install id, in one application view. Setup prints a dollar line for
each item before it creates anything; the Footprint page and
warden footprint list every resource with why it exists and what it
costs. Where it lives shows the same list from the release,
with what each identity can read and write.
The uninstall starts from the same list. It undoes anything Defend is holding first,
removes everything but the ledger, which stays under Object Lock until its retention
ends, and proves the rest is gone with warden footprint --after-uninstall.
| Place | Kind | Name | Why | $/month |
|---|---|---|---|---|
| namespace wardensec | Deployment | wardensec-console | the console and signing page | in node |
| namespace wardensec | Deployment | wardensec-lane | the event lane | in node |
| namespace wardensec | CronJob | wardensec | the 15-minute read | in node |
| namespace wardensec | Deployment | wardensec-egress | the one route out | in node |
| cluster | Node group | wardensec | runs the four workloads | $31.00 |
| hub account | Stack | wardensec-hub | VPC endpoints, 1 zone | $94.90 |
| hub account | Stack | wardensec-ledger | Object Lock bucket, KMS key | $4.20 |
Vulnerabilities
Which flaws reach your workloads, and which to fix first.
Warden is built to know what software runs in your AWS accounts and clusters, to learn of new advisories from a signed feed, and to rank what it finds by what an attacker could reach. It reads what AWS already offers, installs no agent and pulls no image. These are the seven ways it differs from a list of CVEs sorted by score.
The list below describes the scanner as it is designed. An early access install does not download the feed yet and shows no vulnerability findings; the Vulnerabilities page lists what is in the product today.
- One ranked list, decided by code from the estate's own attack graph. By design, a flaw on a batch job that can read one bucket ranks below a lesser flaw on an internet-facing pod whose role can become administrator. Each item is to say why in one plain sentence built from proven facts.
- The fix, not the CVE. Matches are designed to be grouped into fix units, such as moving twelve pods to one image tag, with what that closes and how much of it is exploited.
- Same-day knowledge. A vendor-built feed is designed to be signed with two keys held in separate custody and to carry the public databases and items curated from security mailing lists, often before a CVE exists. The target is a finding on the page within the hour, for installs that fetch on the live schedule.
- 'Are we affected?' with honest answers. The answers are designed to be affected, not affected, scanner reports none, or could not tell, with the reason and what to turn on. A host's package list is never to answer for the libraries inside its applications, and an unread scope is never to be reported as clear.
- Platforms and AWS's own updates in the same list. Designed to carry end of standard support for EKS versions, database engines, Lambda runtimes and operating systems, AWS's pending security updates for managed caches and search domains, and what extended support costs each month.
- The agents are designed to check whether it is already being used. For the top items, an agent is to ask the evidence an install has collected whether the workload shows signs of exploitation. Code decides every rank from typed facts, and no model output raises or lowers one.
- Compromised packages count as compromises. A running package whose artefact matches one a public malicious-package database lists is designed to raise a critical finding. A package that only shares a name is to be flagged for a person to check and never treated as an intrusion.
The target is a finding on the page within the hour of the feed learning of an issue, for installs that fetch on the live schedule. That is a promise about the page. Notices follow once the rules leave shadow on an install.
What each AWS option adds
With no option turned on, Warden is designed to know platform, engine, runtime, node and image versions, AWS's pending updates and end-of-support dates. Each option below is AWS's own and is billed by AWS to your account, never a prerequisite (list prices checked on 23 October 2026).
- Amazon Inspector: package-level flaws inside instances, images and Lambda functions, with the fixed version.
- ECR scanning: operating system package flaws in images pushed to ECR.
- Systems Manager: the package list of each managed instance, so a version outside an advisory's range can be answered.
- Inspector software export: the components of each image and function, for same-day package matches.
An early access install does not download the feed yet and shows no vulnerability findings; the Vulnerabilities page lists what is in the product today. Sources, matching and prices are in the docs, and the curated advisories are public at /advisories.
Trust
Nothing about your estate leaves your account. Nothing acts without a person.
- Read-only by construction. The models hold an invoke-only credential. Every read they ask for is a closed list run by code.
- Attacker text is quarantined. Models see fenced handles, never raw names, tags or user agents. A decoy and a leak token ride on every call.
- Verified evidence. Every sentence shown was 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.
- Embers. Decoys nobody legitimate touches. A touch is close to certain.
- A person signs. No model can act, suppress or excuse anything without a passkey signature over the exact change. Any passkey works; a password manager is fine.
- It cannot be stopped quietly. A dead-man alarm and a chained ledger under Object Lock. A Witness account, a witness outside the cluster, comes after launch.
Read the security model, or get early access: access arrives by e-mail during the preview, and the install shows the line and the script it runs.
Thank you. You are on the early access list.
We email the address you gave once, to confirm the request. Requests are approved by hand, and an approved one gets an invite link by email. No marketing is sent. To be taken off the list, write to support@wardensec.ai.