How does an AI agent earn
permission to act?איך סוכן AI מרוויח את הרשות לפעול?

Overview

Automation a security team can see into

In my demo, a small security team at a health insurer guards card numbers and patient records across many cloud accounts. When a storage bucket goes public, automation could fix it in seconds. But a rule that removes access on its own can also cut off a link that real work depends on.

So teams either don't automate, or automate blind. Tidewall is my concept for a third way: an AI agent that drafts a rule from plain words, shows what it understood and would touch, and asks permission before changing data.

Open the prototype Open the Storybook Open the Figma file

My role. A self-initiated concept, solo. I took an old brief for a rule builder toward an agent-centric experience, to learn data security (DSPM) and to practise designing for AI agents. Research, UX, UI, the coded prototype, design system and usability session are mine. One question shaped every decision: how does an AI agent earn permission to act?

---

The users

Three people, one rule

Marcus writes the rules. Dana is on call and approves any step that changes data. Elena reads rules to show an auditor what happens. The author can never approve his own rule's destructive steps.

---

The problem

Fast or safe, pick one

Security automation rules are usually a form: a trigger, conditions and actions. The form says what a rule is, not what it will do. Marcus can't see which buckets it will touch, and Dana is asked to approve a change without its reason.

The original brief asked for that form, plus a bonus question: how could the interface build trust? I made the bonus question the project.

---

How I worked

Trust as the brief

The goal came first: a team should never be surprised by what a rule does. Then the user stories:

• A benchmark of seven tool groups. The market split between AI that owns the workflow and an engineer who authors with AI helping. I took the middle: copilot first, agentic once trusted.
• A test script as acceptance criteria. Every flow written as Marcus, Dana and Elena would walk it.
• One usability session so far. Moderated and remote, with a full-stack developer, on the coded prototype: only real code could show an AI reading a typed request.

---

Design decision 1

The conversation leads, and the rule is what it makes

The problem

My first build was a rule builder with an assistant beside it. On 23 October I named what bothered me: "the overall concept doesn't feel to me like agent centric UX."

Tidewall shows how it read the request before anything else. The rule sits beside the conversation, starting with its map. What the request didn't say, Tidewall asks.

---

Design decision 2

Show what it would touch, then what it did

The problem

A rule's conditions don't say which resources it touches or who loses access.

The map got the session's clearest praise: "The diagrams are really excellent." But P1 couldn't tell if it showed what the rule would change or had already changed. So it split into What it covers and What happened, and the backtest became recommended, not required.

What the rule would act on. Nothing here has happened. Left out of this rule, in words that say what happened.

Each action says what came of it: done, or waiting. Removing access is still waiting for Security on-call.

---

Design decision 3

Risk decides who says yes

The problem

A Slack post can't break anything. Removing public access can take a live site down.

Notifications run on their own. Removing access waits for a person, every time. Watch first: matches are logged, and nothing is removed.

If nobody answers in time, the default is to do nothing and escalate. And approvals go where Dana is: a Slack message, then a decision on her phone, with what Tidewall checked in front of her.

Removing access is never one tap in Slack. Dana decides on the review page. What Tidewall checked, in one line. Approve with Face ID, from wherever she is.

---

Design decision 4

Say what you understood, one question at a time

The problem

An agent that reads plain words can misread them. "PCI or PHI" and "PCI and PHI" are one word apart, and they match very different data.

Each answer is logged, and the value becomes yours. Removing access anyway is an option, with its cost written beside it.

The fix: chat and rule are now fully synced. A change in either shows in the other, with Undo.

---

Process

Designed in Figma, built in code, with Claude

I designed in Figma and built with Claude Code as a partner, keeping the decisions mine. Gemini helped explore illustration styles.

• A decision log. Every decision dated, with the options and the reason.
• Drafts first. Every change shown to me as a draft, then approved, kept or reverted.
• One source of tokens, synced to Figma variables, and the same components in Storybook and Figma.

---

Outcome

What one session changed

The proof isn't a shipped metric. It's a working prototype, a design system, and what the first session changed.

• "Is it doing something, or is that it?" Before: no way to tell if an action had run. After: every action is planned, waiting or done.
• Approval questions skipped. Before: "approver" and the 2-hour window were unclear. After: asked in order, with the window labelled as time to respond.
• Control in the wrong place. Before: turning a rule on only worked through the chat. After: activate, pause, resume and delete from the rule itself.

What I would do differently

Recruit security people before the first session, not after. One developer is good at finding where a flow breaks, and weak at judging a security call.

---

What next

Put it in front of security people

Two or three more sessions, with people who write security policies. First, the check P1 never reached because of prototype gaps: will people catch Tidewall reading "or" as "and"? Then P1's question. He expected a nudge to the data owner, since a public link to patient data may be shared with a clinic on purpose. Should access ever be removed automatically?