arizuko › products › AWS DevOps agent

AWS DevOps agent — Argus

An SRE that lives in your team’s chat, reads your runbooks, and runs read-before-write against AWS. Each engineer acts with their own keys — so CloudTrail names the human, not a shared robot.

what you get

Each engineer’s own AWS keys. Alice’s aws calls run with Alice’s credentials, Bob’s with Bob’s. One agent, but the account sees the real person on every call. A shared team role is the fallback, not the default.
Read before write. The agent defaults to describe / list / get. A mutating call — terminate, delete, stop, modify — stops and shows you the exact command and its blast radius before it runs.
Runbook-grounded answers. It reads the runbooks and the service map you put in facts/, cites the file and line, and says “I don’t have that” rather than inventing a procedure.
Can’t reach anything but AWS. The container runs default-deny. It reaches amazonaws.com and whatever hosts you allowlist — nothing else. An agent holding cloud keys that physically cannot talk to a host you didn’t approve can’t exfiltrate them.
Oncall in the channel you already watch. Alerts and destructive-action confirmations land in Telegram; the team thread runs in Slack or Discord. Same agent, same folder, whichever surface.
Per-identity audit, both sides. arizuko logs who asked for what in its own audit_log; AWS logs the matching API call to that engineer’s IAM principal in CloudTrail. Two records, one human.
Your server, no vendor plane. Conversation history, runbooks, keys, and agent state live under /srv/data/arizuko_<name>/. Nothing about your infra transits a SaaS control plane; the only model call goes to Anthropic.

whose keys am I running as

This is the whole idea, so it’s worth walking through. When a message triggers a turn, arizuko resolves the sender’s own user-scoped secrets and overlays them on the team’s folder secrets — the person’s own keys win. Those keys become the container’s env for that one turn, and the container is thrown away when the turn ends.

alice  @argus the stuck instance i-0abc won't drain, terminate it

argus  Running as you (arn:aws:iam::…:user/alice). Here's the state first:
         i-0abc  running  us-east-1a  asg web-prod  (2 healthy siblings)
       This will terminate one prod instance; the ASG replaces it.
       Confirm and I'll run:
         aws ec2 terminate-instances --instance-ids i-0abc

alice  go

argus  Terminated i-0abc. ASG is launching a replacement.
       Logged to diary. CloudTrail shows the call under user/alice.

Bob triggering the next turn gets a fresh container with Bob’s keys. There is no long-lived process holding anyone’s credentials, and in a shared incident channel each turn still runs as whoever sent it — the container doesn’t outlive the turn, so one person’s keys never bleed into another’s call.

two layers gate the dangerous stuff

The agent gates intent. Its CLAUDE.md holds it to read-before-write and makes it state the command and wait for your go before any mutation. The bash grant decides whether it may shell out at all.
IAM gates the blast radius. The real cap is the IAM policy on each engineer’s keys — read-first actions wide, Terminate* / Delete* narrow or denied, per person. arizuko decides who; IAM decides what that person may do. If a call comes back AccessDenied, that’s IAM refusing the human, and the agent reports it instead of retrying.

who it’s for

A small platform/SRE team that wants an oncall copilot in chat but won’t hand a shared admin key to a bot.
Regulated or privacy-sensitive shops that can’t send infra state, telemetry, or credentials to a vendor cloud — this runs on your host with default-deny egress.
Anyone who needs per-engineer attribution in CloudTrail for change control, incident review, or audit.

why this beats the usual AI-SRE tool

The market is full of AI SREs. Almost all of them share one shape that this product doesn’t: they run as a single service account and live on the vendor’s cloud. That difference is the pitch.

Per-human cloud identity is near-uncontested. Tools like Cleric, Resolve, Kubiya, Datadog Bits AI, incident.io, Firefly, and Spacelift all execute cloud actions through one shared role or token — so CloudTrail records the bot, not the engineer. Here, each person’s own keys drive their own calls (store/secrets.go user-scope, resolved per caller in routd/dispatch.go).
The one real counter-example is AWS Q — and it’s AWS-only. Q’s CLI does inherit your own AWS profile, so it attributes to you. But it’s AWS-locked, runs on AWS’s managed plane, and lives in one terminal. This runs on your host, spans your chat channels, and the same per-operator model works for any keys you inject.
No forced egress. Even the “in-VPC” and self-hosted-runner products ship prompts, telemetry, or state out to a control plane and onward to an external model. This has no vendor plane; egress is default-deny through crackbox, allowlisted per folder.
It executes, but bounded. Half the market only reads and recommends (Datadog Bits, incident.io, PagerDuty Advance); the half that acts does it with a shared credential. This acts — under a grant-gated shell, a read-before-write persona, and per-operator IAM.
Prod and staging are real walls. Each environment is its own folder: own keys, own egress allowlist, own grants, own container. The agent in acme/staging cannot see or touch acme/prod.
Ephemeral by construction. Every turn is a fresh docker run --rm; keys are injected at spawn and gone when the container exits. No daemon sits on your cloud credentials between incidents.
Not an add-on to something you already pay for. Most of these ride on top of an existing observability or IaC subscription and one or two channels. This is a folder shape you own — read it, diff it, change it.

Honest note: per-human cloud attribution across the other tools is mostly architecturally precluded by the shared-credential design, not proven absent — their docs simply don’t offer a per-engineer path. AWS Q is the exception, within AWS. The claim here is “any keys, self-hosted, in your chat,” not “nobody else attributes to humans.”

the AWS surface, concretely

There is no special AWS connector. The agent already has the toolchain (uv, bun, gh) and reaches AWS the way an engineer would — the CLI or the SDK, reading AWS_* from its env:

uvx --from awscli aws sts get-caller-identity      # who am I running as
uvx --from awscli aws ec2 describe-instances       # read-only, safe
uv run --with boto3 python check_alarms.py         # scripted, same creds

AWS APIs need SigV4 request signing, which arizuko’s declarative REST connectors don’t do — so AWS goes through the in-container agent, not a connector. The reasoning is in the product spec.

setup

arizuko create acme --product aws-devops
cd /srv/data/arizuko_acme
$EDITOR .env                                  # ANTHROPIC_API_KEY, TELEGRAM_BOT_TOKEN, WEB_HOST
arizuko network acme allow main amazonaws.com # one entry covers every region
arizuko secret acme set main AWS_ACCESS_KEY_ID --value AKIA…   # shared fallback
arizuko run acme

# then each engineer sets their own keys at /dash/me/secrets (or via
# `arizuko user-secret`), and their calls run as them.

Full step-by-step — IAM policy shape, per-operator keys, egress, verification — is in the operator setup guide.

go deeper

secrets — folder vs user scope, the BYOA overlay, encryption at rest
grants — how the bash grant and action gating work
crackbox — default-deny egress and the per-folder allowlist
primitives — the folder-as-environment model behind prod/staging isolation
security model — ephemeral containers, tenant boundary, secret injection