Security model

A security tool asks for trust. This page sets out what Warden can reach, who can make it act, and what leaves your account, so you can decide how much trust to give it.

Three principles

1. No model can act. A model can propose: a suppression, a fix, a fact for a case. Code checks every proposal against the records it cites. Only a person’s passkey signature can make Warden act, suppress a finding or excuse an actor.
2. Code decides what a finding is. Rules turn evidence into findings, and code sets a case’s status and severity. A model never changes a stored finding and never decides what is hidden: the control that shows every row is always on the page.
3. The watcher cannot write, and the writer cannot be talked to. Watch’s roles are read-only. Defend’s write roles live in their own stack, are used only by a verifier that checks each signed plan, and never read model text.

Read-only roles

Watch reads through roles that setup creates in your own AWS accounts. Those roles are read-only and explicitly deny calling models. You can read every permission Warden holds in your own IAM console.

Because the roles do not allow writes, Watch cannot change your resources even if something inside Warden went wrong. The limit is enforced by AWS, not by a promise in our code.

Setup is the one step that needs more: an operator with admin rights creates the roles and installs the hub. After setup, Warden runs with its own scoped roles. Its run identities never hold the deploy role.

Why the agent cannot be talked into anything

An attacker can write text into your estate: a role name, a tag, a user agent, a commit message. An AI agent that reads that text with admin rights can be steered by it. Warden is built so that it cannot.

• The agents hold no power. Their only credential can call the pinned Bedrock models. Their tools are a closed list of read-only queries run by code.
• They do not read attacker text. Names and tags reach a model as handles and fixed vocabulary, never raw. Every call carries a decoy and a prompt-leak token; a model that takes the bait trips the agents off for seven days and raises a high finding.
• Two makers. A model from a different maker refutes every narrative, suppression and lead before it is shown. What it contests is marked; what cannot be proven is dropped and counted.
• Plans come from cases, not from words. A response plan is built by code from the case’s lineage. No chat transcript can change a plan’s steps or targets, and a test holds that line.
• Signing needs the passkey. A stolen console session can ask questions and draft rows. It cannot sign, because signing needs the keeper’s passkey with user verification over the exact plan.

One signature over the plan

When you sign a response plan, your passkey signs the hash of the whole plan: every step, every target, every time box. The verifier refuses anything that does not match. Each step is still its own item in the undo ledger, with its own dry-run result, read-back, CloudTrail confirmation and undo.

Steps that touch things which existed before the attack and run your workloads, or that target actors joined only by behaviour, are held for a confirmation. With one keeper, a held step waits a short solo hold with a mailed confirmation; with more keepers, a second keeper can approve it. A plan that would leave an account with no administrator but the root user says so in words and is held.

Any passkey signs: one saved in a password manager, on a phone or laptop, or on a security key. Each passkey’s class is recorded and shown wherever a keeper appears. Requiring security keys is a signed option if you choose it.

It runs in your account

Warden is self-hosted. The hub runs in your own EKS cluster, the agents call Bedrock in your own account, and the ledger lives in your own bucket. There is no hosted service on our side that reads your estate.

No phone-home

Warden has no telemetry, no license server, and no request that carries anything about the install beyond what any download shows: the address it comes from, which reveals the AWS region, and its time. An install may download public, signed data that every install downloads identically (the advisory feed) on a schedule a keeper chose; a “Check now” also shows that someone asked at that minute. Releases and rule packs are downloaded only when a person asks.

• No telemetry. Warden sends no usage, metrics or crash reports to us.
• No online license check. A license is a signed file. Warden verifies it offline when it starts, against public keys built into the product.
• No key fetching. We publish our license keys at /.well-known/wardensec/license-keys.json so you can check a license yourself. The product carries the same list and never fetches it.
• One scheduled download, and a keeper picks the schedule. The advisory feed is the same public file for every install: no identifier, no version and no inventory in the request. This site counts nothing and writes no log line for the feed files under /feed/. A keeper who wants less chooses hourly, daily or on request. See The advisory feed for what each host can see.
• Egress is closed. One pod in the namespace has a route out, bound to a list of AWS hostnames the release names. The feed download is made by a function in the hub, outside the cluster.

What the watching identity can read, and code drops

The watching identity can read Lambda environment values and ECS overrides, because AWS returns them with the function listing and the task description (lambda:ListFunctions, ecs:DescribeTasks). Code drops them whole on arrival, before anything is stored, shown or sent to a model, and the listing is called only where Inspector’s Lambda coverage does not already give runtimes and layers. Warden never reads Lambda code, ECS task definitions, image layers or the contents of Systems Manager file inventory.

What leaves your account

The ledger and tampering

Every read, decision, signature and act is written to a chained ledger in a bucket under Object Lock, for ten years. Nobody can delete it, the root user included. A dead-man alarm raises the alarm if the scan stops, and the console’s state turns to Not watching or Blinded with the cause. An uninstall that skips the signed decommission is reported as tampering.

What it does not see

Warden watches the cloud’s control plane: every call an attacker makes to the AWS API, which is where a cloud attacker must go to escalate, spread, persist or take data. It is not a sensor inside your workloads. It does not see processes or files inside a container or instance; GuardDuty Runtime Monitoring and EKS audit logs are read as witnesses when you have them. It misses an attacker who stays inside one workload and never calls the cloud API, data read through a data plane whose events are off, and anything in the minutes before the event lane sees it. The console’s Watching state names what this install cannot see.

Release signing

Every release is signed, and the installer and the program check each signature against a root built into the installer. Release keys may be software keys held in a password manager, or security keys; the class of every key behind a running release is printed by the installer and shown in the console. The product root needs two signatures of different custody, so a stolen laptop alone cannot ship a release.

This website

This site has its own short security page: no trackers, no third-party requests, sign-in with passkeys only, and signed licenses. See Security.