Omkar KhadamkarAll work

Self-led design study · Firewall rules · 2026

An AI suggests changes. A person approves them.

I sorted an AI's nine suggested changes into three kinds of decision, so safe ones take one click.

Proposals this week: nine AI-proposed rule changes in three zones. Ready to accept, three low-risk rows with one Accept all 3 button. Check the evidence, one medium-risk row where two sites were silent for 20 days. Roll out in stages, five medium or high-risk rows, each with an Open request button.
The week's review: nine proposals, sorted into three zones by what the admin has to do.Feature study · Figma, 03 Screens
My decision

Slow down where a mistake would hurt. Risky changes get a reviewer and an undo.

Go deeper 2 min

A concept for reviewing the firewall changes an AI suggests every week. The company, product and data are made up, built from public information on my Vela Design System.

  • Role I set the problem, the goals and every decision; AI tools drew from my brief
  • Tools Figma, Claude Code as the spec-writing and review agent, my Vela Design System
The problem

Software can find unused or risky firewall rules. A person still has to decide, because one wrong change can block traffic people rely on.

What I made

Six screens, six edge cases, a clickable prototype of the main path, and a handoff for engineers.

My part

I set the problem, the goals and every decision. AI agents drew, researched and scored from my brief.

  1. 01An AI suggests firewall changes every week. Who approves them?The moment
  2. 02The nine suggestions fall into three kinds of decision.The real problem
  3. 03Quick approval for safe changes. A separate page for risky ones.The decision
  4. 04The admin sees missing evidence before any button.Missing evidence
  5. 05A change that could block traffic gets a preview, a reviewer and an undo.The request
  6. 06A wrong approval can be undone before it causes an outage.Being wrong
  7. 07I set the problem, the goals and the decisions. AI drew the screens from my brief.How it was made

01The moment

An AI suggests firewall changes every week. Who approves them?

A person still has to say yes, and every step of that check can go wrong.

The admin's week, and where each step goes wrong

  1. 1 · NoticeNine look like nine equal jobsSo the review gets put off.
  2. 2 · SortThe risky one gets skimmedBecause the others looked fine.
  3. 3 · Check"No traffic" read as "unused"While two of four sites sent no logs.
  4. 4 · DecideAn accept blocks trafficThat nobody expected.
  5. 5 · Roll outThe monitor is too shortTo catch a job that runs weekly.
  6. 6 · UndoThe way back is slowOr nobody can say why the rule changed.
Go deeper 1 min

Every Monday the AI suggests rules to disable, narrow or merge.

Why this problem

Rule bases collect rules nothing uses, rules an earlier rule already covers, and rules far broader than the traffic they carry. Firewall guidance asks for specific rules and periodic review (NIST SP 800-41). Finding these can be automated. Deciding can't be handed over. After years on security consoles, it was the next problem I wanted to work on.

The trap

Research on AI-assisted decisions found that an explanation makes people more likely to accept the AI's advice whether or not it's right (Bansal et al., 2021). So the design question isn't how to show nine proposals.

Who it's for

  • The network security admin who owns the rule base.
  • Not drawn, but designed for: the change approver who signs off, and the auditor who later asks why a rule changed. Both read the change log the admin leaves behind.

These costs are reasoned from the task and public sources. They haven't been observed with admins.

02The real problem

The nine suggestions fall into three kinds of decision.

Safe changes are approved in one click, missing evidence is shown first, and risky changes roll out in stages.

The same week after the safe group was accepted: three rules on a 30-day hold, P-302 deferred in Check the evidence because Ferrymoor and Saltmarsh were silent from 15 Sep to 4 Oct, and P-304 monitoring in Roll out in stages. A banner says Saltmarsh hasn't sent logs since Thu 8 Oct, so proposals that depend on it are held.
ABC
The week after one click on "Accept all 3".Feature study · Figma, 03 Screens
  1. A
    Safe changes go together. Unused for 90 days with full logs: disabled for a 30-day hold, never deleted.
  2. B
    The gap comes first. Two sites were silent for 20 days, so "no traffic" isn't evidence.
  3. C
    Risky changes roll out in stages. Each one opens as its own request.
Go deeper 1 min

The sample week

An invented company with four sites and 20 rules. Nine proposals arrive on Monday 5 October 2026, from a 90-day observation window: three ready to accept, one with a gap in its evidence, five medium or high risk.

