Zero-Trust Architecture

Identity-first network design and segmentation, so a compromised machine cannot reach everything else, with a phased migration path from where you are today. Containment for AI agents is one workload this applies to.

AWSAzureGCPOn-premHybrid

Zero trust is an architecture, not a product purchase. The premise is that the network is not a trust boundary: reaching a system is a decision made on its own merits, weighing identity, device, and context, and a machine that gets compromised cannot walk to the next one.

Most environments are already partway there: strong authentication at the front door, a VPN, and a flat interior behind both. The interior is the work. Zero trust architecture, explained without the buzzwords is the longer version of that argument if you want it before a call.

What the engagement covers

Identity as the control point. A modern identity provider, strong authentication everywhere, and access policy that weighs device and context rather than identity alone. That includes the paths that quietly bypass it: legacy protocols, service accounts, break-glass credentials, and anything still authenticating against a directory directly.

Segmentation that assumes breach. Where the boundaries go, what enforces them, and what each side is allowed to say to the other. Microsegmentation is what keeps a compromised machine from reaching everything else, and the design names the enforcement points rather than drawing zones on a diagram.

A migration path from where you are. The target architecture is the easy half. The engagement produces a phased route to it, ordered so each phase is deployable on its own and reversible if it goes wrong. Larger engagements start with a scoped discovery phase, which exists to turn the question of how long this will take into a number before you commit, not after.

How the design is delivered

Policy as code, generated and reviewed, so the architecture is enforced rather than documented. A segmentation rule that lives in a diagram drifts the first time someone is in a hurry; the same rule in version control, with a test and a review, does not. You keep the policy repository and the pipeline that applies it.

Where teams get stuck

Buying a product and calling it an architecture. Vendors sell enforcement points, and enforcement points are useful. Which traffic is allowed, between what, and on whose authority is a design decision nobody can sell you, and it is the part that decides whether any of it holds.

Authenticating hard at the edge and trusting everything inside. The front door is excellent and the interior is flat, so the first compromised laptop reaches the file server, the build system, and the database it was never meant to see.

Designing segmentation nobody enforces. The zones exist in a document. The rules were never applied, or were applied once and drifted, and nothing fails when they do. Enforcement that is not in version control is a claim about the past.

A migration with no phase that ships. The target architecture is agreed and then waits for a quarter where everything can change at once. That quarter does not arrive, and the design ages until it has to be redone.

Where AI agents fit

An AI agent is a workload that acts with credentials, reaches services, and eventually does the wrong thing. Bounding what a workload can reach is what this engagement already does, so agent containment is a line item inside it rather than a separate product, and it can be scoped on its own when that is the live problem.

The design detail is written up separately rather than here. The agent sandbox blueprint sets out the invariants and where each one is enforced, and zulusec/sandbox-reference is a public harness that measures a sandbox you own against them. Agents are the first workload given that treatment; the method is not specific to them.

The same goes for the rest of it. Worked examples, down to the policy and the test that proves it holds, belong in the field notes rather than on this page.

What you get

FAQ

We already have SSO and a VPN. Is that zero trust?
Usually not. Single sign-on decides who you are once, at the front door; a VPN decides that you are inside. Zero trust is what happens after that: whether reaching a specific system still requires a decision, whether that decision weighs device and context rather than identity alone, and whether an attacker who lands on one machine can reach the next. Most environments with SSO and a VPN have strong authentication and a flat interior. That interior is the work.
How long does a migration take?
It depends almost entirely on how many enforcement points already exist and how much of the interior is flat, which is why larger engagements start with a scoped discovery phase. Discovery exists to turn that question into a number before you commit to the work rather than during it. A phased path is the normal outcome, because a zero-trust migration that requires one flag day is a migration nobody will finish.
Do we need a security audit first?
Not necessarily. A security audit is the smaller first step if you would rather have general posture written down before committing to design work. It asks a broader question rather than a deeper one, so it tells you where you stand, not what to build. If you already know the interior is flat, this is the engagement.
How is this different from Platform Engineering?
This decides where the boundaries go and what enforces them. Platform Engineering builds the accounts, networks, and pipelines the systems run on. In practice they meet: a segmentation decision made here lands as policy in the same repository the platform work uses. If the question is what the architecture should be, that is this page. If it is who builds the environment, that is the other one.
Does this replace a penetration test?
No. A pentest asks what someone can do against what you built. This asks whether what you built enforces the boundaries you believe it does, then changes the design where it does not. The output is a change you make rather than a list of things that worked. For full exploitation testing ZuluSec can refer a pentest partner.
Our engineers have started running AI coding agents. Where does that start?
Here, and the agent sandbox blueprint is the reasoning behind it. Containment is the question this engagement already asks, aimed at a newer workload. It can be scoped on its own, which for most teams is where it starts, but it stays one line item inside this engagement rather than a separate product, because the enforcement points are the same and the policy that holds an agent is the policy that holds anything else.
Can you measure the sandbox we already have?
Yes, and you can do it yourself first. zulusec/sandbox-reference is a public MIT-licensed harness, one probe per invariant, that runs against a sandbox you own. It ships a compliant reference and a deliberately leaky fixture, and CI asserts the first comes back clean while the second trips the same named rules, so a passing run is not passing for the wrong reason. If yours comes back clean, you may not need this engagement.

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