I design the human-facing layer around agents that act on their own inside a security product — how a person reads an unattended run, redirects it, undoes it, and stays accountable for it. It reaches public preview in early August 2026, so this page argues the practice rather than the screens.
Security work arrives fragmented. Incidents in one surface, alerts in another, threat intelligence as articles, posture findings somewhere else again. Every practitioner opens their day on the same three questions — what changed, where is my risk, what should I work on first — and spends the first twenty minutes reconciling surfaces by hand before any judgement happens. That much is true of nearly every security team and none of it is secret.
Autonomous agents can absorb a great deal of that work. The trap is that dropping them into a fragmented product produces one more fragmented surface: powerful, and unusable.
So the design question isn't “what should the agents do.” It's what does a team need to see first, and how does autonomy become something they can safely reach for from there? Everything below follows from that ordering.
“Security team” is not a persona. These are industry-standard roles, and they want opposite things from the same autonomous system. The one thing they share is that none of them wants to be trained on it first.
“Tell me what changed overnight and what I can safely close.”
Working a queue under time pressure. Wants volume taken off the top and a fast, legible reason for every auto-closed item. High tolerance for autonomy on cheap-to-undo actions — and the undo has to be one click and obvious.
“Show me what the agents are permitted to do, and what they cost.”
Accountable rather than operational. Rarely reads a single investigation; reads aggregates, permission scopes and spend. Their surface is governance — the meter, the identity model, the audit trail.
“Follow this hunch, and let me redirect you when it drifts.”
The steering case. Long, open-ended investigations where the goal shifts as evidence arrives. Needs mid-flight control far more than approval gates — stopping and restarting a two-hour hunt is the failure mode.
Those three jobs pull in incompatible directions, and the resolution is the part I'm proudest of: the system adapts to the person rather than asking them to configure it. What surfaces first is ranked by what's available now, what's genuinely urgent, and what this person has done before.
Which raises the harder question. Adaptation people can't see is indistinguishable from a system behaving erratically. If the queue reorders itself and nobody says why, an analyst stops trusting the ordering. So every adaptive surface carries a plain-language reason for its ranking and a way to say “not this” that visibly changes what comes next. This is where responsible AI stops being abstract for me — personalisation without legibility is just an unaccountable system with better manners.
A static dashboard can't answer those three morning questions, because it doesn't know who is asking. Everyone gets the same cards, so everyone stitches context together by hand before judgement starts.
A dashboard shows you everything. A brief tells you something.
So we've been testing a different shape: an opinionated daily briefing that behaves less like a dashboard and more like a narrative — composed at runtime around the reader's role, current intent and permissions, saved and rehydrated with fresh data each morning. You start from a template, pin more views as your job changes, and recompose in natural language when your intent shifts.
The part I'd defend is the fixed order. Every brief runs summary → evidence → recommendation → action, in that sequence, for every role. Compose the structure per person as well as the content and nobody ever learns the product — a surface that rearranges itself just reads as broken.
The three roles don't just want different content — they want different shapes. The same catalogue composes into three canonical layouts, chosen by the job rather than the data:
Adaptive interfaces fail in a specific way: the user can't build a mental model, because the thing they're modelling changes underneath them. Personalisation without a stable spine reads as instability, and in security — where the cost of missing something is the whole point of the product — instability is disqualifying.
Fixing the narrative order gives the reader one thing they can count on. They learn where the recommendation lives once, and it's there every morning regardless of what generated it. That's what makes the composition underneath it safe to vary.
This one is a hypothesis with a working proof of concept behind it, not a shipped result — and it would be dishonest to present it otherwise. Validation with practitioners is the next step, scoped around the four things most likely to be wrong: whether a composed brief actually beats the dashboard people already have, where templates stop helping and start demanding configuration, how much evidence belongs in a brief before it stops being one, and whether that fixed order really holds across all three roles. First round targets SOC analysts, using interviews then scenario-based concept testing rather than a demo-and-ask.
This is the hard part, and the reason the problem is interesting well beyond security. If an agent composes the UI at runtime, what stops it producing something inconsistent, unlearnable, or subtly wrong?
The answer we landed on: the agent doesn't generate layout, it selects from a catalogue. Composition happens over reusable primitives and cards carrying semantic rules about what may contain what, what may sit beside what, and which card types can hold an action. The model chooses and arranges within that grammar. It never invents a component.
The catalogue is a ladder, and the agent is only allowed on the top rung. Climb it to see where its freedom actually is:
Which converts an open-ended generative problem into a constrained one — and constrained is what makes it reviewable. A composition can be checked against the rules, so a bad one fails a check rather than reaching a practitioner.
A conventional design system documents intent for humans: use this card for this kind of content, don't nest these. Those conventions live in a component library and a page of guidance, and they hold because designers read them.
An agent doesn't read guidance. So the same conventions have to be expressed as machine-checkable semantics attached to the primitives themselves — what this card means, what it can hold, when it's the wrong choice. That's a real shift in what a design system is: less a library of parts, more a grammar a machine can be held to. I think it's the most transferable thing I'm working on right now.
I designed and built the composable POC spec-first — the composition rules, the catalogue semantics and the narrative order written as a spec, with the implementation generated against it and answerable to it. Not a prompt that produced a plausible screen, but a decision the code has to satisfy.
The toolchain is the same one I argue for on the shipped work: a Figma MCP server wired both ways, so the component catalogue is one source that the design file and the running composer both read and write — no one-way export to drift out of sync. VS Code with GitHub Copilot for the build against the spec, and Playwright — browser automation — driving the agent through composed layouts to check they hold up when something other than a human assembles them. The method is the point: an AI-composed interface is only trustworthy if the thing composing it is held to a written grammar, and the same discipline has to run through how the tool itself is made.
These aren't written after the fact. They're the tie-breakers I use whenever autonomy and safety pull in opposite directions, and I use them in review to make the trade-off explicit rather than aesthetic.
What they have in common is the thing I'd most want understood: every point of human control exists so agents can run more autonomously, not less. A reliable undo, a legible run, a way to redirect mid-flight — each is what makes it defensible to hand an agent a longer leash. Teams that skip them don't get safer agents; they get agents nobody is willing to let out of sight.
An agent nobody can audit is an agent nobody authorises twice. Reasoning shows as evidence and conclusion, not as a chat log.
How much an agent may do alone is decided by how cheaply a mistake can be undone — not by how confident the model is.
If the person spending capacity can't see the meter, the product will fail them mid-investigation. Consumption belongs in the session, not the admin console.
An agent should hold its own least-privilege identity rather than borrowing a person's whole access footprint.
Teaching an agent should show what will change before it changes, and stay reversible afterwards.
The model's confidence never sets what an agent may do — reversibility and identity do. But the person still needs to see it, so it's shown as its own signal, separate from what's allowed.
A small team needs a safe default; an enterprise needs every axis pinnable. The same surface has to do both without becoming an admin console.
Most agentic systems I've looked at wire autonomy straight to model confidence — the surer the model, the more it does alone. That quietly hands the throttle to the least accountable part of the system, and it's the decision I split hardest against. Autonomy is governed by reversibility and identity, decided up front by a person. Confidence is a separate thing the reader is shown — how a finding was reached, how sure the model is, where it's shaky — so a practitioner can calibrate their own trust rather than inherit the model's.
The distinction matters because the two failures look identical from the outside and are opposite underneath. A confidence number that silently decides what already happened is a system spending the user's trust without telling them. The same number, shown plainly next to the evidence and kept away from the throttle, is what earns trust — because now a person can disagree with it. Legible confidence is a trust signal; confidence-as-throttle is a liability wearing one.
RBAC — role-based access control — is the rule that decides who may do what. In security products it's usually treated as configuration: a table of roles somewhere in an admin console. The moment an agent can act on its own, it becomes an interface problem, because the question stops being “what is this agent capable of” and becomes “under whose authority is it acting right now.”
There are three ways an agent can hold authority, and they are not interchangeable. It can act on behalf of the person who started it, inheriting their whole access footprint. It can hold its own scoped identity. Or it can run on a connected account — a shared service credential nobody is individually accountable for. Same agent, same capability, three completely different answers to “was this allowed?”
Pick an identity on the left, then an action. Switch identity and watch the same row change verdict — that's the whole argument: capability is constant, authority isn't.
Read the “change a conditional access policy” row across all three identities. Deny, then ask, then allow — and nothing about the action changed. That's why I push for scoped agent identities over connected accounts, and it's the argument that lands with security stakeholders when an autonomy debate stalls.
The row I'd defend hardest is the last one. Deleting audit logs is denied to every identity, permanently, because the audit trail is what makes every other permission on that list reviewable. Some actions shouldn't be reachable by an agent under any authority, and deciding which is a design judgement rather than a policy default.
Identity systems already know how to express all of this. What they can't do is make it legible to the person accountable for it, at the moment they're deciding — and that gap is mine to close.
Autonomy debates stall on capability — can it do this? — and they unstick when you reframe them as identity: under whose authority, watched by whom, and undoable by whom? Getting a team to that question is a design contribution, and it's usually worth more than the screen it produces.
Six habits carry this work. Two of them have numbers — method figures from my own design process, not the product's outcomes, which wait for preview.
A hunt can run for hours, and nobody sits and watches it — they start it, leave, and come back. So the question isn't “is there a spinner,” it's can someone tell, an hour in, whether this is going well enough to keep paying for. I design the run state to answer that without being read end to end: what it has established, what it's currently pursuing, and what it has ruled out. Ruled-out is the one people forget, and often the most valuable thing a long run produces.
Approve-or-kill is the default binary in most agentic products and it's too blunt for open-ended work. Killing a two-hour investigation to correct one wrong assumption throws away everything the run got right. I push for mid-flight steering — narrow the scope, discard a branch, correct an assumption while the work continues. It's harder to design than a stop button because it has to be legible about what your intervention will and won't undo, but it's the difference between an agent you supervise and an agent you delegate to.
Conventional research can't reach the edges of a non-deterministic system — recruiting can't reliably produce the analyst who hits the rare failure mode. I built a synthetic-persona and AI-simulated testing framework to red-team agent trust, transparency and override behaviour before launch: adversarial evaluation for a system that never behaves identically twice. Roughly 30% fewer live research cycles, and it surfaces edge cases recruiting misses.
Collaborating with AI in my process isn't only faster prototyping — it's evaluation. I built a Six Thinking Hats critique agent in Copilot Studio and run a flow or a spec through it before I take it to review. It hands back a structured critique across the six lenses — the risks and failure modes ranked, what's working and worth protecting, what the heuristics say, the gut reaction a first-time user has, concrete alternatives, and a synthesis that names the single highest-leverage change to make next. It doesn't replace my judgement; it makes sure I've argued the opposite case before I commit. Built solo.
I introduced MCP (Model Context Protocol) design workflows connecting Figma, VS Code and GitHub Copilot, so design and engineering iterate against the same live component state instead of drifting between a mockup and an implementation. Roughly 25% less design-to-development handoff time.
I lead design on this work — setting strategy, running critique, and holding the trust and transparency standards across what ships. Day to day that means working directly with PM and engineering rather than through a handoff: backlog grooming, feasibility, and the argument about where a human has to stay in the loop, settled in the same conversation where the design question came up. I also manage and mentor a team of four designers and researchers, which is where most of these principles get pressure-tested before they reach a product review.
The through-line: the AI-composed UI model itself — a design system a machine can be held to — is the most transferable thing here, and the reason the problem is interesting well beyond security.
At public preview this page becomes the complete case study: the surfaces themselves, the lifecycle from session initiation through management, the cost and consumption model, the autonomy framework in full, and the outcome figures.
If you're reading this before then and want the detail, ask me in an interview — I can walk through all of it, including the parts that didn't work.
This work builds on a prior chapter at Microsoft (2021–2024), where I led design strategy for Docufy, ExpenseGo and Legal Ease — three AI-powered platforms across contracting, expense management and compliance. I presented AI UX frameworks at the 2025 MSD Impact Series to the Senior Leadership Team, helping shape org-wide responsible-AI design standards.
Live modelPowered by GPT-4o Grounded in Sayena's case studies, not a canned bot. Billed per question — so make them good ones.