Evidence before risk

A risky proposal with a gap in its log coverage goes to Check the evidence first. You can't judge the risk of a change while the data behind it is incomplete.

Edge states I drew

  • An empty week, loading, and a week that failed to load, with Try again.
  • A site that stops reporting: every proposal that depends on it is held, with a banner that says why.
  • An admin without permission to enforce, who proposes the change to a change approver instead.
  • An approver policy that sends every change for sign-off, previewed on the week before saving.

03The decision

Quick approval for safe changes. A separate page for risky ones.

I compared six layouts on the same data. The final one combines the best two: groups for the week, and a page for each risky change.

Lo-fi option F: the week in three zones. Ready to accept with Accept all 3, Check the evidence with P-302 already open showing the rule's traffic, log coverage by site and Defer, Reject, Accept anyway buttons, and Roll out in stages with an Open request button on each row.
F: B's zones, with the gap case already open; each risky row opens D's request page.Feature study · Figma, 02 Explorations, lo-fi

The trade. F asks for an approver only when a change can block traffic. Everything else is recorded with its reason in the change log.

Go deeper 2 min

Criteria first

Seven criteria grew from the questions in my brief; an evaluator agent weighted them and added an eighth, and I confirmed the set. The two that count three times: a coverage gap can't be missed before accepting, and what would stop working is on screen before any action that can block traffic.

Six directions

  • A, list and side panel. Fast, but evidence, impact and the rule diff share 480 px.
  • B, three zones. Sorted by the work; gave up grouping by type.
  • C, one at a time. A heavy week of 90 proposals means 90 screens.
  • D, pull request. Full review, but slow, with an approver on every change.
  • E, inline in the rule base. No view of the week.

Too close to call, so I asked a question

AI evaluator agents scored A to E twice, one pass blind. B (73.0 of 90) and D (69.5) were under the 10% close-call gate, so no winner. I asked whether a combination could score higher. F came first in both passes of round three: 75.0 against D's 65.5 and B's 65.0. Confidence is medium: the blind pass was stricter, and in it F only ties D on the two heaviest criteria.

04Missing evidence

The admin sees missing evidence before any button.

Approving anyway is allowed, but they have to write down why.

P-302 opened in place. A warning reads 2 of 4 sites sent no logs for 20 days. Per-site bars show Northgate and Eastbank at 90 of 90 days and Ferrymoor and Saltmarsh at 70 of 90, with the last 20 days drawn dashed. The weekly hits chart shows the missing weeks dashed, not as zero. A side form, Accept with a gap in log coverage, asks for a reason that goes into the change log.
ABC
P-302, on the branch where the admin chooses to accept despite the gap.Feature study · Figma, 03 Screens
  1. A
    What's missing, in words. Above everything else on the card.
  2. B
    Silence shows as a gap, not as zero hits. Dashed in the site bars and in the weekly chart.
  3. C
    Accepting anyway is allowed. It asks for a reason, which goes into the change log.
Go deeper 1 min

The main path is to defer until the logs are complete.

Why a sentence, not a warning

Explanations made people more likely to accept AI advice whether or not it was right (Bansal et al., 2021). Designs that force a moment of thought reduced over-reliance more, though people rated them lowest (Buçinca et al., 2021). Both studies used general decision tasks, not security admins, so they support the concern, not a number.

What I threw out: an evidence-strength grade

A label such as strong or weak would be one more judgement stacked on the AI's own. The card states what was measured instead: the observation window, how many sites reported, the dates of any gap, and whether logging was on. The admin does the grading.

The target it serves

8 of 10 admins notice a planted gap in the logs before accepting. A target set before drawing, not measured.

05The request

A change that could block traffic gets a preview, a reviewer and an undo.

The system suggests, a person decides, and the screen shows the impact before anything is blocked.

Request P-304: narrow R-1015 from all ports to 443 and 80. A stepper reads Preview, Monitor, Approve, Enforce. The rule before and after with the port row highlighted. What would be blocked: 14 sessions on TCP 8080 from two partner addresses at Northgate, all on Fridays. A rollout box with a 7-day monitor that covers a Friday, an approver and a 14-day rollback window, and the buttons Accept, monitor first, Defer and Reject.
ABCD
One risky change, opened as a request.Feature study · Figma, 03 Screens
  1. A
    Preview, monitor, approve, enforce. Nothing is blocked until the last step.
  2. B
    The rule, before and after. All ports narrowed to 443 and 80.
  3. C
    What would break, in words. 14 partner sessions on 8080, all on Fridays.
  4. D
    The monitor fits the evidence. Seven days, so it covers a Friday.
