Secure by default for vibe coding.

AI-assisted development is no longer a side experiment. Teams describe an API, an auth flow, or an agent, and a model writes the first draft. That speed is real. So is the risk: security decisions now happen in the prompt and the patch, not only in a later review.

grok-asvs is a Grok Build plugin I open-sourced to push OWASP-aligned secure defaults into that generation loop, for humans vibe-coding with AI and for agents that write and review their own code.

The common pain point

Most application security programs still meet ASVS-style expectations after the fact. Features ship, reviews pile up, scanners fire, and teams retrofit controls that should have been defaults on day one. That was already expensive when only humans wrote code. It is worse when models generate large diffs at machine speed.

The pain is not a lack of standards. It is when the standards enter the workflow:

• Security is treated as a gate after implementation, not a constraint during design and coding
• AI-generated code inherits insecure defaults unless the agent is steered otherwise
• Reviewers inherit huge, AI-shaped patches without a shared checklist that matches how the code was produced
• Bolt-on fixes miss authorization, injection, and secret-handling bugs that were baked in at creation time

Baking ASVS and AISVS thinking into creation (by people or machines) is cheaper than re-architecting after the fact. That is the pain point grok-asvs targets.

The problem it targets

When models scaffold features, insecure patterns show up as often as clever ones:

• String-built SQL or shell
• Missing object-level authorization (IDOR / BOLA)
• Secrets in source, logs, or prompts
• Over-broad agent tools and MCP surfaces
• Prompt injection via PR text, retrieved docs, or tool output

OWASP ASVS and AISVS already describe what “good” looks like for applications and AI systems. What was missing was packaging that agents can apply while coding, not only a standard to re-read after the fact.

Why OWASP?

OWASP (the Open Worldwide Application Security Project) is a community-driven effort to make application security knowledge public, practical, and shared. Volunteers publish free standards, guides, and tools so builders and defenders can talk about the same controls without reinventing vocabulary for every product.

Two of those projects matter especially for product design:

• ASVS (Application Security Verification Standard) spells out what “good” looks like for apps and APIs: authentication, authorization, injection resistance, crypto, sessions, logging, and more, at progressive verification levels.
• AISVS (Artificial Intelligence Security Verification Standard) does the same for AI systems: prompts, agents, RAG, MCP, model supply chain, and AI-assisted coding itself.

The intent is not paperwork. It is a common security language for design and verification, so teams stop debating basics and start implementing them. grok-asvs does not replace reading the standards; it turns agent-facing “paved roads” from ASVS and AISVS into defaults during code creation, when change is still cheap.

Why Grok?

I built this for Grok Build because the tooling and the model stack are both serious options for agentic software work, not niche experiments.

xAI has open-sourced Grok Build as a coding agent environment you can run and extend with plugins, skills, and commands. That openness matters for security work: you can inspect how guidance is packaged, pin installs by commit, and keep policy local without bolting on opaque MCP servers.

On capability, Grok-class models compete in the same agentic tier as the other frontier systems. Independent agent benchmarks such as the Arena.ai Agent leaderboard rank models on real tool-using work (task completion, steerability, recovery, and related signals). Grok variants sit among competitive agent models there; rankings move, but the point is durable: you are not choosing “a weak model with a clever plugin.” You are steering a strong agent stack.

Cost is part of the product decision too. For many teams, Grok is often more cost-effective for high-volume coding and agent sessions than the priciest frontier alternatives, while still holding up on agentic tasks. Secure-by-default guidance is wasted if nobody can afford to run the agent. Pairing ASVS/AISVS paved roads with a strong, economical coding agent is intentional.

What grok-asvs is

A local instruction plugin for Grok Build:

It changes how the coding agent thinks and what it writes. It does not invent an air gap around your model provider; that remains an operator responsibility (data retention, MCP inventory, remotes, secrets in prompts).

Two knobs operators actually use

1. Security level (1 / 2 / 3)

Same idea as ASVS/AISVS verification levels:

• 1: baseline (plugin default)
• 2: production, PII, multi-tenant
• 3: high assurance

Set with /security-level 2 for a project, or with --global for a user default. Implementation guidance and reviews scale with the level.

2. Reference source (local | upstream)

• local (default): use only plugin-shipped paved roads. No standards network fetch. Offline-friendly.
• upstream: fetch commit-pinned OWASP ASVS/AISVS chapter files and SHA-256-verify them against pins shipped in the plugin before use. Floating master/main raw URLs are forbidden. On mismatch, discard remote text and keep local guidance.

Upstream checksums are agent-enforced, not OS-enforced. If you need offline certainty, stay on local.

Trust model in one screen

• Skills-only least privilege for a security-themed plugin
• Opt-in egress only for pinned OWASP raw content
• Install by full git commit SHA, with integrity documented in the manifest
• Explicit non-certification: this does not make you “ASVS certified”

Quick start

# Prefer a SHA pin over floating main
grok plugin install isbitski-klm/grok-asvs@02af47719e26e3f22a5d40b84f4d08dd71ba6d55 --trust
grok plugin enable grok-asvs
grok plugin details grok-asvs

In a Grok Build session:

/security-level 2
/reference-source
# …build features…
/asvs-review
/aisvs-check

Full install verification, pin notes, and trust details live in the repository. Current release: v0.3.1. Pin the integrity.git_commit value, not necessarily the tip of main.

github.com/isbitski-klm/grok-asvs

What it is not

• Not a substitute for threat modeling, pen tests, or formal compliance
• Not official OWASP guidance (paved roads are agent-facing distillations; upstream standards remain authoritative)
• Not a guarantee about where your code is stored or processed by the host AI product

Why ship it this way

Security plugins that pull in MCP servers or shell hooks expand attack surface. grok-asvs is deliberately instruction content: useful in the generation loop, boring from a supply-chain perspective, and honest about residual risk, including that upstream checksums depend on the agent following the procedure.

If you build with Grok Build, or you review AI-generated code, feedback, issues, and patches are welcome on the repo.

Acknowledgments: credit for ASVS and AISVS belongs to OWASP and the project contributors. This plugin is informed by those standards and is not affiliated with or endorsed by OWASP or xAI. Grok Build is a product of xAI; this is a third-party community plugin. Agent rankings cited from Arena.ai are independent and change over time; check the live leaderboard for current positions.