Madhu Preetha Chandrasekaran has spent over a decade in security work that stretches from machine learning threat detection through application security and third-party vendor risk. She is a named inventor on three U.S. patents, two of which (11,038,905 and 11,870,795) cover behavioral detection of malicious PowerShell activity, and a third (12,086,264) covering software risk assessment. Her current work centers on getting security into the development lifecycle earlier, including where AI agents can carry part of that load.
That background puts her on both sides of the question the industry is currently arguing about. She has built detection systems that depend on modeling behavior, and she reviews code that a model helped produce. Her read on the second is less optimistic than the marketing around it, and more specific about where the cost lands.
She spoke with AI Journal in a personal capacity.
Much of the code arriving for security review now had an AI involved in writing it. How has that changed what lands on a security engineer’s desk day to day?
As more developers use AI-assisted coding (especially loosely defined/specified vibe coding), we’ve noticed greater ambiguity. When developers don’t explicitly lay out edge cases and requirements, AI fills in the gaps by hallucinating/guessing, and that can go in both directions – missing use cases that are needed and overcompensating and adding functionalities/cases that aren’t required. This increases review time and load, and if it is missed during review, they show up as an incident and ops load.
Security teams are beginning to hand routine reviews to AI agents. How do you decide an agent has earned the right to clear code without a human behind it?
I don’t think all reviews can be given to AI agents without any human involvement. However, given that the industry itself is moving fast, we need to balance risk and speed. A good starting point would be simple reviews that are low risk (for example: code with low blast radius). Once we’ve narrowed down to simple low-risk reviews, we need to make sure that the agent itself is doing a good job. We could do this by testing the agent with previously reviewed reviews (done by humans) and verifying that it is identifying issues that are expected. Then, it is important to stage it in batches – do a couple of reviews, both manually and using the agent, and then once we are confident, we can move to automate that type of review fully. One important thing to keep in mind here is that reviews and the industry keep growing and changing, so the agent needs to be updated with these changes. This could be done by doing sample testing of some reviews even after doing full automation.
Tell me about a moment an AI-assisted security tool failed in a way you didn’t see coming. Two of your patents cover behavioral detection of malicious PowerShell activity. What did building those detection systems teach you about the limits of anomaly detection?
Anomaly detection that uses user behavior as the baseline relies on building a baseline based on that user’s behavior; this baseline takes time to be built. One limitation with that is if malicious activity is done before that baseline is built, it might not accurately detect it. The patent actually covers it – the patent doesn’t only look at an individual user’s baseline, but it takes their peer clusters’ baseline into account. For example: If a developer suddenly tries to access another employee’s payroll, it would be tagged if it is not a part of his team’s job duty.
Catching a flaw while a developer is still typing costs a fraction of what it costs weeks later in a formal review. Can you put some shape on that curve from your own experience?
The cost of fixing a flaw later during a formal review is steep. For example: if an infrastructure/design issue is identified during the review rather than early in the process, it would cost multifold to fix since the developer has to go back and fix the design and the code. This would cause launch delays and additional work for the team. This has also been researched by multiple standards such as NIST and CISQ, and it is a common consensus that the cost of fixing a flaw later is exponentially higher. The recommendation is to identify issues earlier in the process, and AI could be used positively to do this.
Buyers face shelves of security products with AI on the label. What would you actually test before trusting one?
The recommendation is to ask for a PoC and test it on buyers’ data. In the test, the most important factors to look for are:
- Low false negatives: Does the tool catch what it claims to do?
- Low false positives: A high false positive rate would lead to engineers/team losing their trust in the tool, which would result in alarms getting dismissed. This means that an actual, critical alarm could get missed.
- The speed of the tool: This depends on the use case. It could be detection latency/how much load it puts on your systems
Other questions/information that should be clarified about data are:
- Will buyer data be used for training purposes? If yes, where is the data stored? What is the anonymization/scrubbing process like? This is to understand how buyer’s data is used and to make sure that leakage of training data wouldn’t lead to sensitive data disclosure.
- How do you train your models? What data is it trained on – synthetic data, public threat feeds?
Companies routinely spend weeks verifying that software they purchase meets their security requirements. How much of that verification can automation take on responsibly?
I think asking questions and receiving documents from the vendor, and receiving answers and documents, will still involve some back and forth and manual intervention. An option to reduce this load and wait times in back-and-forth communication would be to use third-party risk management tools. These tools might have data about vendors you are interested in.
Additionally, the parsing of these answers, documents, and any additional data (regardless of how the data was obtained) could be automated, especially with AI, and that would help reduce the overall timeline significantly. Humans can be involved again in ensuring the answers are right and that it meets their standards – this is important to make sure that the model is not misrepresenting an answer/requirement. The involvement of humans could be reduced iteratively for low-risk tools (tools that impose low risk to the buyer based on how it is used, what data it accesses, and the surface impact of an issue).
A five-person security team at a mid-sized company wants to know where AI would earn its keep first. What do you tell them?
For a five-person team, my suggestion is to use AI to reduce their alarm fatigue for incidents and vulnerabilities. AI could be used to look at alerts they receive, past tickets (to identify past false positives), and systems/dashboards necessary, then provide recommendations on prioritization and action items. Building on this iteratively would help the team focus on true positive issues and high priority items, and also focus on making their systems and processes better.
