Your AI writes code faster than you can review it. Ours does too. This is what we built to survive that.
AYA Code-Guard is the static-analysis fleet we run against our own 17,000-module, largely AI-written codebase at every single commit, packaged as an audit for yours. It does not just hunt CWE signatures. It checks the failure modes that actually kill agentic systems: the exception that gets swallowed silently, the security check that fails open, the shared cache mutated without a lock, the module that was generated, committed, and never called by anything.
Book an AI-codebase audit See a sample findings report
THE PROBLEM
Coding agents changed the economics of writing code and broke the economics of reviewing it. A team that merges ten times more generated code does not get ten times more reviewer attention, so review becomes sampling, and sampling misses exactly the defects generated code is best at producing: code that compiles clean, reads plausibly, and is architecturally wrong. An except-pass that eats the error so the demo works. An auth check that returns True when the verifier throws. A subsystem that looks essential and has zero callers. Commodity SAST was built for a different war, injection sinks and taint tracking in human-written code, and it happily green-lights all of the above. Meanwhile the EU AI Act's high-risk obligations bind on August 2, 2026, and resilience and cybersecurity of the systems you ship becomes a question with a paper trail, not a vibe.
HOW IT WORKS
We point the fleet at your repository and run the same gates AYA cannot commit without passing. The rules come from doctrine, not signature databases: no direct calls that bypass your message or service boundaries, no silent exception swallowing, security paths must fail closed (an exception in an auth check must deny, never allow), mutable shared state must be lock-guarded, module-level import hygiene, no PII or hardcoded secrets in source, no dangerous primitives like eval or pickle on untrusted data, and a check for the Protocol-stub inheritance trap that type checkers do not catch. On top of the rule pass runs the liveness scan: which symbols in this repository have zero callers, meaning code that was built and never wired. Because a wrong "this is dead" verdict is how panic deletion campaigns start, our scanner is calibrated against an independent multi-signal ground-truth oracle and the agreement is pinned by a regression test; we learned that lesson on ourselves, three false alarms deep. You get a findings report ranked by blast radius, with every claim pointing at a file and line, and an honest unknown where static analysis cannot see (dynamic dispatch, reflection), never a guess dressed as a verdict.
WHAT YOU GET
- the doctrine findings, every architectural violation with file, line, rule, and why the rule exists (each one bought with a real production failure at scale), - the fail-open inventory, every security path that allows on error instead of denying, - the silent-failure inventory, every swallowed exception between your users and your logs, - the liveness verdict, which subsystems have zero callers, cross-checked against a ground-truth oracle before we call anything dead, - the ranked remediation order, keystone fixes first, not an undifferentiated wall of 4,000 warnings.
WHO IT'S FOR
Engineering teams whose codebase is increasingly written by AI: agent startups, AI-native SaaS, and any shop that adopted coding agents at scale and is starting to feel the review gap. Platform and security engineering groups who owe an internal secure-coding standard and would rather enforce it as pre-commit gates than as a PDF. Consultancies doing AI-code cleanup who need a repeatable scanner instead of heroics. If all you need is dependency CVE scanning or license compliance, that is commodity SCA and not this product.
PRICING (the ladder)
We price the ladder, not a single number, and every number is a hypothesis we validate with you, not a commitment. - Audit pilot, a fixed-price engagement: we run the fleet against one repository, engineer-driven, and hand back the full findings report with a ranked remediation order. - CI subscription, per repository per month, the fleet wired into your merge gates so the doctrine is enforced continuously, once the CI packaging ships. - Platform, license the rule packs and fleet into your own developer platform or consulting practice.
IP is licensed, never assigned. Any step that takes your money is gated and confirmed by a human before it runs, nothing charges silently.
THE PROOF (dogfood)
This is the rare product where the dogfood claim is total. AYA's own repository, roughly 17,000 Python modules, most of them written by AI agents, cannot accept a commit that fails these gates: the fleet runs as pre-commit hooks on every change and as a fail-closed verification fleet on every deploy. The rules were not designed on a whiteboard; each one exists because the failure it catches actually happened to us at scale and had to be machine-caught, including the audit that found over a million lines of plausible-but-wrong generated code and the silent failure that disabled 212 adapters while every log line looked routine. The liveness scanner earned its calibration the hard way too: it falsely cried "80% dead" three times before we built the ground-truth oracle it now has to agree with, an agreement pinned by a regression test in our own suite.
HONEST NOTE
We would rather under-promise. What exists and runs today: the linter fleet (113 Python modules under scripts/linters/), the pre-commit and deploy gates, the liveness scanner and its oracle, and the committed security assessment pattern that carries the SAST pass, all executing daily against AYA itself. What does NOT exist yet: any productized packaging. There is no CI app, no hosted scanner service, no report API, no dashboard, and no tenant isolation, and the fleet has never scanned a repository that is not AYA, so rule-pack portability outside our own architecture doctrine is honestly untested. The audit pilot is real precisely because it does not need that packaging, an engineer drives the fleet against your repo by hand. That first external run is the next test this product has to pass, and we will say so until it has.
Book an AI-codebase audit
*This page is a specification. The capability it describes is not built yet, and nothing here is a claim that it runs today.*