Every Firewall Policy Starts the Same Way.

• Not with a firewall rule.
• Not with a protocol.
• Not with a configuration screen.

It starts with someone saying,

“Can doctors securely access patient records from hospital-managed devices?”

It sounds like a simple request, but behind that sentence are dozens of security decisions. Who should have access? Which application is involved? Should remote access be allowed? Does it meet compliance requirements? Could one mistake expose the network? The request takes seconds to describe, but making the right decision can take hours.

Business outcomes

Stakeholders speak in plain language

Translation

Administrator bridges both sides

Firewall expects

Identities, zones, protocols, policies

When I joined the project, I thought we were redesigning firewall policy creation. After spending time with security engineers, I realised the real challenge came much earlier. We weren’t redesigning firewall policies—we were redesigning how administrators understand a business request before it becomes one.

The Real Work Happens Before the Firewall

One security engineer said something I’ll probably remember for the rest of my career.

“Writing the policy isn’t the hard part. Understanding what people actually mean is.”

That sentence changed how I looked at the product.

We Were Solving the Wrong Problem

After several research sessions, our workshop wall was covered with sticky notes. We had captured everything we heard:

• Applications
• Identity
• Compliance
• Existing Policies
• Risk
• Business Language
• Trust

Individually, they felt like disconnected observations. Together, they revealed something much bigger.

Administrators weren’t struggling to create firewall policies. They were translating business conversations into technical decisions.

A Familiar Problem, Different Industry

I often explain this challenge using Google Maps.

Imagine typing,

“Take me to the airport.”

Instead of showing directions, Maps asks for GPS coordinates, routing algorithms, and road classifications.

Everything is technically correct. Nothing helps you reach the airport. Traditional firewall products often worked the same way. They asked administrators to think about firewall objects before helping them think about the business problem.

People don’t think in ports, protocols, or policies. They think in outcomes.

Policy Copilot simply flipped that order.

Start with intent. Let configuration follow.

Four Principles Shaped Everything

Once we understood the real problem, the design principles became surprisingly clear.

By the end of discovery, we weren’t designing a tool that generated firewall policies. We were designing one that helped people make better security decisions. Everything that followed—from the interaction model to the final workflow—was built around that idea.

Designing Understanding Before Automation

The goal wasn’t to generate a firewall policy. It was to help administrators understand what they were about to approve.

By the end of research, we realised every policy started as a business request but ended as technical configuration. Somewhere between those two worlds sat the administrator, translating outcomes into secure decisions.

Policy Copilot wasn’t designed to replace that expertise. It was designed to make the journey from business intent to trusted policy faster, clearer, and easier to understand.

Start With Intent, Not Configuration

Traditional firewall products usually begin with configuration.

• Source
• Destination
• Application
• Protocol
• Ports
• Logging

Every field assumes the administrator already knows the technical answer.

Policy Copilot starts with a different question:

“What are you trying to achieve?”

Administrators no longer had to translate a business request before opening the product. They could simply describe the outcome. The product handled the translation. People stayed focused on the problem. The firewall received the configuration it needed.

Understanding Before Generation

Like many AI products, our first prototype generated a policy immediately. It worked—but it answered before proving it had understood the request.

So we slowed the experience down. Before generating anything, Policy Copilot reflected its understanding back to the administrator.

The First Draft Wasn’t the Policy

During usability testing, one pattern appeared again and again. Administrators rarely edited the generated policy first.

They corrected the AI’s interpretation instead:

• User groups
• Applications
• Remote access
• Missing context

That changed our thinking.

People preferred reviewing meaning before configuration. So we changed what “first draft” meant. The interpretation became the first draft. The firewall policy became the second.

One Workspace, Not Five Screens

Most enterprise products move people through a series of screens. We wanted the opposite. One workspace where the conversation, the context, and the policy stayed together.

As administrators confirmed details, the workspace gradually expanded:

• Users
• Applications
• Network zones
• Access conditions
• Compliance

Every new card was connected to the original request. Nothing appeared out of nowhere.

The policy wasn’t generated in a single step. It was assembled one decision at a time.

Make AI Thinking Visible

One design principle guided almost every interaction. Never make administrators wonder what changed.

