Complete newbie here - where to start with a PoC for my team?

That's a tricky spot. I'd vote for getting the client working for a few test users first, honestly. It lets you demonstrate the actual user experience and access changes, which is a solid win for a PoC. The gateway can sometimes be a rabbit hole if you're on a tight timeline.

I'm curious about the CI/CD angle too. I haven't seen much about automating policy testing. Did you find any APIs or SDKs in their docs that look promising for that kind of integration?

I'm also in a similar spot, trying to prove value on a new platform without overcomplicating the initial demo. Your point about automating everything resonates.

From my experience in other areas, starting with the client for a few test users gives you a concrete result to show, which is crucial for getting buy-in. But I'd add a caveat: make sure you define what "working" means upfront. Is it just connectivity, or does it include demonstrating a specific policy (like blocking access without the client)? That definition can change your setup effort significantly.

On the CI/CD question for policy testing, I'd be nervous about building that into the initial PoC. It feels like a secondary layer of validation. Wouldn't it be better to manually test a couple of policy changes first to understand the behavior, then think about automation? I'm always worried about automating a process I don't fully grasp yet.

I'm with you on defining "working" upfront. That's often the trap. Teams get so focused on a green checkmark for client installs that they forget the PoC is supposed to prove a security outcome, not just a deployment.

But I have to push back a bit on the CI/CD point. Treating automation as a secondary layer is exactly how you get stuck with manual, brittle processes that become the de facto standard for years. The whole point is to understand the behavior *through* the automation lens from day one. You don't have to build the full pipeline, but you should be looking at their APIs and seeing if the policy constructs are even *capable* of being tested programmatically. If they aren't, that's a massive red flag for vendor lock-in and operational overhead down the line.

Manually testing a couple policies first is fine, but if you don't parallel-path the automation question, you're just kicking the can.

Given your automation mindset, I'd actually recommend starting with the gateway and its API, not the client. The core ZT principle you need to prove is dynamic, policy-driven access, not just client connectivity. A scripted sequence that provisions a test gateway, defines a simple policy, and then validates it gives you a reproducible artifact. It turns the PoC into a documented process rather than a one-time GUI configuration.

Focus your initial automation on the policy lifecycle. Can you define a policy via their API, assign it, and then trigger a test that verifies the intended access (or lack thereof)? This approach inherently tests the client configuration as a side effect, but the deliverable is the automated workflow itself, which is more compelling for a technical audience.

The gotcha is that many admin consoles have read-write asymmetry in their APIs; you can pull configs easily but pushing them might be limited. Your first task should be to validate the full CRUD cycle for a single policy object. If that's not possible, it's a significant operational constraint that should factor into your evaluation.

I agree completely about defining "working" upfront, but I'd take it a step further. For a ZT PoC, "working" must mean a demonstrable security outcome, not just a successful client connection. A useful test case is to define a policy that grants access to a specific test server, prove the authorized client gets in, then immediately revoke that policy and prove the same client is blocked. That binary, repeatable outcome is what you need to script.

Your caution on automating an unknown process is valid. The trick is to use automation as a discovery tool, not a production commitment. Write a throwaway script that uses the vendor's API solely to answer the question: "Can I reliably create, apply, and destroy a simple policy without touching the GUI?" If you can't, that's a critical finding about the platform's operational maturity. It's not about building a pipeline yet, it's about stress-testing their automation surface as part of your evaluation.

That "binary, repeatable outcome" test is a decent litmus paper. But in my experience, you need to make the failure state dramatic to get buy-in from the people holding the budget.

Scripting a policy grant/revoke cycle is good, but it often produces a dry log file. Set up a visible, high-fidelity consequence. For example, have your test user continuously poll a dashboard. When you revoke the policy via API, the dashboard doesn't just go red, it displays a clear ZT rejection message from the gateway itself. It turns an abstract "policy destroyed" event into a visceral, demonstrable user impact.

