What started as a weekend idea is becoming something much more valuable: a community effort to make AI applications easier to understand and safer to build.

Over the past few weeks, I’ve been building SafeAI, an open-source static AI Capability & Risk Analyzer.

The original idea was simple.

Traditional static analysis tools understand software. They can detect SQL injection, hardcoded secrets, dependency vulnerabilities and insecure coding patterns. But modern AI applications introduce entirely new concepts:

• Skills
• Prompt files
• Tool definitions
• MCP servers
• Workflow templates
• Model configurations
• Autonomous capabilities
• Agent orchestration

These artefacts deserve the same level of visibility and security analysis as traditional source code.

That’s why SafeAI exists.

Why Static Analysis for AI?

Most AI security discussions focus on runtime behaviour.

Prompt injection.

Jailbreaking.

Hallucinations.

These are important, but long before an AI agent executes, developers have already made dozens of security decisions in code and configuration.

Questions such as:

• Can this agent execute shell commands?
• Can it write to the filesystem?
• Does it have unrestricted network access?
• Can it invoke external tools?
• Does an MCP server expose mutation operations?
• Can a workflow trigger side effects without approval?

These are architectural questions that can often be answered without ever running the application.

That is exactly what SafeAI aims to do.

The Latest Milestone

The latest beta significantly expands the scope of analysis.

SafeAI now inspects much more than agent source code.

It analyses AI-specific project components including:

• Prompt and system instruction files
• Skills
• Tool definitions
• Workflow templates
• Model configurations
• MCP servers
• AI framework metadata

The project currently supports a growing list of frameworks, including early support for Claude Code, Google ADK, LangGraph, CrewAI, Haystack, LlamaIndex, Mastra, Dify, n8n and others.

Most importantly, SafeAI remains completely offline.

It never executes agents.

It never calls an LLM.

It never uploads your project.

Everything happens through static analysis on your own machine or in your CI/CD pipeline.

AI Helped Build an AI Security Tool

One unexpected part of this project has been the development process itself.

Instead of relying on a single coding assistant, I experimented with multiple AI coding models.

Using OpenCode as the development environment, I assigned different roles to different models.

• Kimi K3 became my primary implementation partner.
• OpenAI Codex was used heavily for reviews, validation and architecture discussions.
• Earlier iterations also benefited from DeepSeek V4, particularly for documentation and review.

Rather than replacing engineering judgement, the models complemented one another. Each had different strengths, and using them together proved more productive than relying on a single assistant.

It’s an approach I’ll continue refining as the project grows.

The Best Part Wasn’t the Code

Publishing an open-source project is always a little daunting.

You wonder whether anyone will look at it.

Whether the ideas make sense.

Whether you’ve overlooked something obvious.

Within days of publishing SafeAI, something encouraging happened.

The community started engaging.

We received:

• our first external code contribution
• thoughtful roadmap suggestions
• design discussions around capability governance
• ideas for AI-specific static analysis
• feedback that is already influencing future releases

One particularly insightful discussion proposed shifting focus from traditional risk scoring towards capability escalation across pull requests.

Instead of simply saying “the risk score increased,” imagine a pull request review that clearly explains:

• Shell execution was introduced.
• Filesystem write capability was added.
• An MCP server changed from read-only to mutation.
• A workflow no longer requires human approval.

Those are deterministic, reviewable changes that developers can immediately understand.

Feedback like this is helping shape SafeAI into something much more useful than I originally imagined.

Open Source Works Because of Community

The repository is still young.

GitHub stars and forks are encouraging, but they’re not the measure that matters most.

The real value comes from people who:

• challenge assumptions
• report false positives
• suggest better detection rules
• contribute support for new AI frameworks
• improve documentation
• share real-world AI projects for testing

Every discussion helps improve the project.

Every contribution makes the ecosystem a little stronger.

Where SafeAI Is Heading

There is still plenty to do.

Some of the areas I’m most excited about include:

• richer capability-diff analysis for pull requests
• deeper framework-specific parsers
• improved MCP security analysis
• more AI-specific detection rules
• stronger governance and policy capabilities
• broader framework support

The goal isn’t to declare an AI application safe or unsafe.

The goal is to help developers understand what their AI systems are capable of before they are deployed.

Join the Project

If you’re building AI applications, working on AI security, or simply interested in the future of AI engineering, I’d love your feedback.

Whether it’s opening an issue, suggesting a detection rule, sharing a test project or contributing code, every contribution helps.

GitHub Repository

Contributions, discussions and ideas are always welcome.

Because safer AI won’t be built by one person or one company—it will be built by a community.