About
Security findings arrive faster than any one person can read them. On a Nordic digital marketing and directory-services company’s AWS estate, they had been arriving for years, with a single operations engineer expected to keep up. The backlog had grown into the thousands, and genuine exposure was hidden inside it: a publicly accessible storage bucket, and a database engine running past end of life with encryption at rest switched off.
Rather than present a proposal, Firemind ran a live deployment of its IT Operating Engine inside the client’s own AWS development and QA account over two months. It read that entire estate, turned a backlog no team could read into a ranked set of remediation proposals, and closed real exposure, with the riskier changes held back for human sign-off.
Scope: the engagement ran on a single AWS development and QA account over two months, not the client’s wider production or corporate estate. All figures on this page relate to that environment.
Challenge
Security was one more responsibility resting on a single operations engineer, and findings arrived far faster than anyone could triage them. Exposure built up quietly in the background:
- Findings outpaced the team. The AWS security tooling generated thousands more findings than one person could read, let alone resolve, so real issues sat mixed in with noise.
- Aged components carried hidden risk. End-of-life database engines remained in service, including an Aurora MySQL 5.7 instance with encryption at rest switched off, and dozens of serverless functions were still running on retired runtimes.
- Misconfigurations went unnoticed. A publicly accessible storage bucket and orphaned security groups dating back as far as 2015 had built up with no continuous control to catch them.
The client needed security and compliance handled continuously, with a clear sense of what mattered most, not a point-in-time assessment that aged on a shelf.
Solution
Over two months, Firemind ran autonomous cloud operations on the client’s AWS development and QA estate, powered by its IT Operating Engine. It ingested the AWS security stack, including AWS Security Hub, Amazon GuardDuty and Amazon Inspector, read that entire estate, and acted on what it found. Every action executed inside the client’s own AWS account, audit-logged, with human approval on anything high-risk.
Ingests Security Hub, GuardDuty and Inspector inside the client’s own AWS account.
Turns roughly 10,000 findings into a ranked set of remediation proposals.
Closes real exposure autonomously, holding higher-risk changes for approval.
Posture is tracked on an ongoing basis, so drift is caught as it appears.
The live deployment proved three things:
-
A backlog of around 10,000 findings became a ranked list of proposals. The estate’s security tooling had produced roughly 10,000 findings, far more than a single engineer could ever read. The engine triaged all of them into prioritised, engineer-ready remediation proposals, separating genuine exposure from noise so the team could act on what actually mattered.
-
A publicly exposed storage bucket was closed without a person touching it. A publicly accessible Amazon S3 bucket, created by a user with excessive permissions, was remediated autonomously by blocking public access. Long-standing exposure was closed during the run, not just flagged in a report.
-
It asks before acting on anything risky, by design. The engagement ran deliberately conservatively. The engine remediated lower-risk exposure autonomously and routed anything higher-risk, such as a medium-risk security group change, to a person for sign-off. With the human-in-the-loop guardrail proven in production, autonomy can be widened with confidence as trust builds.
None of this ran unchecked. The client kept full control over what could auto-execute, what needed approval and what was blocked:
Auto-executed
Routine remediations applied straight away, such as blocking public access on an exposed S3 bucket.
Held for approval
Higher-risk changes routed to a person first, such as a medium-risk security group change.
Blocked
Actions outside policy never run. The client decides where that line sits.
Results
Triage came first: the full backlog became ranked, engineer-ready proposals. From there the highest-priority exposure was actioned, a publicly accessible S3 bucket remediated autonomously and the rest flagged or routed for approval, rather than 10,000 changes pushed through blind.
Running live in the client’s AWS environment over two months, the deployment strengthened security posture without adding a single person to the team. Beyond the findings above:
- Around 10,000 findings triaged in two months, with no added headcount. A backlog that would take a stretched engineer months by hand was worked through by the engine, while the team’s single operator stayed on higher-value work.
- Posture, not snapshots. Security shifted from a point-in-time assessment to continuous monitoring, so drift is caught as it appears rather than discovered later.
- A funded path forward. The engagement has progressed into commercial business case discussions, with container vulnerability remediation scoped for a next phase.
The client gained a security posture that is surfaced, triaged and kept under control on an ongoing basis. Its single engineer was freed from an unwinnable triage backlog to focus on higher-value work.
