A practical approach
There is a shift happening in how the industry talks about agentic AI security. A year ago the conversation was speculative – what might go wrong, what we might do about it. Now it is specific. The platforms, primitives and patterns for operating agents safely exist as named things you can point at on a slide. The vocabulary is converging across vendors. The reference architectures are documented.
In this blog I explore the themes that mattered most, and what they mean for security teams.
As organisations accelerate AI adoption, a familiar pattern is emerging: security teams – often the CISO – are increasingly asked to own or coordinate AI governance. That outcome is not an accident. Security leaders already operate across departmental boundaries, manage data inventories, run cross-functional programs and are trusted by executives and boards to solve hard, systemic problems. AI initiatives are inherently cross-disciplinary, data-centric and integrated into product and vendor ecosystems, so responsibility naturally flows toward teams that already do that work. This operational reality creates an opportunity: security can (and should) move from firefighting to shaping safe adoption practices that preserve value and reduce harm.
In this blog I outline key strategies on how to be successfully in leading AI governance initiatives in your organisation.
We are entering the agentic era – an inflection point defined by AI systems that can reason, plan and take action autonomously. This shift may be among the most consequential technological transformations of our generation, and it carries an equally significant obligation: to ensure these systems are designed, governed and deployed in ways that earn and sustain trust.
I completed a 5-Day AI Agents Intensive Course where we dove deep in Google’s open source Agent Development Toolkit. In this blog, I’ll share key takeaways and practical suggestions so you can navigate this shift and learn to build AI agents of your own.
A big moment at the 10x Demo Day with Edmond Sorich and Eléonore Cluzel.
Health 10x, in collaboration with The George Institute for Global Health, is a unique national program accelerating the business growth of startups building affordable and scalable solutions for major health challenges.
It was a privilege to support GLIA Diagnostics developing the first portable, accurate brain injury diagnostic device over the past twelve weeks as an advisor and mentor.
Cyber security strategy and execution is one of the top priorities for a CISO. It helps articulate the value of security, provide clarity on short and long term goals and outline a cyber security uplift roadmap.
In this blog I recommend a proven step-by-step guide for developing a cyber strategy.
Scaled Agile Framework (SAFe) provides a way for the entire organisation to work in an agile way, not only software engineers. Security professionals, lawyers, compliance specialists and procurement teams are encouraged to engage in sprints (or ‘iterations’) too. You don’t have to write code to participate in a retrospective.
I recently had an opportunity to apply some of the Agile practices in my latest cyber security projects while going through formal Leading SAFe training at work.
Many ideas are not new, especially if you worked with Scrum previously, but they don’t have to be in order to be effective. The framework serves more as a collection of principles and a menu of techniques that can be used to transform large organisations that have ‘always done things that way’.
Product security is more than running code scanning tools and facilitating pentests. Yet that’s what many security teams focus on. Secure coding is not a standalone discipline, it’s about developing systems that are safe. It starts with organisational culture, embedding the right behaviours and building on existing code quality practices.
Knowing your existing assets, threats and countermeasures is a necessary step in establishing a starting point to begin prioritising cyber risk management activities. Indeed, when driving the improvement of the security posture in an organisation, security leaders often begin with getting a view of the effectiveness of security controls.
A common approach is to perform a security assessment that involves interviewing stakeholders and reviewing policies in line with a security framework (e.g. NIST CSF).
A report is then produced presenting the current state and highlighting the gaps. It can then be used to gain wider leadership support for a remediation programme, justifying the investment for security uplift initiatives. I wrote a number of these reports myself while working as a consultant and also internally in the first few weeks of being a CISO.
These reports have a lot of merits but they also have limitations. They are, by definition, point-in-time: the document is out of date the day after it’s produced, or even sooner. The threat landscape has already shifted, state of assets and controls changed and business context and priorities are no longer the same.
In the DevSecOps paradigm, the need for manual testing and review is minimised in favour of speed and agility. Security input should be provided as early as possible, and at every stage of the process. Automation, therefore, becomes key. Responsibility for quality and security as well as decision-making power should also shift to the local teams delivering working software. Appropriate security training must be provided to these teams to reduce the reliance on dedicated security resources.
I created a diagram illustrating a simplified software development lifecycle to show where security-enhancing practices, input and tests are useful. The process should be understood as a continuous cycle but is represented in a straight line for the ease of reading.
There will, of course, be variations in this process – the one used in your organisation might be different. The principles presented here, however, can be applied to any development lifecycle, your specific pipeline and tooling.
I deliberately kept this representation tool and vendor agnostic. For some example tools and techniques at every stage, feel free to check out the DevSecOps tag on this site.
There is a strong correlation between code quality and security: more bugs lead to more security vulnerabilities. Simple coding mistakes can cause serious security problems, like in the case of Apple’s ‘goto fail’ and OpenSSL’s ‘Heartbleed‘, highlighting the need for disciplined engineering and testing culture.
I touched upon embedding security in modern software development practices in my previous blogs on agile security and DevSecOps culture and recommended some tools to help automate managing vulnerabilities in open source libraries, help preventing committing secrets in code and integrating application security testing in the CI/CD pipeline. In this blog I would like to touch upon the connection between code quality and security and explore static code analysis.
An open source tool that is gaining a lot of momentum in this space is Semgrep. It supports multiple languages and integrates well in the CI/CD pipeline. You can run Semgrep out of a Docker container and the test results are conveniently displayed in the command line interface.
The rule set is still relatively limited compared to other established players and it might find fewer issues. You can write your own rules, however, and things are bound to improve as the tool continues to develop with contributions from the community.
A more well-known tool in this space is SonarQube. You can still use a free Community Edition for basic testing but advanced enterprise-level features would require a paid subscription. CI/CD integration is possible, inter plugins (like the one for ESLint) are also available.
SonarQube has a dashboard view which scores your code across reliability, security, maintainability and other metrics.
As with any tool of this type, to get the best use out of it, some initial configuration is required to reduce the number of false positives, so don’t be discouraged by the high number of bugs or “code smells” being discovered initially.
Keeping in mind the fact that no amount of automation can guarantee finding all the vulnerabilities, I found SonarQube’s analysis around Security Hotspots particularly interesting. It also estimates a time required to pay down the tech debt which can serve as a good indicator of maintainability of your codebase.
It is important to remember that static code analysis tools are not a substitute for the testing culture, code reviews, threat modelling and secure software engineering. They can, however, be a useful set of guardrails for engineers and act as an additional layer in your defence in depth strategy. Although these tools are unlikely to catch all the issues, they can certainly help raise awareness among software developers about quality and security improvements, alert about potential vulnerabilities before they become a problem and prevent the accumulation of tech and security debt in your company.
