Capability

Your AWS account, in plain English

Read EC2, S3, Elastic IPs and EBS, spot what is quietly costing you money, and make changes only after you approve them.

Create an account See the full flow

EC2 S3 Elastic IP EBS volumes EBS snapshots Security groups Bucket policies Versioning and encryption IAM access keys STS session tokens Every AWS region

In your words

Ask it like this

No syntax to learn. These are real requests, phrased the way people actually phrase them.

›which account am I actually in ›is anything in this account open to the internet ›what is costing me money that nobody is using ›why is this instance running but not responding ›how big is this bucket and what is filling it up ›stop the staging instances, we do not need them overnight ›is this bucket public

Capability

What it does here

Everything below is what the agent does today, not a roadmap.

Lists EC2 instances including stopped ones, with their real state and status checks
Flags security group rules open to 0.0.0.0/0 without you reading a single CIDR list
Finds unattached Elastic IPs and idle EBS volumes, which are billed whether you use them or not
Summarises a bucket by size, folder, storage class and age, without ever reading your files
Starts, stops, reboots and tags instances, each one confirmed before it happens
Cannot change security group rules, delete volumes or read object contents at all

What it looks like

One question, one answer, one fix

The checks on the left of each reply are the reads it did before committing to an answer. That is the difference between a diagnosis and a guess.

Every exchange ends in a verified outcome. It goes back and confirms the result rather than assuming the fix worked.

brynko devOps Agent

anything in this account open to the internet?

checked which account read 14 security groups read 6 Elastic IPs

Account 3397…0876, ap-south-1. Two rules are open to the whole internet: sg-0a41 has 22/tcp from 0.0.0.0/0, and sg-0b77 has 5432/tcp. SSH and Postgres, both world-open. I cannot change security group rules, so those two need doing in the console.

what am I paying for that nobody is using?

listed volumes listed addresses listed instances

Three things. Two Elastic IPs are attached to nothing and are billed hourly regardless. Four EBS volumes totalling 320 GiB are in state available, meaning attached to nothing. And staging-worker-2 has been running for 41 days with no status-check activity. I can stop the instance if you want; the volumes and IPs I will not delete.

Read-only · nothing changed

Common cases

The ones that cost you an afternoon

Each of these is a specific failure with a specific set of checks behind it, not a general promise to help.

Something is open to the internet

Security groups accumulate. Somebody opened a port for an afternoon two years ago and nobody has read the rules since.

What it does. It reads every group and tells you which rules are open to 0.0.0.0/0, precomputed, so you are not parsing CIDR lists out of nested JSON. It cannot change the rule for you, by design, so it tells you exactly which group, port and range to fix.

The bill is creeping up and nobody knows why

Unattached Elastic IPs and detached EBS volumes are billed hourly forever, and nothing in the console puts them in front of you.

What it does. It lists both and marks which are attached to nothing, so the ones you are paying for and not using are a short list rather than an audit.

The instance is running but the service is not

The console says running, so the console is no help. The application is unreachable and you are guessing.

What it does. Running is not healthy. It reads EC2 status checks, which fail independently of the instance state, and tells you whether the box itself is failing or only the software on it.

Is this bucket public

The answer lives in three places at once - the bucket policy, the public-access block and the ACLs - and a policy document is dense enough that eyes slide over the one statement that matters.

What it does. It reads the policy, versioning, encryption and public-access block together, and scans the policy for statements granting access to everyone with no condition attached. A public grant is called out as public, not buried in a findings list.

Nobody is sure which account this is

An instance id looks identical in staging and production. Confidence is the only thing distinguishing them, and confidence is not a safeguard.

What it does. It reports the account id and the exact IAM identity before anything irreversible, and every approval is bound to that account and region, so an approval given for staging cannot be replayed against production.

You need to know what is in a bucket, not what is in the files

You want totals, the biggest objects and which prefix is eating the space. What you do not want is customer data pulled into a chat log.

What it does. It answers with structure and numbers only - counts, sizes per folder, storage classes, oldest and newest. There is no code path to fetch an object body, so files cannot leak into a conversation even by accident.

Start to finish

What happens between the question and the fix

You add an access key once
Stored encrypted on your own machine and never sent to the model. No tool takes a key as an argument, so a key cannot end up in a prompt or an audit row.
You ask a question
AWS is reached over its API using that key. It does not go looking for AWS on your servers, and it does not need one.
It reads, and it says which account
Reads are free and unprompted. Before anything irreversible it reports the account id and IAM identity, because an instance id looks the same everywhere.
You approve a change
Start, stop, reboot, terminate, launch, tag, or an S3 change. You see the account, the region, the exact resource and an explicit warning when the action cannot be undone.
Some things it simply will not do
Security group rules, the S3 public-access block, releasing an Elastic IP, deleting a volume or a snapshot. Not blocked - absent. If one of those is the fix, it tells you the exact change to make and stops.

The part that matters

Reading is free. Changing asks first.

Reads run instantly and need no permission, because reading cannot break anything. Anything that changes a system, whether that is a restart, an edit, an install or a delete, stops and tells you what it is about to change, on which server, and why. You see it written out, as the command it will run or a red and green diff of the file, so you are approving the actual thing rather than a description of it. Changes are backed up first, so undoing one is a click.

Read the security model

Questions

Aws, specifically

Can it delete my infrastructure?

It can terminate an EC2 instance and delete S3 objects or a bucket, and each of those needs your explicit approval with the account, region and an irreversibility warning shown first. It cannot delete an EBS volume or a snapshot at all - there is no code path for it.

Can it change my security groups?

No, and not because it is switched off. The functions do not exist in the codebase, and there are tests that fail if anyone adds them. If a rule is the problem it reports the group, port and range and stops, rather than looking for a way round it.

Can it read the files in my S3 buckets?

No. The S3 surface answers what is in a bucket with structure and numbers - counts, sizes, prefixes, storage classes, dates. There is no call that fetches an object body, so your files cannot reach a model context even by mistake.

Where do my AWS keys live?

Encrypted at rest on your own machine, decrypted only in memory when a call is made. They are never sent to the model, and no tool accepts a key as an argument, so a key cannot appear in a prompt, a confirmation or an audit entry.

How does it know which account it is in?

It asks AWS, using the saved credential, and reports the account id and IAM identity. Every approval token is bound to that account and region, so an approval given while pointing at staging is rejected if the credential later resolves to production.

Does it support temporary credentials?

Yes. A session token can be stored alongside the access key for STS credentials.

Will it launch a fleet of instances by mistake?

It launches exactly one instance per approved action; the count is fixed in code and is not a parameter. It also cannot set UserData, so it cannot decide what a new instance runs at boot.

Also covered

The rest of the stack

Ask Jenkins what went wrong

Read jobs, builds, the queue and console logs, find out why a build failed, and trigger or stop builds with your approval.

It runs on your machine too

Build, run and fix projects on your own computer, including installing the runtime the project needs.

A real file editor for your Linux servers, no nano required

Browse your Linux servers as a file tree and edit files in a real editor with syntax highlighting, find and replace and search across the whole box. Over the SSH access you already have, with nothing installed on the server.

Docker, without memorising the flags

Inspect containers, read logs, check stats, restart services and run Compose stacks, just by describing what you want.

Your reverse proxy, explained and fixed

Test configs before they go live, read the right log, and reload safely, on nginx, IIS or Tomcat.

Ship it, and know what shipped

Run your existing deploy scripts, watch the output live, and get a straight answer about whether it worked.

Try it on something that already annoys you

Point it at one server. You will know within an hour whether it earns its place.

Create an account See pricing