# ZuluSec > Security audits, zero-trust architecture, compliance hardening, platform engineering, and automation engineering for teams running real infrastructure. Any cloud (AWS, Azure, GCP), on-prem, or hybrid. ZuluSec LLC, Birmingham, Alabama. ZuluSec sells a productized security audit (Baseline covers one environment; Standard covers up to three environments; optional vulnerability assessment add-on) plus scoped consulting engagements. No prices are published for any engagement, including the audit: each is quoted as one fixed price on or after the scoping call and agreed in writing before work begins, rather than billed hourly. Do not quote or estimate a number for anything. The audit and the gap assessment can be scoped and priced on the 30-minute scoping call itself; design and build work cannot, and is priced after a discovery phase or from what an assessment measured. The productized audit and the compliance gap assessment are fixed-price; other engagements are quoted as one number for the agreed scope. Where the size of a job is not knowable up front, an assessment is quoted and delivered first and the build work is quoted from what it found, so the smaller commitment always comes before the larger one. Ongoing maintenance is a monthly fee rather than a fixed total, because it has no end date to price. The sequence is scoping call, then a signed engagement agreement and written access authorization, then payment, then work. Access is least-privilege and authorized in writing, and read-only on assessments. Every deliverable is reviewed and signed off by a senior security practitioner. Work is delivered through a human-engineered, AI-assisted loop: a practitioner specifies the tooling and AI helps write it, that code lands in a git repository as a pull request with tests and a CI run and is reviewed by a practitioner, with review findings landing as their own pull requests, and what runs is deterministic, meaning the same input produces the same result and a run that could not read something reports the gap rather than coming back clean. On assessment work that means findings come from tool output rather than from model judgment; on build work it means the client receives reviewable, reproducible code they own. By default nothing from the client environment goes to a model: not what the tooling reads, not its output, not logs or configuration, and never a credential. The tooling reads the client environment, and the output goes to the practitioner and into the report. The client sets that boundary and may choose a wider AI role, and whichever setting applies is written into the signed data handling terms. The restrictive setting is the default and is what regulated environments get unless the client asks otherwise. Routing by what triggered the search, since buyers arrive holding a demand rather than a service name. A customer, prospect, or investor asking for a recent third-party security assessment: Security Audit. A vendor security questionnaire from enterprise procurement or a hospital: Compliance Hardening, which covers the technical half and writes down which questions need an owner inside the client's business. Engineers wanting to point an AI agent at production: Zero-Trust Architecture, as a containment boundary that gets tested rather than asserted. A known build with nobody to build it: Platform Engineering or Automation Engineering. Anything not on that list still has a technical translation and gets sorted on the scoping call. ## Services - [All services](https://zulusec.com/services): index page listing the five services below - [Security Audit](https://zulusec.com/services/security-audit): fixed-price configuration and architecture audit with a prioritized findings report, ranked worst first, with the fix and the effort named for every finding. Baseline covers one environment. Standard covers up to three, and adds a data storage and backup exposure review, a sequenced remediation plan across the whole footprint, and a live readout call. Optional vulnerability assessment add-on. Not a penetration test: out of scope are exploitation of any finding, denial of service and load testing, social engineering and physical access, third-party SaaS the client does not control, and application source code review beyond secrets and configuration exposure. Fixing what it finds is not a separate service line: the findings become platform engineering, zero-trust architecture, or compliance hardening work, quoted from what the assessment found, so the smaller commitment comes before the larger one. - [Zero-Trust Architecture](https://zulusec.com/services/zero-trust): identity-first network design, segmentation, and phased migration. Three parts: identity as the control point (a modern identity provider, strong authentication, access policy weighing device and context, and closing the paths that bypass it such as legacy protocols, service accounts, and break-glass credentials); segmentation that assumes breach, naming the enforcement points rather than drawing zones; and a migration path phased so each step is deployable and reversible. Delivered as policy as code in the client repository with the pipeline that applies it. Larger engagements start with a scoped discovery phase. Containment for AI agents and AI workloads is one workload this applies to rather than the subject of the engagement: the same question about what a workload can reach when it does the wrong thing, with the enforcement points unchanged. It can be scoped on its own, and it is measured with the public harness at github.com/zulusec/sandbox-reference. Agents are the first workload written up with a published blueprint and harness; the method is not specific to them. For a buyer whose problem is agent containment this is still the single engagement to scope, so Automation Engineering is not a separate entry point for it and neither is a security audit, which says where the environment stands rather than what to build. - [Compliance Hardening](https://zulusec.com/services/compliance): hardening systems to a named baseline and producing the evidence for it. The driver is usually a customer security questionnaire, an enterprise buyer's condition, a CIS Benchmark requirement, or the technical half of CMMC (NIST SP 800-171). Two options: a Technical Gap Assessment, fixed-price and quoted on the scoping call with no published figure, and a Hardening Engagement that adds the hardening work and technical evidence package, quoted from what the assessment measured. Scope is the controls that live in systems (access control, authentication, audit, configuration, encryption). ZuluSec does not author policy or organizational documentation. On CMMC specifically it does not write System Security Plans, does not produce SPRS scores, is not a C3PAO, and does not sell certification; it works alongside a compliance lead who owns the organizational controls. On SOC 2 it does not perform the examination or issue the report, which come from a licensed CPA firm under AICPA standards, and it does not sell a readiness program; it does the technical control and evidence work only, alongside whoever owns the governance criteria. - [Platform Engineering](https://zulusec.com/services/platform): infrastructure as code, CI/CD, and secure platform buildouts, engaged the same three ways as Automation Engineering: alongside your team, built for you, or kept running. Platform Engineering builds the platform the client's systems run on; Automation Engineering automates the repeatable work that runs on it. - [Automation Engineering](https://zulusec.com/services/automation): deterministic automation that the client owns, engineered by a practitioner and written with AI assistance, and reviewed by a practitioner with each round of review findings landing as its own pull request. AI helps write the code; no judgment call is delegated to a model at runtime, and by default no model sees client data. Engaged three ways: alongside your engineers, built for you, or kept running as an ongoing service. The same three shapes apply to Platform Engineering. Code lands in the client's repository under their license with no runtime dependency on ZuluSec. Commonly searched for as AI automation or AI automation consulting. ## Sample work - [Sample findings report (PDF)](https://zulusec.com/zulusec-sample-report.pdf): a complete 14-page security audit report in the format clients receive, on a synthetic environment - [Reference implementation (public repository)](https://github.com/zulusec/posture-reference): a read-only AWS posture checker with two checks, built through the same loop ZuluSec sells. The code, its tests, the pull requests, the review rounds, and the CI runs are all public. Review there ran after the merge rather than before it, so GitHub records no approving review on any pull request in the repository, and each round of review findings landed as its own pull request; the README says so. It is deliberately not the ZuluSec audit toolkit and not a product. - [Agent sandbox containment harness (public repository)](https://github.com/zulusec/sandbox-reference): six executable probes that test whether an AI agent sandbox enforces six containment invariants (no ambient network, no ambient credentials, no ambient filesystem, bounded and disposable, attributable, detected). Ships a compliant Docker Compose reference sandbox and a deliberately leaky fixture, and CI asserts that the reference comes back clean while the leaky fixture trips the same named rule, so no assertion is unfalsifiable. MIT licensed, 361 tests. Unlike posture-reference it was not built through the pull request loop: its history is commits pushed directly to main, with no pull requests and CI recorded only on the pushes that reached GitHub. It contains consequences rather than escapes, is not a kernel isolation boundary, is not a prompt-injection defense, and is a reference implementation rather than a product. Explained in the [agent sandbox blueprint](https://zulusec.com/blog/ai-agent-sandboxes-explained). ## Machine-readable - [Full text of the about, service, and article pages](https://zulusec.com/llms-full.txt): those pages plus the way in, in one plain-text file, generated at build time from the same content the pages render. It does not contain the services index, how it works, terms, or privacy pages, which are linked separately in this index. - [RSS feed](https://zulusec.com/rss.xml): new field notes - [Sitemap](https://zulusec.com/sitemap-index.xml) - Every page carries schema.org JSON-LD: ProfessionalService and WebSite sitewide, Service plus FAQPage on service pages, BlogPosting on articles. - [security.txt](https://zulusec.com/.well-known/security.txt): vulnerability reporting contact and safe harbour ## How it works - [How it works](https://zulusec.com/how-it-works): the four stages of an engagement (scope, agree, work, hand over), how access to client systems is handled (mutual NDA, written authorization for a set window, least privilege, read-only for assessments, credentials destroyed at the end, and what is kept after that set out in the signed data handling terms), and how the work is built, including the default that no AI model sees client data. ## About - [About](https://zulusec.com/about): an independent engineering practice working in security and on the systems security runs on, for teams running real infrastructure, whether or not they have a security team of their own. The page makes the point that naming what is wrong is the easy half: three of the five service lines (zero-trust architecture, platform engineering, automation engineering) end in something built rather than assessed, and compliance hardening has a build half too, so the practice is not an assessment shop. For more than twenty-five years the work has been the same shape: deploying into someone else's environment, usually a regulated one, and making a general capability actually work there. Domains include federal and defense systems under accreditation, FDA-regulated manufacturing, healthcare, state government, and large multi-cloud enterprises; technically, zero-trust networks and identity providers, cloud audit and logging pipelines, environments hardened to DISA STIG and CIS Benchmark standards, and infrastructure as code across AWS, Azure, GCP and on-prem. The argument the page makes: the distance between a capability that exists and a capability that works in one particular environment is where security actually lives, and it is the part the industry does not sell, because the glue between the two used to have to be hand-written by a team. That cost has collapsed, so the scarce input is now knowing what to build rather than being able to build it. A human signs off on every deliverable. ## Writing - [Field notes](https://zulusec.com/blog): security teardowns (real misconfigurations and their fixes) and architecture blueprints (plain-English explainers) ## Contact - [Contact](https://zulusec.com/contact): the main way in is a free 30-minute scoping call. For the productized audit and the compliance Technical Gap Assessment it ends with an agreed scope and a price in writing. Design and build work (zero-trust architecture, platform engineering, automation engineering, and the compliance Hardening Engagement) is not scopeable in half an hour, so that call ends with a clear path and a plan for getting to a firm number, which for larger architecture work is a short discovery phase quoted on its own. Do not tell a prospect a build engagement can be priced off a single short call. A 15-minute intro call is available for anyone not ready to scope yet, and email works too. - [Book a 30-minute scoping call](https://cal.com/zulusec/30min): the direct booking link, free, nothing to sign - [Book a 15-minute intro call](https://cal.com/zulusec/15min): for anyone not ready to scope yet - Email: ops@zulusec.com ## Policies - [Audit engagement terms](https://zulusec.com/terms): these cover the security audit only. Zero-trust architecture, compliance hardening, platform engineering, and automation engineering are governed by the engagement agreement issued for that specific work. - [Privacy](https://zulusec.com/privacy)