Whenever the AI updated the workspace, it clearly explained:

• What changed
• Why it changed
• How confident it was
• What still needed confirmation

Nothing appeared without context. Nothing felt like a black box.

The goal wasn’t to make administrators trust the AI. It was to make its thinking easy to understand.

One Moment Changed Everything

During one internal review, an engineer looked at the prototype for a few seconds and said,

“This doesn’t feel like writing firewall rules anymore.”

He paused. Then smiled.

“It feels like reviewing someone else’s work.”

That was exactly the experience we were trying to create. The AI wasn’t the author. It was the first reviewer. The administrator remained the final one.

Designing Trust

The hardest question wasn’t “Can AI generate a policy?” It was “Should I trust it?”

Once Policy Copilot could understand a request and draft a policy, the challenge shifted. In enterprise security, a policy is only valuable if someone is confident enough to approve it.

One security architect captured it perfectly:

“I don’t mind if AI writes the first draft. I mind if I can’t explain why I’m approving it.”

That insight shaped the rest of the product. Trust wasn’t something we added at the end—it had to be designed into every interaction.

Validation Became Part of the Conversation

Our first idea was straightforward: Generate → Validate → Fix → Deploy.

It looked logical, but it didn’t reflect how administrators actually worked. Research showed that experienced administrators validated continuously. Every decision raised another question:

• Does a similar rule already exist?
• Could this affect another application?
• Does it meet company standards?

Validation wasn’t a final step. It was part of the decision-making process. So instead of adding another validation screen, we embedded validation into the workspace. As administrators confirmed users, applications, and access conditions, Policy Copilot quietly checked:

• Existing policies
• Compliance requirements
• Security standards
• Duplicate rules
• Network segmentation
• Potential impact

Nothing interrupted the workflow. The product surfaced issues only when they mattered.

Explain the Recommendation, Not Just the Result

Usability testing revealed another important insight.

Administrators rarely asked, “What should I do?”

They asked, “Why are you recommending this?”

That changed how we designed recommendations. Instead of simple alerts, every suggestion included the reasoning behind it.

For example, if Policy Copilot recommended enabling audit logging, it explained why:

• The application handled sensitive healthcare records.
• Similar policies already enabled logging.
• Organisational standards required an audit trail.

Instead of asking administrators to trust the recommendation, we gave them the context to make their own decision.

Let the AI Admit Uncertainty

Another design decision was surprisingly simple. If the AI wasn’t sure, it said so.

Instead of making assumptions, it asked for clarification:

• Should remote access be allowed?
• Should contractors inherit these permissions?
• Should access expire automatically?

Rather than reducing trust, those moments increased it. In enterprise security, admitting uncertainty is often safer than pretending certainty.

Help People Review Impact, Not Configuration

Before approving a policy, administrators wanted one answer:

“What happens if I deploy this?”

Instead of asking them to interpret firewall rules, Policy Copilot simulated the outcome:

• Who gains access
• Which applications become reachable
• How traffic paths change
• The potential impact

Administrators stopped reviewing configuration.

They started reviewing impact.

Human Approval Was Never Optional

One principle never changed.

No matter how confident the AI became, it could never deploy a policy. It could:

• Understand intent
• Interpret requests
• Recommend actions
• Validate decisions
• Simulate impact
• Optimise policies

The final approval always belonged to the administrator.

That wasn’t a technical limitation—it was a product principle. Enterprise security depends on accountability, so AI supports judgement, but people make the final decision.

The Real Product Was Confidence

Looking back, I don’t think the product we designed was a validation engine.

It was confidence.

Every interaction—from clarifying intent to explaining recommendations and simulating impact—helped administrators answer one simple question:

“Do I understand this well enough to move forward?”

Once they did, approving the policy became the easiest decision in the workflow.

One Workspace. One Conversation.

The most successful part of the experience wasn’t any individual screen.

It was the continuity.

The original request stayed visible, every decision built on the last, and the entire workflow happened in one shared workspace.

By the time the policy was approved, it no longer felt AI-generated. It felt like a decision the administrator had made—with AI helping along the way.

What Changed — and Where I’d Take It Next