Setu Parimi is Co-Founder and CTO of RiskProfiler. He spoke to CXO XPERTS about agentic AI, attackers’ use of automation and why attack surface management is more than an asset list.
You co-founded RiskProfiler in 2023. What gap did you see in the security market that convinced you the company needed to exist?
Security teams have plenty of alerts. What they lack is context. They cannot easily tell which threats matter or how unrelated risks can combine into a real attack.
A leaked credential shows up in one tool. A lookalike domain shows up in another. A compromised vendor appears in a third, and an exposed cloud asset in a fourth. Each tool flags a genuine risk, but none links them or explains the business impact. Teams end up piecing together fragmented intelligence and sorting thousands of findings to decide where to act first.
My co-founders and I came from cybersecurity leadership, penetration testing, cloud security and third-party risk. We saw a basic mismatch. The industry was built around separate product categories, but attackers work across all of them. They do not care whether something is brand protection, dark web intelligence, external attack surface management or supply chain risk. They chain small weaknesses into real attack paths.
So we set out in 2023 to build one intelligence-driven platform that views an organisation’s external footprint the way an attacker would. It links assets, identities, executives, brands, vendors and emerging threats into one view of risk.
Now we are taking that further with agentic AI. Specialised intelligence agents find exposures, correlate threats, map attack paths and help teams prioritise fixes by real business risk
What does a CTO at a cybersecurity startup spend most of their time on, and how has that changed as the company has grown?
In year one, nearly all my time went into building. I wrote code and designed the data pipeline and the knowledge graph beneath it. I also sat with early customers to learn which alerts they acted on.
Today my time splits three ways. The first is the architecture of KnyX. That covers how we scope agents, what evidence they must collect and how we score and log verdicts. These choices are hard to reverse, so I stay close to them.
The second is customers and partners. I spend a lot of time with CISOs and with our MSSP and channel partners in India, Australia, New Zealand and the Middle East. The best product input comes from watching how a team really triages. I still go to Black Hat and DEF CON as well. This year we ran one-to-one demos of the KnyX agents there.
The third is trust. That means security reviews, SOC 2 and ISO 27001 evidence, and the tough questions buyers ask about how AI touches their data.
The biggest change is that I have moved from writing the answer to building the team and the system that produce it. The skill I use most now is saying no. One agent that investigates reliably is worth more than five that demo well.
AI can produce confident but wrong answers. How do you validate KnyX’s findings so security teams can trust them?
We start with one rule. The model does not decide what is true. The evidence does.
KnyX agents follow fixed, structured investigation steps, the same ones a senior analyst would take. They do not reason freely. For a lookalike domain, they check registration data, DNS, hosting and certificates, and whether a live phishing page is running. Each result is saved as evidence and must pass a schema check to count. The verdict is the conclusion of that evidence, with a confidence score. It is not an opinion the model formed alone.
We also cross-check. A vendor-breach claim from one source is not treated as fact until other trusted sources back it up. Credential checks run only against domains we have verified the customer owns, and only through identity providers the customer has authorised.
Everything is also reproducible. Each investigation records its inputs, outputs, evidence and execution history, plus the versions of the agents and skills used. If an analyst disagrees with a verdict, they can see how it was reached and where it went wrong. Trust in a security tool does not come from never being wrong. It comes from being checkable.
You recently launched an MCP Connector for AI assistants. Why does this matter, and how do you see security teams working with AI assistants over the next few years?
Most security teams have enough data. They lack the time to find it. An analyst who wants to understand one domain may open five modules, filter each and stitch the answer together in their head.
With the MCP Connector, they can ask, “What does RiskProfiler know about this domain?” They get exposure, digital-threat, credential and vendor context in one answer, and can keep asking follow-ups. A CISO can ask for a morning briefing and see what changed overnight across the attack surface, vendors, brand and identities.
Two design choices matter most. RiskProfiler stays the system of record, and the assistant sees only what that user is already allowed to see. The connector is an interface layer, not a new home for data. We launched with Claude, and ChatGPT and Gemini are planned.
Over the next few years, I expect the assistant to become the front door to security tools. Analysts will start with a question rather than a dashboard. Dashboards will become the place to verify, not to search. The vendors that do well will have data trustworthy enough to query in plain language, with permissions that hold. The assistant helps a qualified person move faster. It does not replace their judgement.
How are attackers using AI, and how is that changing the way you design defences?
The biggest shift is cost. Reconnaissance, phishing kits, lookalike sites and credential testing once took a skilled person’s time. AI has made each one cheap and fast. Convincing impersonation sites go up in minutes. Phishing copy reads cleanly in any language. Credentials from stealer logs get tested at scale.
In September, Gambit Security published research on a campaign against online retailers that used a set of AI agents. Separate agents handled target selection, vulnerability discovery, intrusion and card skimming, at roughly $25 per target. When an attack costs that little, attackers can afford to try everyone.
That changes our defence design in three ways. First, we automate the investigation, not just the detection. If attackers automate the attack, defenders cannot investigate every alert by hand. That is why we built KnyX Autonomous Investigations. Second, we measure the time from exposure to fix. We look for the one fix that breaks an attack path, rather than a longer alert list. Third, we treat AI as attack surface. Exposed model endpoints, AI APIs and data pipelines now appear in external scans. We monitor them like any other internet-facing asset.
How do you balance moving fast on AI features with security and privacy commitments such as SOC 2 and ISO 27001?
I do not see it as a balance. Our compliance programme is what lets us move fast. If every AI feature runs through the same controls as the rest of the platform, we do not have to re-argue security each time we ship.
In practice, four things hold. AI features are in scope from day one. Access control, change management, logging and vendor review apply to agents just as they do to everything else. Agents get least privilege. Each one has only the narrowest access its job needs. A credential-investigation agent can touch only verified customer domains and the identity providers the customer has authorised. Behaviour is versioned. Every agent and skill carries a version, and the version used goes into the audit trail, so any change in behaviour traces back to a release. And new interfaces inherit old permissions. The MCP Connector uses the platform’s existing permission model rather than a new one.
Where we do slow down is on actions. Reading and correlating data can ship quickly. Anything that changes something in a customer’s environment, such as resetting a password or filing a takedown, sits behind customer-defined policy and gets more review before release.
Many vendors now say they are “agentic.” What does that mean in practice at RiskProfiler, and where do you still keep humans in the loop?
For us, agentic means the system does the investigation, not just the detection. A KnyX agent takes an alert and gathers the evidence an analyst would. It reaches a verdict with a confidence score and, where policy allows, acts. We call the loop Alert, Investigate, Verdict, Remediate. Today we have agents for leaked credentials, lookalike and typosquatted domains, live phishing pages, vendor-breach validation and threat-intelligence filtering.
“Where policy allows” is the key phrase. For every remediation action, the customer decides whether it runs automatically, goes to a person for approval or stays off. Most teams start with approvals on, watch the agent work and then turn on automation one action at a time. A CISO at one of our retail customers told us it was the first time he could explain autonomous response to his board. Every action had a policy and an audit trail behind it.
Humans stay in the loop in three places. They set the policy, and no agent decides its own permissions. They approve actions that touch identities, customers or third parties until they choose to automate them. And they review thin evidence. A low-confidence verdict is a question for an analyst, not an instruction to act.
Which industry according to you is the most challenging to protect, and why?
Seen from the outside in, retail. That surprises people, who expect me to say finance or healthcare.
Banks have large security teams and regulators who force investment. Healthcare is hard too, with legacy systems and medical devices that are tough to patch. Retail has a different problem. The brand itself is the attack surface. Every promotion, seasonal campaign and new market creates domains, landing pages, apps and social accounts. Attackers clone them within hours as fake stores, fake support lines and phishing pages. Customers cannot tell the difference, so the fraud lands on the brand.
Retailers also depend on third parties. They include payment providers, logistics firms, marketing agencies, franchisees and e-commerce plugins. Each one is a way in. Most retailers guard all of this with a security team that is small next to their footprint. The AI-driven campaigns against online stores this year show where this is heading.
Is there a common misconception about external attack surface management that you’d like to correct?
The biggest one is that EASM is an asset inventory. Teams buy it and get a list of every domain, IP and certificate they own. They think the job is done. Then the list has ten thousand rows and nobody knows where to begin.
An inventory is the starting point, not the outcome. External risk is not a list of assets. It is the set of paths an attacker can actually walk. A forgotten staging server matters far more if someone’s credentials for it sit in a stealer log and a vendor that was just breached hosts it. Taken one by one, each is a medium finding. Together, they are an incident waiting to happen.
The second misconception follows from the first. It is the idea that your attack surface is only what you own. Your vendors’ exposures, your executives leaked credentials and the lookalike domains that impersonate you are all part of it. None of them appears in your asset register. Good EASM connects all of it and tells you which single fix breaks the path.
