Helping security analysts understand what an AI agent can access, what needs attention and what remains unknown.
An AI agent can have more access than its job needs. I redesigned its overview and permission review, then independently explored how to verify a fix.
The exercise centered on Research Assistant, an agent used by twelve employees. Its Knowledge Base credential had more access than its task required. Six assigned policies added another question: what did the system actually know about protection?
The overview needed to keep four facts connected.
Find information for the team. No editing or deleting required.
Research Assistant| Permission | Current | Required |
|---|---|---|
| Read | Allowed | Needed |
| Edit | Excess access | Not needed |
| Delete | Excess access | Not needed |
Two permissions too many.
Six policies assigned. Protection still unknown.
“The agent needs only read access.”
“The metaphor is excess permissions, not a malicious agent or an attack.”Excerpts from the saved generation brief.
Visual development for this portfolio case, after the exercise.
After submission
After the submission, I asked three security practitioners what they need to understand an agent and follow up on a finding.
Q&A conversations, not usability tests.
“We follow up to make sure the permissions were actually reduced.”
The owner changes access. Security follows up. This helped focus the extension on verification after the request.
A sent request still leaves the finding open.
“‘Not reported’ is a state of uncertainty, not a healthy state.”
Missing collection, an unconnected source and a failed check mean different things. The extension explores how to explain the gap.
Connected → discovered → protection still unknown.
“The first thing I want to see is what the agent can actually do.”
Permissions, data access and recent activity provide context for a review. This reinforced the access comparison already in the submission.
The task needs Read. The credential allows more.
Anonymous practitioners. Quotes translated from Hebrew, with excerpts shortened. The original request flow was designed before these conversations.
I compared how identity and AI security products describe agent context, access and remediation.
Microsoft Entra Agent ID
Astrix
Zenity
Noma Security| Product | Publicly described focus | Design implication for Ballast |
|---|---|---|
| Microsoft Entra Agent ID | Agent identity and governance | Keep identity, owners and granted permissions easy to find. |
| Astrix | Access and identity lifecycle | Connect excessive access to a concrete remediation task. |
| Zenity | Exposure, policy and runtime behavior | Show what an agent can reach alongside what it does. |
| Noma Security | Agent behavior, access and governance | Make the context of an action part of the review. |
| Ballast concept | Concept: agent overview, access review and owner handoff. | Responsible person, exact access change and evidence limits. |
Based on the linked public documentation and product pages. The design implications are my interpretation; I did not test these products. Ballast is a proposed concept, not a tested result.
Context shaped the submission. Later conversations sharpened the independent work on verification and missing data.
Compare Read, Edit and Delete with the agent’s task. Recent usage supports a conversation with the owner, rather than replacing that conversation.
See the review decisionMake responsibility and request status visible. In the extension, connect the reported fix to an evidence review.
Explore verificationAssigned policies and reported protection are different facts. A neutral Not reported state keeps the uncertainty visible.
Explore missing dataTwo working profiles keep the handoff concrete. The analyst is informed by the practitioner conversations. The owner is an assumption-based profile for this exercise, not an interviewed participant.
Security analyst
Agent owner
Original submission + independent extension
The original flow keeps the analyst in the agent’s context and ends with the finding In review. The independent extension explores the evidence needed before it can close.
Understand its purpose and owner.
See the high-severity finding and unknown protection.
Review permissions and recent usage.
Request Read-only access from Yael.
Keep it In review.
The handoff returns to security.
Compare the reported fix with current access.
Stale or unchanged evidence returns the finding to review.
Fresh Read-only evidence supports closure.
Original submission
I explored how much emphasis to give the high-severity finding, summary data and the agent’s profile. The choice was about what stays visible while someone makes a decision.
Identity and owner remain visible while the analyst reviews the finding.
Trade-off: The persistent profile leaves less space for charts.
Explanatory diagrams of the explored directions, not original wireframe exports.
The profile anchors the review. The summary cards make the current state easy to scan.
Original submission
Each decision clarifies the review, with a trade-off in space or depth.
What is this agent? What needs attention? What do we know about protection? What happens next?
Trade-off: Lower-priority detail sits one level deeper.
Explore the decisionSix assigned policies and Not reported protection appear as separate facts, with separate meanings.
Trade-off: Another summary card, but less ambiguity.
Explore the decisionPersistent identity and ownership connect the permission review to the person who can act on it.
Trade-off: Less horizontal room for the review itself.
Explore the decisionA side panel offered less room for the comparison. A modal hid the surrounding context. A focused page gives the permissions and usage room to breathe, while the agent and owner stay visible.
Original submission
The submitted flow moves from the overview to a permission review and an owner request. The later verification sequence is shown separately in the full motion study.
Purpose, owner and the current state share one overview.
Read is used. Edit and Delete were unused in the 30-day scenario. That supports a review, rather than proving future access needs.
The confirmation names Yael and states that permissions are unchanged. The request has been sent, the fix is still pending.
The high-severity finding remains visible and In review. The analyst can return to the same context.
Illustrative prototype animation. The score values shown in the video are part of the design scenario, not a validated scoring model.
Take the analyst’s seat. Review the access, ask the owner to act, then decide what the evidence actually proves.
Research Assistant only needs to read. Open the high-severity finding to see what it can actually do.
Required: Read. Current: Read, Edit, Delete.
The original product screens anchor the interaction. Later evidence paths are illustrative scenarios from the independent extension. No new risk score is calculated.
Three post-submission conversations focused my independent extension on the questions below.
Agent overview, access review and owner handoff.
Coverage, explainability and evidence of a fix.
Discovery, source connection and reported protection should not collapse into a single reassuring badge. If the cause is unknown, the interface should say so.
The breakdown makes the factors behind the scenario score inspectable. The weights are illustrative; this exercise does not establish a validated risk formula.
Security checks the owner’s reported fix against fresh evidence. Reduced permissions support closure; unchanged access keeps the finding open.
The challenge was not just showing a risk. It was making sure the interface did not promise more certainty than the data could support.
The conversations pushed me to design what happens after a request is sent: who checks the change, what evidence they need and when a finding can close.
I have not tested these flows with users. Next, I would test whether analysts and owners understand the states, requests and evidence needed to close a finding.
Changing permissions directly, investigating the two medium findings and building the rest of the product. The case study adapts to mobile; the product concept is a desktop workflow.
AI helped me explore the domain and prototype the experience. I owned the hierarchy, the treatment of missing data and the choice to keep the fix with the owner. See a visual direction I changed.
I had never worked in cybersecurity before this project. Working with AI agents made me curious: the same ability that makes them useful can also make them risky.
I wanted to understand how to make that world safer, starting with a small, concrete question: what can this agent access, and who can do something about it?
This exercise gave me a way into the field. The conversations reminded me how much there is still to learn from the people doing this work every day.
Nati
