{"slug": "your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill", "title": "Your AI Writes the Code. Who’s Checking It for Security? Meet ai-Security-Skill", "summary": "A new open-source tool called ai-security-skill provides a local-first security control plane for AI-assisted development, using deterministic code analysis to verify code generated by AI agents. The tool, created by a developer, combines OWASP ASVS V5, OWASP API Security Top 10, OWASP Top 10 for GenAI and LLMs, NIST SSDF, and CIS Controls with TypeScript AST parsing and taint-flow analysis to block builds or commits when critical issues are found.", "body_md": "We are living in the golden era of agentic software engineering.\n\nDevelopers are no longer writing code line by line. We are increasingly orchestrating AI agents using tools like Cursor, Windsurf, Antigravity and Claude Code. These agents can build features, debug errors, refactor repositories, and sometimes complete in minutes what would have taken hours.\n\nBut there is a hidden cost to that speed:\n\n**Vulnerabilities are being introduced at the same speed.**\n\nAsk an AI coding assistant to implement a payment gateway and it might produce the entire integration in seconds. But it could also make a dangerous assumption, such as trusting a price supplied by the client.\n\nNow comes the more interesting problem.\n\nWhat happens if you ask the same AI agent to check whether the code it just wrote is secure?\n\nYou get what I call the **“marking your own homework” problem.**\n\nAn AI agent can hallucinate, make incorrect assumptions, or convince itself that its implementation is safe. There is no independent verification boundary forcing the generated code to prove that it is secure.\n\nThat is the problem I wanted to solve.\n\n**Meet ai-security-skill.**\n\nAs I started using ai coding agents more and more from past 6–7 months the thought of the security always comes to my mind, the Ai agent wrote the application whole code in line minutes now I need to go through important files and check for the security risks that’s when I think of ai-security-skill, it is a local-first security control plane designed to sit directly inside the AI-assisted development loop.\n\nInstead of asking an LLM to decide whether its own code is secure, the idea is to give it an independent verification layer based on deterministic code analysis.\n\nThe Paradigm Shift: Security Needs to Move Closer to Code Generation\n\nTraditional Static Application Security Testing (SAST) tools are extremely useful, but they were designed around a different development workflow.\n\nA typical security workflow might look like this:\n\nThat workflow becomes less effective when an AI agent can generate hundreds of lines of code in seconds.\n\nBy the time a vulnerability reaches CI, the agent may have already generated several more files that depend on the vulnerable implementation.\n\nThere is also the problem of noise.\n\nDevelopers can end up with hundreds of security findings and false positives. Eventually, security warnings become something people learn to ignore.\n\nAI-assisted development needs a different approach.\n\nSecurity controls should be **context-aware**.\n\nA project using Stripe should have payment-related security checks. A project using PostgreSQL should have database-related controls. A project integrating OpenAI or LangChain should have controls specifically related to AI and agent security.\n\nThey should also be **local-first**.\n\nDevelopers should be able to analyze their code without uploading the entire repository to a third-party security platform.\n\nAnd most importantly, the security decision should be **deterministic**.\n\nAn LLM can help explain a vulnerability or suggest a fix, but the final security gate should be based on evidence from the code itself.\n\nThis is the architecture behind ai-security-skill.\n\nThe system combines two major layers:\n\n**Knowledge Layer:** OWASP ASVS V5, OWASP API Security Top 10, OWASP Top 10 for GenAI and LLMs, NIST SSDF, and CIS Controls.\n\n**Verification Layer:** TypeScript AST parsing, static analysis, and taint-flow analysis.\n\nThe result is a security pipeline that looks at the project context, determines which controls apply, verifies the actual code, and then makes a policy decision.\n\nIf everything passes, development continues.\n\nIf a critical issue is detected, the policy gate can block the build or commit until the issue is fixed or explicitly approved.\n\nHow ai-security-skill Understands Your Project\n\nThe first step is context discovery.\n\nInstead of blindly running every security rule against every project, ai-security-skill profiles the workspace using discoverProject.\n\nIt looks at things such as package.json, dependencies, and imports to understand what the application is actually using.\n\nFor example, it can identify:\n\n**Application stack:** Next.js, Express, Fastify, Svelte, and other frameworks.\n\n**Database stack:** PostgreSQL, MongoDB, Prisma, Drizzle, and related technologies.\n\n**Authentication:** Clerk, NextAuth, OAuth providers, and session-based authentication.\n\n**Sensitive capabilities:** Stripe, PayPal, OpenAI, LangChain, and other integrations.\n\nOnce the context is established, the system maps the detected stack against its security standards database.\n\nInstead of checking hundreds of irrelevant controls, it can focus on the controls that actually apply.\n\nFor example, detecting Stripe can activate payment amount integrity controls such as CTRL-BL-001.\n\nDetecting OpenAI or LangChain can activate AI agent tool validation controls such as CTRL-AI-002.\n\nThis makes the security analysis more useful because the scanner understands what it is looking at before deciding what to check.\n\nUnder the Hood: Deterministic Static Analysis\n\nAt the core of the system is a verification engine built around the TypeScript Compiler API.\n\nThe code is parsed into Abstract Syntax Trees (ASTs), allowing the engine to inspect the actual structure of the application rather than relying only on text matching or an LLM’s interpretation.\n\nOne of the key capabilities is the **Taint Flow Analyzer**.\n\nConsider a common e-commerce vulnerability.\n\nA frontend sends a payment amount to the backend:\n\n```\nconst { amount } = req.body;\njs\nconst payment = await stripe.paymentIntents.create({  amount,  currency: 'usd'});\n```\n\nAt first glance, the code looks perfectly reasonable.\n\nBut the amount came directly from the client.\n\nThat means an attacker could potentially manipulate the request and submit a different amount.\n\nThe important question for a security scanner isn’t simply:\n\n*“Does this code look suspicious?”*\n\nIt is:\n\n**“Where did this value come from, and where did it end up?”**\n\nThe TaintAnalyzer tracks exactly that.\n\nIt identifies untrusted sources such as:\n\n```\nreq.bodyreq.queryreq.paramsrequest.json()\n```\n\nIt can also identify trusted sources such as database query results.\n\nThen it follows how those values propagate through the application.\n\nFor example:\n\n``` js\nconst price = req.body.price;const amount = price * quantity;\n```\n\nEven though amount doesn’t directly reference req.body, the analyzer knows that its value originated from an untrusted source.\n\nIf that value eventually reaches a sensitive sink such as:\n\n```\nstripe.paymentIntents.create(...)\n```\n\nthe system can flag the entire flow.\n\nThis is one of the key differences between deterministic analysis and simply asking an LLM whether code appears secure.\n\nThe system isn’t guessing.\n\nIt is following the data.\n\nSecuring AI Agent Tools\n\nThere is another security problem that becomes increasingly important as AI agents become capable of taking actions.\n\nModern AI applications expose tools or functions that an LLM can decide to execute.\n\nThose tools might include:\n\n```\nrefund_paymentdelete_usertransfer_moneysend_emailupdate_account\n```\n\nThe problem is that these aren’t just functions.\n\nThey are **capabilities**.\n\nConsider a refund tool:\n\n``` js\nconst refundTool = {  name: 'refund_payment',  description: 'Refunds a transaction using transactionId.',\nasync handler({ transactionId }) {    await db.refunds.create({ transactionId });  }};\n```\n\nThe tool performs a sensitive operation, but there is no authorization check.\n\nThere is no verification that the current user is allowed to refund that transaction.\n\nThis creates a potentially dangerous attack surface for an AI agent.\n\nAn attacker could potentially manipulate the agent through prompt injection or another attack and cause it to invoke a powerful tool against an unauthorized resource.\n\nThe AIAgentAnalyzer is designed to identify this type of issue.\n\nIt looks for potentially destructive operations such as refund, delete, and transfer, and then examines the implementation for authorization-related signals such as:\n\n```\nauth()sessionuserIdrole\n```\n\nIf a sensitive tool appears to be exposed without appropriate authorization logic, the scanner can flag it.\n\nAs AI systems move from generating text to performing real-world actions, this distinction becomes extremely important.\n\nThe AI should be allowed to reason about what action to take.\n\nBut the application should still enforce whether that action is actually allowed.\n\nSecurity Feedback Inside the AI Development Loop\n\nOne of the features I find particularly interesting about ai-security-skill is its integration with the **Model Context Protocol (MCP).**\n\nThe security control plane can be exposed as an MCP server and connected directly to AI development environments such as Cursor, Claude Code, or Windsurf.\n\nThis changes the workflow.\n\nthe goal becomes:\n\nThe AI agent can query the security requirements relevant to a feature before implementing it.\n\nAfter generating the code, the local verification engine can scan it.\n\nIf a vulnerability is detected, the finding can be returned to the agent, allowing it to correct the implementation before the developer even reviews the file.\n\nThis creates a much tighter feedback loop between **code generation and security verification.**\n\nAnd importantly, the security engine doesn’t have to trust the AI’s own explanation of whether the code is safe.\n\nArchitecture Decision Records for Security Exceptions\n\nOf course, security scanners aren’t perfect.\n\nSometimes a finding is technically correct but doesn’t represent a real vulnerability in the application’s specific context.\n\nFor example, a test might execute a SQL query against a hardcoded in-memory SQLite database.\n\nA generic scanner could flag that as SQL injection.\n\nInstead of adding complicated ignore comments throughout the codebase, ai-security-skill uses **Architecture Decision Records (ADRs)** stored inside:\n\n```\n.security/decisions/\n```\n\nA decision can document why a particular finding has been intentionally accepted:\n\n```\nADR-001: Exclude SQLi in local tests\nfinding_id: SQLI-73716c69rule_id: INJ-003expires: 2026-12-31approved: truereviewer: SecurityLeadreason: SQL query is executed against a hardcoded sqlite memory db.\n```\n\nThe engine can evaluate the decision, check whether it has expired, verify its approval status, and suppress the finding when the exception is valid.\n\nThe important part is that the reasoning becomes part of the repository.\n\nIt is version-controlled.\n\nIt can be reviewed.\n\nAnd it creates a much clearer security trail than simply saying:\n\n*“Ignore this warning.”*\n\nGetting Started\n\nThe goal was to make the setup as simple as possible.\n\nInitialize the security layer in an existing project:\n\n```\nnpx ai-security-skill init\n```\n\nThen scan the workspace:\n\n```\nnpx ai-security-skill scan\n```\n\nCheck the current security status:\n\n```\nnpx ai-security-skill status\n```\n\nAnd finally evaluate the project against the security policy:\n\n```\nnpx ai-security-skill gate\n```\n\nThe gate can return exit code 0 when the project passes the policy.\n\nIf critical or high-severity vulnerabilities remain open, it can return exit code 1 and block the build or commit.\n\nThe entire workflow can run locally.\n\nNo source code needs to leave the developer’s environment just to perform these checks.\n\nWhy I Built This\n\nAI-assisted development is not going away.\n\nIf anything, AI agents are going to become increasingly capable of writing, modifying, testing, and eventually deploying software.\n\nThat means application security needs to evolve with them.\n\nWe can’t simply bolt security onto the end of the development process and expect that to scale.\n\nSecurity needs to move closer to the point where code is created.\n\nBut there is also a fundamental trust problem.\n\nIf an AI agent writes the code and then the same AI agent decides whether that code is secure, we are effectively asking the student to grade their own exam.\n\nThat doesn’t mean LLMs shouldn’t be involved in security.\n\nQuite the opposite.\n\nLLMs can be extremely useful for explaining findings, suggesting fixes, understanding application context, and helping developers reason about security decisions.\n\nBut underneath that intelligence, there should be an independent verification layer that can say:\n\n**“Show me the evidence.”**\n\nThat is the philosophy behind ai-security-skill.\n\nBy combining context-aware controls, security standards, deterministic AST analysis, taint-flow detection, AI agent security checks, MCP integration, and local-first execution, the goal is to give developers and AI agents the guardrails they need to move fast without treating security as an afterthought.\n\nThe project is open source and available on GitHub:\n\n[https://github.com/Abhishekksoni/ai-security-skill](https://github.com/Abhishekksoni/ai-security-skill)\n\nYou can also initialize it directly in an existing project:\n\n```\nnpx ai-security-skill init\n```\n\nI’d love to hear what you think.\n\nHave you experienced an AI coding assistant generating a security vulnerability?\n\nDo you think AI-generated code should always pass through an independent security verification layer?\n\nAnd if you could add one security check to every AI coding agent, what would it be?\n\nLet’s discuss.\n\n[Your AI Writes the Code. Who’s Checking It for Security? Meet ai-Security-Skill](https://pub.towardsai.net/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill-e9b9ea641b69) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill", "canonical_source": "https://pub.towardsai.net/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill-e9b9ea641b69?source=rss----98111c9905da---4", "published_at": "2026-08-30 16:01:01+00:00", "updated_at": "2026-08-30 16:22:13.718543+00:00", "lang": "en", "topics": ["ai-safety", "ai-tools", "developer-tools"], "entities": ["ai-security-skill", "Cursor", "Windsurf", "Antigravity", "Claude Code", "OWASP", "NIST"], "alternates": {"html": "https://wpnews.pro/news/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill", "markdown": "https://wpnews.pro/news/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill.md", "text": "https://wpnews.pro/news/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill.txt", "jsonld": "https://wpnews.pro/news/your-ai-writes-the-code-whos-checking-it-for-security-meet-ai-security-skill.jsonld"}}