Static Scanning Without a Model Key

Quick answer: Static scanning does not require a model key. The deterministic route extraction and the completeness gate run locally through framework tracing and AST analysis, and source code is not sent anywhere by default. AI gap fills are a separate, optional step rather than a requirement for the scan, and there is no provider key or custom endpoint to configure.

Why the scan works without a model

The part of the scan that proves routes is deterministic, not generative. It follows the framework instance and reads the AST, then classifies contracts through the gate. None of those steps call a model, so they need no key and no network connection to a provider.

That keeps the core extraction local and repeatable. The document is built from code the machine reads, not from a hosted response.

Running without a key also means the scan works in places a hosted model cannot reach. A laptop on a restricted network, a CI step that only reads the repository, or a codebase that cannot leave the machine can all still produce a document, because the analysis never needs to phone out. There is no account to provision before the first run, and no quota that runs out halfway through a large project. The speed is consistent too, since the time depends on the size of the code rather than the latency of a remote service.

What runs without a key

The gap fill is the only step that uses AI, and it is not required to produce the baseline document. You can scan, review, and adopt a spec without ever invoking the model.

Privacy and source handling

Because static scanning stays local, source code is not sent anywhere by default. Local scans exclude common dependency, build, and credential paths, although they cannot guarantee the source contains no secrets, so you should still review what you share when you do request an AI fill.

There is no bring-your-own-key flow and no custom endpoint. The built-in model handles the optional AI work, and upstream providers are managed server-side rather than configured by the client.

How the two steps fit together

The split keeps the deterministic groundwork independent from the optional AI layer.

1. Run the scan locally with no key and get the proven routes.
2. Review the gate status and the named gaps.
3. Only if you want, request an AI fill for specific gaps.
4. Keep the extracted structure as the baseline and treat fills as hypotheses until reviewed.

A model-only note never reclassifies the deterministic structure, and the scan does not run the app. A successful scan still does not prove conformance, but it does not depend on a model to establish the routes.

Keep the two outputs in order when you read the result. The baseline document is deterministic evidence that can be trusted within its gate labels, while any AI fill is a separate layer that stays a hypothesis until you check it against the source. That ordering does not change when you skip the model entirely, which is the default for a first scan.

Powerduck keeps the offline scan and the optional AI work separate, so no provider setup blocks the baseline extraction.

Frequently asked questions

Do I need a key or an account to scan? No. Deterministic extraction and the gate run locally without a model key, and source code is not sent anywhere by default.

When does AI enter the process? Only when you request a gap fill. It is optional, uses the built-in model, and does not invent routes.

Can I configure my own provider key? No. There is no bring-your-own-key or custom endpoint; the built-in model is used for the optional AI work.

The bottom line

Static scanning is a local, deterministic process that needs no model key, proving routes through framework tracing and AST analysis while keeping source code in place by default. The AI gap fill is an optional, separate layer rather than a gate to get started. This keeps the baseline extraction fast, private, and free of provider setup, while a successful scan still does not prove runtime conformance. You can build the document without ever calling a model. Read more in the code-to-OpenAPI guide.