Automation Engineering

Deterministic automation you own: designed by a practitioner, written with AI, and reviewed with the findings kept on the record. The same input returns the same result, and the code lives in your repository.

AWSAzureGCPOn-premHybrid

An engineer states what the automation needs to do and AI helps write the code. The code lands in a git repository as a pull request carrying its tests and a green CI run, a practitioner reviews it, and each round of review findings lands as its own pull request rather than being folded in where nobody can see it. What ships is deterministic: the same input produces the same result, a run that could not read something reports that gap instead of coming back clean, and no judgment call is delegated to a model at the moment the work runs.

By default nothing from your environment goes to a model. A wider AI role is available if you want the speed, and whichever setting applies is written into the data handling terms you sign. How it works sets out the boundary.

Why it is built this way

The git and pull request loop is the control framework. Every change has a diff, an author, a reviewer, a test result, and a history, which is what turns "the AI generated this" into something your compliance reviewers already accept.

For security work that is a requirement rather than a preference. A model's opinion is not a finding; the API response is. A hallucinated HIGH severity destroys credibility permanently, and a result that cannot be reproduced is worthless to an assessor.

Most of the market sells AI agents as oracles: trust the agent to do the work. ZuluSec sells the opposite: trust the AI to build the tool that does the work, then read the tool it built.

Where it fits

Anywhere the same work happens repeatedly and the answer has to be the same every time. Evidence collection for a compliance cycle. Posture checks across accounts. Access reviews. Log and alert pipelines. Report generation from tool output rather than from someone's memory.

It is not a fit where the work genuinely requires human judgment each time. ZuluSec will say so during scoping rather than automate something that should not be automated.

What one change looks like, from the public reference

The request

The S3 check reads Block Public Access only at the bucket level. AWS applies it at two levels and the effective setting is the union of both, so an account that turns it on account-wide and configures nothing per bucket comes back as a wall of false HIGH findings. Fix it, and make the evidence say what is actually true.

What it generated

-    config = _public_access_block(s3, name)
-    disabled = sorted(
-        setting for setting in _BPA_SETTINGS if not config.get(setting, False)
+    config, configured = _public_access_block(s3, name)
+    not_enabled = sorted(
+        setting
+        for setting in _BPA_SETTINGS
+        if not (config.get(setting, False) or account_config.get(setting, False))
     )

The test that shipped with it

def test_account_level_block_public_access_clears_an_unconfigured_bucket():
    """The preferred posture: account-level BPA fully on, no bucket-level
    configuration anywhere. Reading only the bucket level raises HIGH on every
    bucket in such an account."""
    s3 = FakeS3(["a", "b"], pab={}, policy_status={"a": False, "b": False})
    assert _run(s3, FakeS3Control(ALL_ON)) == []

What the review checked

The review went after the way this change could quietly lie. If the account-level lookup is denied, the tool knows less than it would with both levels in hand, and the risk is that it keeps reporting as though it had checked both. The reviewer traced that path and confirmed the finding narrows its wording to bucket level rather than claiming a union it never read. No defect, and the check is the point: the failure worth hunting was not a crash, it was a sentence that would still have sounded right.

The trail it left

Pull request 12, with its tests, which took that file from eight to seventeen, and a green CI run. Review in that repository happens after the merge and its findings land as their own pull requests, which the README names. None of it was reconstructed afterward.

Read the pull request

What you get

FAQ

Is this an AI automation service?
Yes, with a qualification. An engineer designs it and AI helps write the code, but AI makes no decision at runtime and by default never sees your data: it produces the tooling, the tooling reads your environment, and the output goes to a practitioner. What ships is deterministic, and you can read it, test it, and change it without ZuluSec.
Do I own the code?
Yes. It lands in your repository under your license, and there is no hosted service you have to keep paying for in order to read it, change it, or run it yourself. Where ZuluSec is the one keeping it running, ending that arrangement means you take over running it rather than losing it. The code, the pipeline, and the history are yours either way.
If you keep it running, who holds our credentials?
You do. The repository, the pipeline, and the accounts are yours, and the access ZuluSec uses is issued by you, scoped to the minimum, and authorized in writing for the window you set.
How is this different from hiring someone to write scripts?
The output is not a script on someone's laptop. Every change arrives as a pull request with tests and a CI run, and it is reviewed, with a diff and a history. That is the same control framework your auditors already accept, applied to automation.
What if the AI writes something wrong?
That is what the tests and the review pass are for. Every change ships with its tests, CI runs them on the pull request and again on main, and the result is on the record. Review is by a single practitioner, and in the public reference it ran after the merge rather than before, which is why GitHub records no approving review there. Each round of findings landed as its own pull request rather than being squashed out. Not a promise that no bug ever ships: a promise that every change carries a diff, a test result, and a review you can go read.
Can I see something real rather than a description?
Yes. github.com/zulusec/posture-reference is a public reference implementation built exactly this way. The code, the tests, the pull requests, the review rounds, and the CI runs are all there to read.
What is the difference between this and Platform Engineering?
Platform Engineering builds the platform your systems run on. Automation Engineering automates the repeatable work that runs on it. Both are engaged the same three ways: alongside your team, built for you, or kept running.

How the engagement works

There are three ways to engage, the same three for every build service, so the choice is about how much you want to do yourselves rather than which product to buy.

Alongside your team

You have engineers and want the pattern established. ZuluSec sets up the structure, builds the first pieces with them, and hands it over with a runbook.

Built for you

You know what it needs to do and have nobody to build it. Every change arrives as a pull request carrying its tests and a green CI run, in your repository and under your license, reviewed by a practitioner.

Kept running

You have nobody to hand it to, so ZuluSec keeps it maintained and current, still in your repository and still auditable. Billed monthly, cancel with notice.

The first two are quoted as one number, agreed in writing. When the size of the job cannot be known up front, an assessment comes first and the build is quoted from its findings, so you commit to the smaller number before the larger one. Keeping it running is a monthly fee, because ongoing work has no end date to price.

Access works the same way whether the work is being built or kept running: you issue the credentials, scoped and authorized in writing, and you revoke them at the end. When the engagement ends, everything stays in your repository. How an engagement works covers the detail.

Book a scoping call