work / Icite
Building Icite: from the seed round to agent-native threat detection
Visit Icite
My role
I joined Icite before there was a team, helped raise a $5M seed round, and have led product and design ever since. I set the product strategy, designed the brand and hundreds of screens and flows, and led design as Icite grew from identity threat detection into visibility over AI agents.
- Role
- Head of Product and Design
- Other roles
- Brand, marketing sales and Fundraising
- Results
- Raised seed round. Sold to first customer. 10 customers currently
- Time
- Oct 2024 → Current
Icite is an Identity Threat Detection platform. It is the only Identity security tool that allows you to see what agents are acting on behalf of whom, and, what is that agent doing. Because of our unique data plane it finds threats that go unnoticed by your SIEM, CSPM and EDR tools.
Starting from nothing
Before there was a team, I helped raise the seed. Once it closed, I refined the vision, wrote the product strategy, designed the brand mark and started building the product with 5 engineers. Since then I’ve designed and iterated on hundreds of screens, flows and prototypes. I’ve also met investors, sold the product and worked directly with design partners.
I knew early on that maintaining our own system would have slowed every release. While there is a certain joy in creating and maintaining a system specific to your product, I decided to use Shadcn instead. It met both engineering’s and design’s needs, and it’s a part of why a small team could move this fast.
One of our earliest iterations of the identity record
Where it has evolved to.
Foundational requirements
From the beginning we knew we wanted this tool to be performant. We didn’t want analysts waiting around for queries to run. We were all too familiar with that pain with traditional SIEMs. A lot of the decisions early on were focused on speed and response times. This was a joint effort on behalf of engineering and design.
Shift: Agent visibility
In about 16 months, the market went from “AI is kinda cool”, to “there are agents everywhere, we have no idea what they are doing and who has one”.
By the time this shift came around, we had built infrastructure that allowed us to widen our focus slightly from Identity threat detection to including agent visibility and detection.
We worked closely with our design partners and narrowed our focus on a few core questions:
- a) What employees in our environment are using agents?
- b) What vendors were they using?
- c) What permissions did they have?
- d) What are those agents doing on behalf of those employees?
“My biggest concern is non-technical staff. We have no way of knowing what it’s doing[agent] with their permissions. The way we are currently going about this—it’s restrictive. We are stopping people from doing work.”
Treating agents as first-class identities
We expect agents to be managed in identity providers just like people, often working unprompted on scoped tasks. So in Icite every agent is its own identity. Its actions show in event logs under its own name, not its owner’s, and it gets its own API credentials.
Icite’s MCP experience is built for agents first.
Users of Icite can drag in threat intel or indicators of compromise, describe the threat, and get a production-ready detection in about five minutes. That used to take hours or weeks.
Agents get different tools, such as access to the raw SQL. They can combine what they know about their own environment with our structured data to build complex alerts.
Creating findings that analysts and their agents trust
We spent a lot of time refining the alert → triage → investigate → resolve → tune workflow.
This is where most of the grunt work happens in a SOC. The problem is, most tools, like a SIEM only have visibility into one data type (e.g. log events) and a lot of the data in those logs is usually tossed out to keep costs down. All of this causes way more work on an analyst, trying to chase down all the required evidence.
We solved this in two ways
Our data plane. When a detection fires, Icite validates it, triages it and pulls all the evidence for the analyst.
Orient and act. We built the finding as a narrative: what happened, who it involves, and the evidence. Whoever picks up the alert, person or agent, starts already oriented. They have all the evidence and one-click prompts that let them ask follow-up questions immediately.
“We’ve actually had our agents dismiss findings from Icite, only for us to tell it to go talk to Icite’s agent and discuss. Our agent comes back and realizes that it’s wrong. This has been incredible for us.”
This approach has proved successful and we’ve grown increasingly confident because multiple customers have had their internal agents question the validity of findings, only to be shown evidence from our agent and changed their conclusions.
How I work now, and what it means for design teams
In nearly three years the product UI has changed, my workflow and tooling have all changed and, I’ve watched the need for single roles merge into more multi-faceted roles.
I’ve moved from a pure design role into a hybrid of product management design and frontend engineer. I design and iterate in code, test and push PRs.
Because of this I think teams change. I’d hire individuals who have a strong sense of agency and who are comfortable with ambiguity. Smaller teams per problem work increasingly well. It’s becoming more of a requirement that all teams have a fundamental understanding of the entire product, the market and the customer. Personally, having engineering and design spend time deeply understanding the problem and scoping a specific use case has proven invaluable.