Safe on cold start
The auto-execute allowlist ships empty. Every containment action waits for a human until an operator explicitly promotes it — and the promotion is itself audited: who, when, and why.
promote.py add disable_access_key --by alice
Private preview — onboarding design partners
Autonomous threat response
that earns its autonomy.
Kronagent is a team of AI security agents that triages, investigates and contains threats across AWS, Google Cloud and Kubernetes — governed by a deterministic policy engine, a human approval gate no model can talk its way past, and an immutable audit log.
Ingests from
AWS GuardDuty·Google Cloud SCC·Kubernetes Audit·STIX / TAXII·OCSF export
The gap
Most “AI SOC” tools stop at a recommendation.
They summarise the alert, map it to ATT&CK, write a tidy paragraph — and then hand a human a ticket. The mean time to contain never moves, because nothing was ever allowed to act.
The tools that do act ask you to trust a language model with production credentials on day one. That's not a trust model; it's a leap of faith with an audit log bolted on afterwards.
Advisory tools
- Investigate, then stop
- Containment stays manual
- Autonomy is all-or-nothing
- Audit trail is a log file
Kronagent
- Investigates and executes
- Containment planned before it runs
- Autonomy earned one action class at a time
- Hash-chained log that fails verification if edited
Architecture
Five specialists. Two of them can touch your infrastructure.
Every LLM agent is strictly advisory — it enriches the incident record and the human's approval context. Only the deterministic policy engine and the containment layer can cause a side effect.
Input
Finding
GuardDuty · SCC · K8s audit, normalised
LLM · advisoryTriageIs this a real, actionable threat?
LLM · advisoryThreat IntelMITRE ATT&CK mapping, IOC assessment
LLM · advisoryCorrelationPart of a wider campaign?
LLM · advisoryCommanderNarrative, P1–P4, escalation call
Deterministic
Forensics
Evidence + chain of custody — captured before containment can destroy it
DeterministicPolicy engineMay this action run unattended?
DeterministicContainmentExecutes, or refuses
HumanApprovalBefore the side effect, not after
ImmutableSHA-256 hash-chained audit logEvery decision, in order, verifiable end to end
Trust model
Four properties that hold even when the model is wrong.
The policy engine is a ceiling, not a suggestion
Actions are classified by reversibility and blast radius. Destructive or wide-blast actions — terminate an instance, delete a pod, scale to zero — are structurally incapable of running unattended. Promote one by mistake and nothing happens: the classification table wins.
LLMs reason. They never act.
Every agent's output schema is built so it cannot express a containment target or action class. Targets always come from normalised finding data — so a prompt-injection payload buried in telemetry has no channel to redirect an action onto an attacker-chosen resource.
Nothing is invisible
Triage, policy, containment, approval, governance, forensics — each is one entry in an append-only, SHA-256-chained log. Editing a past record breaks verification of every record after it.
✓ chain verified — 1,284 records
Behavioural trajectory guard
An automatic kill switch for the agents themselves.
Kronagent watches its own behaviour over time, not just each action in isolation. When an incident's trajectory starts to look like an agent being steered — escalating blast radius, repeated policy probing, targets drifting away from the originating finding — the run halts itself and routes to a human, mid-incident.
Compliance
Built to the shape of the regulation, not retrofitted to it.
Automatic logging and human oversight aren't features we added for a questionnaire — they're the two invariants the whole system is constructed around. Generate the evidence manifest as a command.
python3 run_compliance_report.py --markdown-output rep.md
EU AI Act · Article 12
Automatic recording of events across the system's lifetime — the hash-chained audit log, by construction.
EU AI Act · Article 14
Human oversight. Destructive actions cannot execute without an approval recorded before the side effect.
OCSF export
Findings and outcomes stream into your existing SIEM in an open schema.
Dry-run by default
KRONAGENT_DRY_RUN=true until you decide otherwise. Nothing touches a cloud account on install.
Run it in your AWS
Inside your account. Nothing leaves it.
One CloudFormation stack runs Kronagent next to the findings it reads: GuardDuty in, approvals in Slack, triage on Claude through Amazon Bedrock in your own account. The findings, the model calls and the audit log never leave it, and no one outside holds a role into it.
aws cloudformation deploy --stack-name kronagent
No inbound ports
Nothing on the internet can reach it. Slack is an outbound connection; the console opens through AWS's own authenticated tunnel.
Read-only until you decide
It starts able to read and plan, and nothing else. Write access is one stack parameter, and every action still waits for your approval.
An audit log you keep
Every decision in a hash chain on encrypted storage in your account, kept even if you delete the stack.
About $10–15 a month
One small Fargate task and its storage, plus Bedrock tokens per finding. No load balancer, no NAT gateway.
Private preview
Bring us your noisiest cloud account.
We're onboarding a small design-partner cohort — teams running real GuardDuty, SCC or Kubernetes audit volume who want response automation they can actually defend in a review.