OpenTaint connects AI agents with formal code analysis
August 14, 2026
OpenTaint tracks untrusted data through Java and Kotlin code and lets agents turn findings into reusable rules. The open tool is designed for local scans and CI.
What this is about
OpenTaint is an open-source static application-security tool. It tracks how potentially untrusted input flows through source code and whether it reaches dangerous operations without sufficient validation. The interesting part for AI teams is its division of labor: an agent can analyze a concrete finding and derive a rule, while later checks run deterministically without another model call.
Seqra created the repository on September 30, 2025, and it was actively maintained on August 14, 2026. OpenTaint can be launched through npm, Homebrew, an installation script, or Docker. This makes it a usable CLI for local machines and CI pipelines rather than a research prototype.
What OpenTaint actually does
Taint analysis marks sources such as HTTP parameters as potentially untrusted and follows their path to sinks such as database queries or operating-system commands. OpenTaint describes its engine as interprocedural, meaning it aims to track data across function boundaries, aliases, asynchronous calls, and persistence layers.
A scan can run locally with opentaint scan or inside a container. Results can be exported as SARIF, a format understood by many code and security platforms. GitHub Actions and GitLab CI integrations are included. The project also contains agent skills for attack-surface discovery, rule creation, finding analysis, and optional generation of dynamic proofs.
The documentation currently names Java, Kotlin, and Spring as the supported focus. Python, Go, C#, JavaScript, and TypeScript are on the roadmap, so they must not be treated as finished coverage.
Why it matters
Simple pattern matchers often identify suspicious syntax but may not understand a value's complete path through several functions. A language model can inspect more context, but repeatedly scanning a whole repository consumes time and model quota. OpenTaint separates those jobs: the agent helps derive or refine a rule, and a formal engine subsequently executes it as often as needed.
That separation can be useful for AppSec teams that want to check the same vulnerability class across many repositories or on every commit. According to the repository, the engine and major components use Apache 2.0 and MIT licenses and can be self-hosted. Source code therefore does not necessarily have to be sent to an external model provider. Teams using the agent skills still need to configure and review model access and permissions separately.
In plain language
Imagine colored water moving through a pipe system. The color starts at an inlet and shows which pipes it crosses and whether it eventually reaches a drinking-water tap. An AI agent helps draw new pipe maps; the actual test can then send the same colored water through the system again and again.
A practical example
A team operates a Spring service with 80,000 lines of code. An HTTP parameter is stored, loaded later, and eventually inserted into a query. A basic pattern check sees isolated files and reports nothing. The team runs OpenTaint in Docker, exports SARIF, and reviews the data path.
An agent examines the confirmed finding and creates a project-specific rule for the library in use. That rule then runs deterministically on every pull request. This example is fictional; it illustrates the intended workflow, not a guaranteed detection rate. A sensible first test is therefore a small, intentionally vulnerable repository whose expected data paths are already known to the team.
Scope and limits
First, documented language coverage currently focuses on Java, Kotlin, and especially Spring. Teams centered on Python, Go, or TypeScript should not confuse roadmap entries with production support.
Second, a static finding does not prove exploitability. Custom rules and library models can create false positives or miss real paths, so people must verify important results.
Third, adding an agent does not make analysis automatically safe. Agents need minimal privileges, an isolated runtime, and explicit boundaries for dynamic proofs. OpenTaint does not replace code review, runtime testing, dependency analysis, or professional penetration testing.
SEO & GEO keywords
OpenTaint, Seqra, taint analysis, static code analysis, SAST, AppSec, Java security, Kotlin security, Spring Security, SARIF, CI/CD security, AI agents
💡 In plain English
OpenTaint checks whether untrusted input travels through Java or Kotlin code into dangerous functions. AI agents can prepare new rules, while repeated scans then run locally and deterministically.
Key Takeaways
- →OpenTaint combines formal dataflow analysis with optional agent skills.
- →Scans run locally, in Docker, or in CI and can export SARIF.
- →Documented support currently focuses on Java, Kotlin, and Spring.
- →The engine and major components use Apache 2.0 and MIT licenses.
- →Findings require verification; the tool does not replace a complete security assessment.
FAQ
Which languages is OpenTaint designed for?
Current documentation names Java, Kotlin, and especially Spring. Other languages are on the roadmap and should not yet be treated as fully supported.
Does every scan require a language model?
No. The core is a deterministic analysis engine. An agent can help with rules and triage, but repeated rule runs do not require another model call under the project's approach.
Can OpenTaint be self-hosted?
Yes. The project offers local installation, npm, Homebrew, and Docker. Model providers, permissions, and data paths still need separate review when agents are added.
Does it replace a penetration test?
No. Static analysis covers only part of the attack surface and can produce both false positives and blind spots.