What is Inference Security?
Inference Security is the company and thesis behind this work: security tooling should move from matching known patterns to reasoning over code, context, and compound risk.
Short answers for security engineers, founders, and technical teams trying to understand what Inference Security is, what Inference Recon does, and where this approach fits.
Inference Security is the company and thesis behind this work: security tooling should move from matching known patterns to reasoning over code, context, and compound risk.
Inference Recon is the first implementation: an open-source prompt and workflow you run inside Claude Code or Codex against a local repository. It guides the agent through security analysis focused on relationships, trust boundaries, and compound impact.
No. A scanner checks for known patterns. Recon guides an AI agent through a reasoning workflow: control flow, data flow, trust boundaries, configuration, and the way separate issues compound into real risk.
It is closer to structured review than automated scanning.
SAST is valuable, but it is usually rule-driven. It flags known-bad patterns, risky APIs, and classes of issues that can be encoded ahead of time.
Inference Recon starts from a different premise: the most important finding may be specific to your codebase and may only exist in the relationship between several ordinary-looking decisions. It is context-seeking rather than signature-seeking.
It means following how the system fits together instead of checking files in isolation. A reasoning workflow asks: where does this input come from, what code trusts it, what permissions does it inherit, what happens on failure, and what becomes possible when those facts are combined?
No. It is a way to scale the first pass and surface better questions, especially when the codebase is moving faster than manual review can keep up.
It is best suited for issues where risk depends on context: authorization bypasses, multi-tenant boundary failures, privileged clients, fail-open behavior, insecure data flows, and multi-step vulnerability chains.
It is an early release, not a guarantee of security. It can miss issues, misunderstand code, or overstate risk. Results depend on the model, the agent, the available context, and the structure of the repository.
Its output should be reviewed the same way you would review analysis from a human teammate: seriously, but not blindly.
Inference Security does not receive your repository when you use Recon. Recon is not a hosted scanner that uploads your code to us.
It runs wherever you run the AI coding agent. If you use Claude Code, Codex, or another hosted model, your code is handled according to that provider's policies and your configuration.
The first release is designed for Claude Code and Codex-style workflows. Other agents may work if they can inspect a local repository, follow long-form instructions, and reason across files.
Yes. Inference Recon is open source so people can inspect the workflow, improve it, adapt it, and see exactly what the first implementation is doing.
Security engineers, founders, and software teams shipping code faster than traditional review can keep up. It is especially useful for small teams reviewing AI-written or AI-modified production code.
Yes — and that's the design. A prompt is an executable workflow: it encodes expert judgment about what to inspect, in what order, and how to reason about compound impact.
The format is intentionally simple so you can read it, adapt it, and trust what it's doing. What makes Recon useful is the methodology. The wrapper is beside the point.
Treat it as security analysis, not a verdict. Review the cited files, validate the chain, reproduce impact where possible, and use it to prioritize deeper review.
AI is changing both sides of software security. It increases the amount of code being written and changed, and it also makes context-aware review more practical.
The old tooling model is under more pressure at the same time a new reasoning layer is becoming usable.