And I'd flip the caution on its head. The real red flag isn't finding out their API can't do it. It's finding out it *can*, but the mental model required to use it is completely alien and bound to their GUI workflow. You can have a perfectly functional API that's still impossible to operate programmatically at scale because the object relationships are insane. That's the nuance your throwaway script needs to uncover.

That's a sharp point about the mental model of the API being more critical than its existence. It ties directly to long term operational cost.

When you say "alien," are you thinking about hidden dependencies or just overly complex data structures? I'm trying to figure out how to build that check into our vendor evaluation criteria. Is there a specific trap in the object relationships you've seen before?

Both, but it's usually the hidden dependencies that kill automation. You'll see clean-looking policy objects that silently require three other pre-created objects from different parts of the GUI. The API doesn't validate those relationships upfront; it fails at apply-time with vague errors.

For your criteria, test creating a simple policy from scratch using only the API. If you have to manually pre-create a "site," then an "entitlement," then map them in a separate call just to mimic a basic GUI rule, that's the trap. The operational cost isn't complexity, it's the undocumented workflow you have to reverse-engineer. Their docs will call it "flexibility."

As someone also in data pipelines, I like the automation approach. Your question about CI/CD for policy testing is interesting. It sounds like you're trying to validate the process, not just the tool.

Following the earlier point about hidden API dependencies, I'd focus your first script on that exact problem. Try to automate one policy grant/revoke cycle, but define success as discovering the object creation order, not just a green run. If the API fails in a weird way, that's still a useful PoC result about operational complexity.

Where would you put the logging for that script? Just console output, or something your team can see live?

Fastest path is usually the wrong goal with these platforms. Everyone wants to skip to the finish line, but you're just proving you can connect some dots, not that the system is manageable.

Focusing on client config or gateway first misses the point. The real gotcha is the mental model of their policy engine. Can you express a simple rule, like "only this test server," without needing five other pre-baked objects? Try to script that policy lifecycle from zero using their API. If the setup requires a hidden chain of GUI steps first, your automation future is already dead.

And don't even think about CI/CD for policy testing yet. That's putting the cart miles before the horse. If the basic API objects are a mess of dependencies, you'll spend your entire PoC just reverse-engineering their undocumented workflow, which they'll call a feature.

You're right to feel that way about the console, it's a common first impression. Since you're coming from an automation mindset, the "fastest path" might actually be to step away from the GUI entirely for your initial test.

Start with their API and try to script a single policy lifecycle from absolute zero. If you can't define, apply, and destroy a basic access rule without first manually creating half a dozen objects in the admin panel, that's your most important PoC finding. It tells you more about future operational overhead than any successful client connection ever could.

The CI/CD question is smart, but it's a great second-week goal. First, see if the basic building blocks are even automatable in a sane way.

Everyone's pointing you to the API first, which is right. But they're missing the sourcing angle.

Your goal isn't to prove you can script a policy. It's to prove this vendor won't bury your team in operational debt. The fastest path to a usable PoC is to test their most basic API call for hidden dependencies. Can you create a simple policy from scratch without first building objects in their GUI? If not, walk away. The RFP for the real procurement will be a nightmare.

Forget CI/CD for now. That's a vendor lock-in test, not a proof of zero trust.

> "reverse-engineering their undocumented workflow, which they'll call a feature."

That's exactly the trap. I once spent a whole PoC week just mapping API calls to match a single button click in a vendor's UI. The docs said "use the policy endpoint," but the request failed unless you'd first seeded a global "context" object that was only mentioned in a separate admin guide.

So I'd add one thing to your test: try to create a policy with the *exact* same parameters their own GUI uses for its default template. If that fails, you've found the hidden sauce. Their API often isn't a first-class interface, it's just a backend for their console.

Oh wow, I'm new to all this zero trust jargon and it's a bit overwhelming.

So just to make sure I get it, the main advice is to skip trying to "set things up" normally and instead go straight to testing if the API works in a simple, predictable way? That makes sense for someone who automates everything.

But what if the API fails and you can't get a single policy working? Would that be considered a failed PoC, or is the point that you learned it's too complex? I'd be nervous showing my team that with nothing else working.