Attack in progressA leaked CI key of ‹ci-deploy-bot› is being used to break in: 6 accounts and machines created.Open the case
Install
Everything Warden installed, whether each piece is working, the release it runs, and what it costs. A keeper, a person whose passkey approves changes, adopts a new release here.
Health Version AWS checks Door Placement and console Parameters Where it lives Footprint Uninstall
What Warden runs in your account
No full sweep has written an inventory yet, so nothing is counted. The next one will.
Health
Health
Watching. The last full run finished 4 hours ago and read 900 of 900 wanted reads. Hourly run 2 minutes ago.
Outside the console, scrapers and webhooks see only: Watching
Outside the console, Warden reports only whether it is watching, never what it saw.
Needs a person
Nothing needs a person.
What changed in your accounts
no data
Service levels, 30 days
no data
Step timing, 30 days
no data
Reads
no data
Intelligence
no data
Integrity
no data
Alarms
no data
Observability itself
no data
Event lane, last hour
no data
How this install is set up
This block is not part of the verdict. Every row, with what someone would need and how to step up
Warden could not read how this install is set up.
Version
The install gate has not reported an adoption yet.
Adopted: 1.0.0, release aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, kernel bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.
Release keys
This console cannot show the keys behind the running release: its launcher did not hand them over.
This console runs a release the ledger has not adopted. Until it is adopted, Warden uses the stricter of the two at every point, and says so every run.
The adopted release's files are not held here, so this console cannot say what adopting would change. Adoption then waits 72 hours.
Known vulnerabilities in this Warden release
Warden matches the software list of the release you run against the same advisories as your own software, ranked by how reachable and how powerful its own parts are.
Not checked yet: the software list of this release has not been matched against the advisories.
If the console cannot be reached
- warden refresh, run by your AWS administrator, puts the console back with the adopted release.
- warden door reissue, run by your AWS administrator, sends a new door sign-in to a keeper.
- authority sign-offline, the launcher's command, lets a keeper whose key signs a raw challenge outside a browser approve a change without the console; a passkey kept in a password manager signs only on the signing page.
AWS checks
Steps only your AWS administrator can take. Check asks Warden's read-only checks function; it changes nothing.
This console cannot ask the checks function.
| Step | What the check found | |
|---|---|---|
| Bedrock model access for the agents | Not checked from this page yet. | |
| The console's DNS delegation | Not checked from this page yet. | |
| The alert subscription is confirmed | Not checked from this page yet. | |
| Clusters accept access entries | Not checked from this page yet. | |
| Organisation trusted access | Not checked from this page yet. |
Door
The install gate has not reported the door yet.
Placement and console
Where Warden runs and how it is delivered. The node group and the footprint change only by a signed install.params record, drafted from Install › Parameters; the install gate applies it.
| Setting | How it stands | |
|---|---|---|
| Placement (node group) | The install's value; no keeper has changed it. | Change |
| Footprint size | The install's value; no keeper has changed it. | Change |
| Delivery | The install gate applies every release. | |
| Console | On, and required: the first signature and every signed change happen in this console. |
This console
What this console can check of its own setup from inside the cluster it runs in: 7 of 7 in place. Every other cluster in your accounts is on Clusters.
| Check | State | What the console found |
|---|---|---|
| Sign-in | in place | You signed in through Warden's AWS sign-in (load balancer wardensec-wardensec-dev). Sign out |
| Your role | in place | You are a keeper: a person whose passkey approves changes. |
| Warden's record | in place | The console can read Warden's record. |
| The last run | in place | The last run finished at 2026-09-12 06:04 UTC and pushed. |
| Your passkeys | in place | You can sign decisions with 1 passkey. |
| Who can sign | in place | 2 keepers can sign decisions. |
| The schedule | in place | Warden scans every day (UTC). The next run starts at 2026-09-13 06:00 UTC. |
Parameters
Every keeper parameter of the release this install adopted, with the value the ledger signed last. A change is a signed install.params record: the install gate applies it to the stack on its next plan.
The release's parameter list could not be read, so the parameters cannot be shown or changed.
Where it lives
- To watch
- AWS's own read-only policies SecurityAudit and ViewOnlyAccess, a short list of extra reads, and explicit denies on secret values, object contents and other data. The watcher writes only its own records. It never writes to your resources.
- The AI agents
- Run inside the scanner and call Amazon Bedrock through a role that can invoke only the models you chose. They read evidence Warden already collected, never your cloud directly. They cannot act, change a setting or hide a finding. The console's Check function makes at most ten one-token test calls a day to show which models you can use.
- To defend (optional)
- A separate role exists only while Defend is on. It can do one item of a closed list of reversible actions, to one target, for a short time, and only after a person signs that exact action with a passkey. Each action undoes itself when its time box ends unless a person renews it.
- Who else can change Warden
- In a single account, your administrators and anyone allowed to update Warden's stacks or functions (AWS's PowerUserAccess allows both). Warden lists them by name below and pages on every such change; an organisation guard closes it when the hub is a member account (v1.1).
- Sent to the vendor
- Nothing. The only outside contacts are downloads: a signed release or rule pack when a person asks and, unless a keeper turned it off, the public advisory feed every 15 minutes: the same files every install downloads. The hosts that serve them see the address, from your AWS region's shared pool, and the time.
Who can change Warden
Who can change Warden has not been read yet: the next full sweep reads it.
Your hub account, home region
| Piece | What it is for | Runs as | Uninstall |
|---|---|---|---|
wardensec-base | The release store (bucket, image and chart repositories) and the installer and deploy roles. First in, last out. | Wardensec-Installer, Wardensec-Deploy | You delete it, last. |
wardensec-gate | The install gate: the only thing that changes Warden, and only as keepers signed. It also owns the image cache. | Wardensec-Gate, Wardensec-Gate-Kube, Wardensec-Gate-Retire, Wardensec-Gate-Retire-Kube, Wardensec-Gate-Scheduler | Deleted by the uninstall, last of all but the base. |
wardensec-hub | The read-only watcher's identity and records: read roles, the validation probe, the state and authority buckets, alarms, private AWS endpoints, the notary, checks and advisory fetch functions, the console's role and secrets. | Wardensec-Hub-ReadOnly, Wardensec-Validate, Wardensec-Spoke-ReadOnly, Wardensec-Agent-Invoke, Wardensec-Trail-Forward, wardensec-secrets-reader, Wardensec-Console, Wardensec-Authority-Notary, Wardensec-Checks, Wardensec-Advisories-Fetch, Wardensec-Sbom-Export | Removed; the state bucket and its key stay until their retention ends. |
wardensec-edge | The console's front door: a load balancer that signs every request in with Amazon Cognito, its certificate, web firewall, alarms and the signing page. | wardensec-signer | Removed. |
wardensec-address | A DNS zone for the console's names, only when your domain lives elsewhere. | None of its own | Removed. |
wardensec-cluster | Warden's own node group, the Pod Identity agent and the cluster's OIDC provider. | wardensec-node | Removed, except the OIDC provider, which others may rely on. |
wardensec-defend | Only while Defend is on: an isolated network and the one function that carries out a signed act. Only while Defend is on. | Wardensec-Defend-Verifier | Removed, only after every Defend action is undone. |
wardensec-defend-cluster | Only while Defend is on: the cluster half of Defend's guard. Only while Defend is on. | None of its own | Removed with Defend. |
wardensec-flowlogs | Optional: flow-log queries the hub read role runs, capped by your budget. Only when you install it. | None of its own | Removed. |
wardensec-selftest | Optional: self-test targets that prove the watch sees what it should. Only when you install it. | wardensec-selftest-role, wardensec-selftest-lambda-role | Removed. |
wardensec-org | With an organisation only: the guard and the StackSet that puts the member roles in each account. Only when you install it. | None of its own | Removed. |
Your hub account, us-east-1
| Piece | What it is for | Runs as | Uninstall |
|---|---|---|---|
wardensec-hub-global | Alarms on changes to Warden's own IAM roles and DNS. | None of its own | Removed. |
Your EKS cluster, namespace wardensec
| Piece | What it is for | Runs as | Uninstall |
|---|---|---|---|
wardensec CronJob | The scanner, every 15 minutes: the tick, the full sweep on your schedule, the rules and the agents. | wardensec | Removed. |
wardensec-console Deployment | The console, reachable only through the front door. No write to AWS or Kubernetes. | wardensec-console | Removed. |
wardensec-egress Deployment | The egress proxy: the pods' only way to hosts outside the cluster that no AWS endpoint serves. It reaches only the hosts on its list, on 443, and holds no identity and no secret. | wardensec-egress | Removed. |
wardensec-lane Deployment | The event lane, one pod: reads AWS's live events within about a minute and puts a plan in front of a keeper. Same identity as the scanner. | wardensec | Removed. |
wardensec-preview CronJob | The rule preview, every minute: answers a queued preview from the stored events, writes only its answer, and exits. Same identity as the scanner. | wardensec | Removed. |
Every other watched account, each enabled region
| Piece | What it is for | Runs as | Uninstall |
|---|---|---|---|
wardensec-member | One read-only role and one event forwarder in each watched account, and the optional SBOM export's role in the one that administers Inspector. | Wardensec-Spoke-ReadOnly, Wardensec-Trail-Forward, Wardensec-Sbom-Export | Removed; outside an organisation, a keeper task with its link. |
wardensec-spoke | The read-only role in an account watched before the member template. Only when you install it. | Wardensec-Spoke-ReadOnly | Removed. |
wardensec-member-defend | Only in the accounts Defend covers: the hands Defend acts through. Only while Defend is on. | Wardensec-Defend-Act, Wardensec-Defend-K8s, Wardensec-Defend-FenceWriter | Removed after every Defend action has ended. |
Identities, one line each
| Identity | Who uses it | Read | Write | Never |
|---|---|---|---|---|
Wardensec-Hub-ReadOnly | The scanner and the console's reads, in the hub account | AWS configuration and activity: AWS's SecurityAudit and ViewOnlyAccess, and a short list of extra reads. ListFunctions returns Lambda environment values; Warden drops them before anything is stored. Every version of the signed authority records; with the flow-log sensor on, the flow-log bucket and its query results, only through Athena | Its own state, ledger and spool objects, written once; the notice topic | Secret values, or any other object contents or data; any change to your resources; Bedrock directly |
Wardensec-Validate | The scanner's validation probe | The account summary only | Nothing | Anything else |
Wardensec-Spoke-ReadOnly | The scanner, in each watched account | As the hub read role | Nothing | Any change in the account; secret values or data |
Wardensec-Agent-Invoke | The agents, inside the scanner | Nothing of yours | Calls to the Bedrock models you allowed | Anything else |
Wardensec-Trail-Forward | EventBridge, in each watched account | Nothing | Write events onto the hub's event bus | Anything else |
Wardensec-Console | The console pods | Warden's records and the authority ledger | Its drafts and run requests; it asks the notary and the checks function | Any AWS or Kubernetes write |
Wardensec-Authority-Notary | The notary function | Signed records | The authority ledger, after checking every signature | Anything else |
Wardensec-Checks | The console's Check buttons | A fixed list of read-only checks and Bedrock's model lists | Its claim objects; at most ten one-token model probes a day | Anything else |
Wardensec-Advisories-Fetch | The advisory fetch function | The signed advisory feed, from wardensec.ai and the vendor's bucket, and the release it verifies it with | Verified feed files, in its own advisories bucket | Anything else |
Wardensec-Sbom-Export | The optional SBOM export, off unless keepers turn it on | Nothing: it starts Inspector's export and reads its status | One Inspector SBOM export a day, to the advisories bucket under its own key. If its function were replaced, this identity could send your software list to another bucket; Warden watches the function for any change | Anything else |
wardensec-secrets-reader | The External Secrets store in the cluster | Warden's own two secrets | Nothing | Any other secret |
wardensec-signer | The signing page | The verifier's heartbeat object | Its own log | Everything else, by an explicit deny |
Wardensec-Gate | The install gate's head | The release store, the authority ledger and the facts it checks | Change sets on wardensec-* stacks under the deploy role; its own plans and journal; door sign-ins | Anything the signatures do not cover |
Wardensec-Gate-Kube | The install gate's hands, in the cluster's network | The plans the gate wrote and the release they name | A server-side apply of a gate-written plan in Warden's namespace | Any object the plan does not hold; anything another delivery owns |
Wardensec-Gate-Retire, Wardensec-Gate-Retire-Kube | The uninstall | The signed decommission and the inventory | Delete Warden's own stacks and objects, only under an effective, unexpired signed decommission | The base stack or the gate itself; anything not Warden's |
Wardensec-Gate-Scheduler | The gate's hourly sweep schedule | Nothing | Invoke the gate's head | Anything else |
Wardensec-Deploy | CloudFormation, for wardensec- stacks: passed only by the gate, and used by whoever may operate those stacks | What CloudFormation reads back about the resources it builds; its own function code | Only the calls the released templates' resources need, generated from them: IAM on Warden's own roles and policies (a role with no boundary takes only the AWS policies its template names); function, log group, rule, topic, queue and schedule writes on Warden's names; bucket and secret calls on Warden's own; key material only through Secrets Manager; passing only the roles the templates name. Network, key, cluster, load balancer, DNS, sign-in and firewall calls name their resources by generated ids, so those are allowed on any resource of the account | Anything outside its boundary; a Warden role without a Warden boundary, or under its own; any other role, policy, bucket, secret, function, log group, rule, topic, queue or schedule |
Wardensec-Installer | Named principals with MFA, for every setup command once the base is sealed | Its boundary's reads: your stacks, cluster, network and front door, the release store, and the authority ledger by version | Release store objects; invoke the gate; sign the release's zips with this install's profile into the signed-code bucket; the A17 readback tag on the hub's read-only role; termination protection on wardensec- stacks | Change a stack directly; any other IAM write or tag key; write the authority ledger or the state bucket |
Wardensec-Defend-Verifier | Defend's verifier, only while Defend is on | The signed records and the evidence each act cites | Its own Defend records; one act's credentials into the act role | Anything unsigned |
Wardensec-Defend-Act, Wardensec-Defend-K8s | The act, in each account Defend covers | What each act checks first | One signed, reversible act on one target, time-boxed | Anything unsigned; anything destructive |
Wardensec-Defend-FenceWriter | Defend's fence | What it checks | The fence's own records | Anything else |
wardensec-node | Warden's node group | Nothing of yours | What an EKS node needs: its network interfaces and pulling images | Anything else |
wardensec-selftest-role, wardensec-selftest-lambda-role | The self-test targets, only when you install them | Nothing of yours | The self-test's own resources | Anything else |
Your analyst role, Your secrets role | Your people, when you name an analyst role or a secrets role at install | Analyst: Warden's records. Secrets role: the two secrets, with MFA | Secrets role: hands the notary a record | Anything else |
wardensec ServiceAccount | The scanner's pods | Kubernetes objects through the reader role, never secrets or exec | Through the hub read role only | Any Kubernetes write |
wardensec-console ServiceAccount | The console's pods | Warden's own jobs and schedule | Through the console's role only | Any Kubernetes write |
wardensec-egress ServiceAccount | The egress pod (v1.1), the only pod with an internet route | Nothing | Nothing | Any Kubernetes or AWS call |
wardensec-secrets-reader ServiceAccount | The External Secrets store | Warden's two secrets, through its IAM role | Nothing | Any other secret |
default ServiceAccount | Nothing: the namespace's default account, with no token mounted | Nothing | Nothing | Everything |
Footprint
Running costs
Everything Warden runs in your accounts, what it is for, and what it costs at list price.
$363 a month, estimated
$344 fixed, plus models at about $18.40 (the last 7 days ($4.29) projected over the month). Models today: $3.78 of $15; up to $30 a day while a case is active.
| What | Where | A month | Basis |
|---|---|---|---|
| Hub interface endpoints (16, two zones) Lets the scanner and the agents reach AWS APIs without the internet. | Hub account | $234 | 16 x 2 zones x $0.01 an hour |
| Console load balancer Serves this console behind your sign-in provider. | Console edge | $16.43 | $0.0225 an hour, plus capacity units |
| Console web firewall Rate-limits and filters the console's one public address. | Console edge | $8 | $5 a web ACL and $1 a rule, 3 rules |
| Dedicated node (one t3.medium) and its volume Runs the four Warden workloads apart from yours. | Your cluster | $31.97 | $0.0416 an hour, 20 GB gp3 |
| KMS keys (2) and secrets (4) Encrypt the ledger and state, and hold the console's two settable secrets. | Hub account | $3.60 | $1 a key, $0.40 a secret |
| Event lane: rules, queue and forwarders Brings each account's management events to the hub within seconds. | Each member account | $1.20 | about 2 million events a month at $1 a million |
| Warden's own logs and witness stream Every request, act and decision, append-only. | Hub account | $1.50 | about 3 GB at $0.50 a GB ingested |
| State and ledger buckets Run results and the signed ledger, the ledger under Object Lock. | Hub account | $0.70 | under 30 GB of S3 Standard |
| Defend NAT gateway Gives the verifier one owned address the countdown policy can name. | Defend | $32.85 | $0.045 an hour, plus $0.045 a GB |
| Defend STS endpoint (two zones) Lets the verifier take its act role without leaving the VPC. | Defend | $14.60 | 2 zones x $0.01 an hour |
| Agents on Bedrock Triage, investigation, hunting and chat; never more than the daily ceiling. | Bedrock models | usage | usage; see the model line |
Plus data through the endpoints ($0.01 a GB) and the agents' usage, which the daily ceilings bound. AWS list prices, us-east-1, read 2026-10-09; other regions differ, and your bill is the measure.
Make Warden better
Turn these on in AWS so Warden sees more. Warden changes nothing here.
OffBedrock model access: hunt (Sonnet class)$3 to $12 a month
Looks across runs every hour for slow, multi-step activity no single finding shows, and drafts hardening proposals.
Details
Request access to a Sonnet-class model on the Bedrock model-access page, then sign the agents.models setting. Price: one hourly pass over the run deltas.
OffAn organisation trail$0 to $12 a month
Every account's events in one place, including accounts created after install, so a new account is never unwatched.
Details
Create it from the management account; Warden finds it on the next full read. Price: the first copy of management events is free; $2 per 100,000 for a second copy.
OffVPC flow logs$10 to $45 a month
Shows where an isolated instance tried to connect, and which addresses talked to your workloads.
Details
Enable flow logs to S3 on the production VPCs; Warden reads the bucket with its existing role. Price: $0.25 a GB delivered to S3.
Partly onCloudTrail data events on your sensitive buckets$4 to $30 a month
Shows who read which objects. On for 1 of your 3 sensitive buckets: Warden cannot say what was read from the other two.
Details
Add the two buckets to the trail's data event selectors; Warden reads them with its existing role. Price: $0.10 per 100,000 data events.
Partly onEKS audit logs on all clusters$15 to $60 a month
Shows who did what inside Kubernetes. On for 2 of your 3 clusters.
Details
Turn on the audit log type for the third cluster in the EKS console. Price: $0.50 a GB ingested into CloudWatch Logs.
OnBedrock model access: lead (Opus class)$4 to $25 a month
Investigates active cases, writes the checked narrative, explains plans and answers the chat.
Details
Enabled at install; the model is pinned at your first signature. Price: measured token profile for accounts of this size; hard ceiling $15 a day.
OnBedrock model access: triage (Haiku class)$1 to $6 a month
Triages every new finding and lane hit within seconds, so the lead model is spent only where it matters.
Details
Enabled at install. Price: about 1,500 short calls a month.
Every resource
Each resource Warden runs, where it is, why it is there and what it costs. Names are Warden's own.
Relied on in your cluster, not installed by Warden
- The External Secrets controller (ESO) 0.17 or later (it serves external-secrets.io/v1), with the cluster's IAM OIDC provider for its reader.
- The AWS Load Balancer Controller (it serves elbv2.k8s.aws/v1beta1 TargetGroupBinding), for the console's place behind the edge load balancer.
No full sweep has written an inventory yet. The next one will.
Uninstall
Everything but the ledger: the dry run below is the run.
What Defend holds
Warden could not read what Defend is holding. Nothing below starts until it can.
What goes and what stays
No full sweep has written an inventory yet, so there is no plan to show.
Sign the decommission
A keeper signs install.decommission with a passkey. With one keeper it waits a 72-hour lock with notices on every channel; with two, the second keeper signs. An uninstall that does not wait still works as the account owner's act, and is reported as tampering.
Nothing can be signed while the steps above refuse to start.
Progress
Warden could not read the uninstall's progress.