Go deeper 1 min

Where the request page came from

From option D: the preview, the staged rollout, the approval and the audit trail live on one page that outlives the week. From the scoring fixes: the rollout plan suggests a monitor that matches the rule's traffic pattern, and the page says where the admin lands after each decision.

Who signs off

A change approver is asked only before enforcing. An admin without permission to enforce sends the change to the approver with a reason, and the approver's view shows what the monitor saw, including whether it covered a Friday.

06Being wrong

A wrong approval can be undone before it causes an outage.

The admin can overrule the suggestion, and the override is visible and easy to undo.

The same change, down two paths

P-304 in the Monitor step after the suggested 7-day monitor. A note reads 3 sessions on TCP 8080 would have been blocked on Fri 9 Oct; the change was only monitoring, so nothing was blocked. The change is deferred until the rule owner confirms, with buttons to ask the rule owner or revise the change to keep TCP 8080 from the partner gateway.
12
The path the design steers to: the suggested monitor, kept.Feature study · Figma, 03 Screens
  1. 1
    The monitor catches Friday. Three partner sessions would have been blocked. Nothing was.
  2. 2
    The change waits for the rule owner. Or it's revised to keep the partner's port open.

Prevention first, recovery second. The suggestion and the warning are there to stop the outage; the rollback is there for when they're overruled.

Go deeper 1 min
  1. 1PreviewWhat would be blocked, for whom, and when.
  2. 2MonitorLogs what the change would block. Nothing is blocked.
  3. 3ApproveA change approver signs off.
  4. 4EnforceThe narrowed rule starts blocking.
  5. 5Roll backOne action restores the rule, for 14 days.

Why two paths

The first version told one story: a 3-day monitor missed the Friday traffic and the change was enforced. A cold read found it undercut the design, as if the failure were the main path. So the prototype follows both: the suggested monitor kept, and the override with its way back.

Two windows, on purpose

  • A disabled rule is held for 30 days and can be switched back at any time. Nothing is deleted.
  • A narrowed rule can be restored in one action for 14 days, to the policy version before it. The 14 days is my choice.

The target it serves

0 of 5 seeded cases where an accepted change blocks traffic the admin didn't expect. A target set before drawing, not measured.

07How it was made

I set the problem, the goals and the decisions. AI drew the screens from my brief.

The goals came first: three targets, written down before any drawing. None has been measured yet.

< 2 min

to clear a typical week's safe changes

Target · not measured
8 of 10

admins notice a planted gap in the logs before accepting

Target · not measured
0 of 5

seeded cases where an accepted change blocks unexpected traffic

Target · not measured

Targets, not findings. Public research supports the concerns behind them, not the numbers. Nothing has been tested with admins yet; that's the next step.

Who did what

MeThe problem and its limits, the targets, the confirmed criteria, the tiebreaker that led to F, sign-off on every story change, and what goes out.
A builder agentDrew every frame, component and note from my written brief and sample data, one step at a time.
A research agentGathered the standards, papers and public documentation. I opened the key ones myself.
Evaluator agentsScored the options twice, one pass blind, and read the file cold, as someone with ten minutes would.
Feature-local components from the study file: tags for type and risk, a log coverage summary with per-site bars where gaps are dashed, a weekly hits chart with complete, zero and partial states, and a key value row.
Parts Vela didn't have, built only from Vela's variables and proposed back to it.Feature study · Figma, 07 Components
Go deeper 1 min

Built on Vela

The only library enabled is Vela, my public design system. Every colour, text style, radius and gap is bound to a Vela variable. Where Vela had no component, the part was built from its variables only, named local, and written up as a request to the design system rather than borrowed from another kit.

What I threw out

  • Options A to E. They stay in the file with their scores, so the choice can be checked.
  • The evidence-strength scale.
  • The side panel: the first pick opened a proposal beside the list.
  • The first P-304 story, which became two paths.

What's in the file

Problem and flow, explorations and scores, screens, states and edge cases, a wired prototype, handoff notes with the assumptions to test and accessibility notes, components, and the AI log.