Pre-Write Scanning vs SAST: Why Static Analysis Misses What AI Agents Actually Do

Pre-write scanning checks AI-generated code before an agent writes or modifies project files. Action-time permission checks evaluate commands and tool calls before execution. SAST, or Static Application Security Testing, analyzes static source code or related artifacts without running the program. Teams using coding agents need both because code analysis and agent-action control protect different parts of the workflow.

What SAST does well

SAST examines code without executing it. Mature tools parse source, bytecode, configuration, or infrastructure definitions and look for known vulnerability patterns such as injection, unsafe data flow, weak cryptography, insecure deserialization, and broken access-control patterns. Findings can be mapped to CWE and other established taxonomies.

SAST is not inherently a late CI-only control. It can run in an editor, after a file is saved, in a pre-commit hook, on a pull request, or across the full repository. Its defining characteristic is the artifact it analyzes, not the exact pipeline stage where it runs.

• Find known vulnerability classes in source and related static artifacts.
• Trace data flow from untrusted sources to dangerous sinks when the language and framework are supported.
• Apply repeatable rules across a repository or pull request.
• Produce findings that developers and security teams can triage, suppress, and track over time.
• Act as a reliable merge or release gate for the code that actually exists.

AI-generated code does not make SAST obsolete or less useful at this job. If a coding agent creates vulnerable SQL construction, unsafe HTML rendering, or a hardcoded credential, a suitable static rule may still find it after that artifact exists.

What static analysis does not observe by itself

A static scanner can analyze files and other supplied artifacts. It does not, by itself, reconstruct every event in the agent session that produced them. If a risky action creates no static artifact—or happens before the repository scan—the action needs a different control and evidence path.

Destructive commands that never become code

An agent can delete files, force-push a branch, publish a package, or execute a database migration directly from the terminal. The command may change real state without appearing in the final diff. A later repository scan has no command artifact to inspect unless another system captured it.

Permission changes across a session

Moving from reading one file to installing a package, opening network access, changing a schema, and deploying to production is a sequence of capabilities and decisions. Static analysis may inspect resulting configuration changes, but it does not inherently decide whether the next requested action is authorized for this agent, target, and environment.

Prompt injection upstream of the resulting file

A poisoned README, issue, webpage, retrieved document, or tool result can influence an agent before code is written. SAST may catch a vulnerable pattern in the output, but clean-looking output does not reveal that untrusted content changed the agent’s goal. How to detect prompt injection in AI-generated code explains the complete source-to-action review.

MCP and external tool calls

An MCP call can read a credential, send data to an API, alter an external system, or chain capabilities across services without producing application source code. Those calls require scoped authorization, validation, approval, and logs around the action itself. MCP security risks for Claude Code users provides a focused connector review.

Pre-write scanning vs SAST

The core distinction is artifact analysis vs action control

Calling SAST reactive and pre-write scanning preventive is too simplistic. SAST can prevent a vulnerable change from merging, and a poorly integrated action check can still happen too late. The durable distinction is what evidence each control receives and where it can enforce a decision.

A static scanner asks whether an artifact contains a risky pattern. An action-time control asks whether this agent should perform this operation on this target in this environment, with this expected impact and rollback posture. The answers complement each other.

Use both layers instead of choosing one

A mature AI coding workflow keeps SAST where it is strong and adds controls around generation and execution. Removing the final repository scan would lose broad, repeatable coverage. Waiting until the repository scan would leave state-changing agent actions outside the enforcement path.

• Before generation: define the task, trust boundaries, protected files, allowed tools, and security requirements.
• Before a code write: scan proposed code for secrets, injection, broken authentication, unsafe configuration, dependency risk, and other supported patterns.
• Before a sensitive action: evaluate the agent identity, tool, action, target, environment, volume, rollback, and matching policy.
• After files exist: run SAST, dependency, secret, and infrastructure checks across the resulting repository state.
• Before merge or deployment: review the diff, tests, findings, approvals, and recorded action evidence together.

A practical example

An agent is asked to set up a database connection. It proposes a configuration containing a production connection string, installs a telemetry-enabled package, and requests permission to run a migration against the database referenced by the current environment.

• A pre-write code check can flag the proposed hardcoded connection string before it lands in the project.
• A dependency review can verify the package, publisher, version, install behavior, and whether the dependency is needed.
• An action permission check can identify the production target, migration action, affected scope, and rollback context before execution.
• A policy can block the migration or pause it for human approval.
• SAST remains valuable after the files exist because it reviews the final repository state and may find additional code-level vulnerabilities.

How VibeLint fits into the workflow

VibeLint separates code scanning from runtime action governance. In supported IDE and MCP workflows, the coding agent can call the local security scanner before writing or modifying code. In agent and automation workflows, the runtime can send a structured permission check before a sensitive tool call.

VibeLint scores structured agent actions from 0 to 100 using context such as tool, action, environment, affected volume, rollback availability, and prior decisions. Policies can return allow, block, or require approval. Action logs preserve the agent, tool, status, risk, decision, approval state, and redacted context.

For the broader workflow, read Vibe Coding Security: The Complete Guide to Securing AI-Generated Code. For the identity, permission, approval, logging, and incident-response controls around the agent, use AI agent security checklist for developers.