The demo worked in the test browser. The fixed fee is nearly signed. Then someone on your team asks the question that changes the deal:
Where do the passwords and API keys live, and is that standard written into the contract before build?
No incident has to happen first. The build simply outran the security rules. Those rules were never locked into scope, price, and acceptance the way the timeline was.
Write the controls into the engagement before code starts, and your team can verify security at acceptance. Leave them as verbal assurances, and acceptance still rests on the demo.
The assistants are settled. The security contract is not
That gap shows up for a COO at a mid-market financial services firm after green-lighting a vibe coding build for a customer onboarding portal. The team ships faster than anyone expected. During a routine review, someone asks where the login credentials for the identity check service live.
A CMO hits the same gap on a lead capture portal built with vibe coding. Conversion looks strong in the demo. Then someone asks where the CRM connection secrets are stored.
Prospect data and marketing-system credentials need the same written standard before real traffic arrives, not after marketing celebrates the conversion numbers.
Executives who recognize that pattern treat security controls as part of how the engagement is bought, alongside price and timeline. The question is not which assistant the team uses, whether that is Cursor, GitHub Copilot, Claude Code, or another IDE. It is whether the contract names what “secure enough to accept” means before anyone writes a line of code.
Why the contract gap matters more than the tool choice
Once “secure enough to accept” has to live in the contract, the tool debate loses its force. AI coding assistants have moved from side experiments to everyday practice.
Work that once needed a senior engineer and several days can now start with a junior developer typing natural language prompts in an IDE. That speed is real, and it is worth keeping.
The tools do not know your organization’s rules for passwords and keys. They do not reliably catch hallucinated packages (dependency names the model invents that do not exist as trusted libraries) or outdated libraries.
AI-generated code often works on the first pass, but it still needs the same review, scanning, and secure development standards{1} you would apply to any system that handles real login credentials, customer data, or regulated workflows.
What turns that speed into something you can accept with confidence is a written AppSec (application security) standard in the contract, including SCA (software composition analysis) on every outside package.
The organizations getting the most from vibe coding can describe, in plain language, which security controls every AI-assisted build must meet before acceptance, and they put that description in the engagement before the deal closes. They also treat vibe coding security risks as contract items, not as a late checklist after the demo lands.
Growth and marketing leaders face that gap on every lead capture form, campaign landing page, and funnel routing tool built with AI assistance. Before real prospects submit data, five practical questions need written answers. Each one becomes a SHARP letter in the engagement:
- Scope: Which security outcomes can you check pass or fail before you accept the work?
- Handover: What security proof ships with the handoff (how secrets are stored, scan results, a full list of software components)?
- Automated scanning: What gets scanned at every delivery checkpoint, and who sees the results?
- Running security: What review and test rules apply to AI-generated changes while the build is underway?
- Post-delivery: Who fixes issues after launch, and how fast must they respond?
SHARP: Five Controls in the Contract Before Code Starts
Those five questions map to SHARP. Each letter is a control written into partner requirements, contracts, and internal policy in plain language, starting with the security outcomes you are buying. For vibe coding engagements, that language is what keeps speed from widening the attack surface before acceptance.
| Letter | Control | What gets commissioned | Pass/fail evidence |
|---|---|---|---|
| S | Security-testable scope | Security outcomes in pass/fail acceptance language before build; each delivery checkpoint names the security item it addresses; payment milestones tied to outcomes you can verify | Example: “the sign-in module uses input validation{2} to reject invalid requests, and shows no high-severity findings in automated security scanning” |
| H | Handover with security evidence | Secrets management{3} that keeps credentials in environment variables, not in version control; no hardcoded secrets or exposed secrets in the handoff; scan results{4} clean before acceptance; a complete list of every software component in the build; documented review and ship rules for AI-assisted changes | No unresolved high-severity findings you did not explicitly accept; a component list your team can operate against; acceptance rests on proof, not a demo |
| A | Automated security scanning | Automated scanning{4} built into CI/CD pipelines, not a tool catalog leaders must configure themselves | SAST (static analysis that scans code before it runs); SCA (software composition analysis) against known CVEs (published vulnerability IDs); DAST (tests the running app for security flaws); no passwords or API keys buried in the code at any checkpoint |
| R | Running security throughout development | Controls inside the process so findings appear while the team can still act, not only at handoff | Limits on what an MCP server (Model Context Protocol connector that gives an assistant tool access) can reach; secret scanning at every checkpoint; code review on pull requests when meaningful changes ship; secure coding practices enforced in the IDE |
| P | Post-delivery accountability | Complete component list{5} at handoff; who patches known issues in those components after launch; measurable time to recover | Named owner for fixes; defined response-time standard; monitoring for new issues{6} in the component list |
A demo proves a feature works in a walkthrough. Security-evidenced acceptance proves the build meets the controls you wrote into the contract. unosquare writes all five into scope and acceptance before the build begins.
The next step is locking that language into the engagement you are about to sign.
Write the security standard into the contract before the build starts
Once SHARP is on the table, the next engagement is where those five controls become contract language. See how unosquare builds security controls into every AI-assisted engagement before code starts. A real workflow makes that language easier to judge than a blank statement of work.
Example: A fintech onboarding portal
Put that contract bar on a fintech or healthcare onboarding portal: identity capture, application routing, and credentials that must never sit inside the code files. Vibe coding can draft that portal fast; SHARP is what makes the result acceptable.
On that portal, SHARP stops being abstract.
Scope might say the identity check rejects invalid requests and shows no high-severity scan findings before acceptance. Handover requires secrets stored outside the code, clean scan results, and a complete component list.
Automated scanning runs at every delivery checkpoint. Running security surfaces findings while the team can still fix them. Post-delivery names who patches after launch and how fast they must respond.
unosquare‘s week-one Discovery maps that portal against those controls and produces a working prototype so security acceptance criteria are visible before scope and price are agreed.
Acceptance ties to SHARP proof your team can verify, not to the walkthrough alone. The delivery phases below show how that proof accumulates from week one to signed acceptance.
From contract language to signed acceptance
Those same controls stay with the project from draft language to signed acceptance. Each phase produces a different piece of contract proof, not a status update. unosquare writes them into scope, price, and acceptance at each step, so security evidence accumulates while vibe coding keeps delivery moving.
Discovery: Test security acceptance against a real workflow
Week 1
Week one runs your core workflow with the same assistants your team already uses, in your business context. The practical test matches what scope should answer before you sign: if you accepted this build today, could you verify security against written pass/fail criteria, or would acceptance still rest on the demo?
The prototype surfaces what a demo alone would hide: whether AI-generated code would leave secrets in the project files, and which outside packages would ship unchecked. Discovery returns a working prototype plus draft contract language for each SHARP control before price is discussed. No commitment is required to proceed.
Solution Architecture: Freeze security scope, handover evidence, and price together
Week 2
In week two, design, fixed fee, and security definition of done settle in one agreement. Each security outcome becomes a pass/fail line item tied to payment milestones, not a general promise to “be secure.”
The handoff package is specified in plain language: where passwords and keys live, which scan results must be clean before acceptance, and what the complete component list must include.
Builds start as low as $100K only after scope, price, and security definition of done are locked together as testable deliverables. Security work sits inside the quoted fee, not in a change order at the finish line.
Build: Keep scanning and review ahead of AI-assisted output
Weeks 3 through 11
Build is where automated scanning and ongoing security review keep pace with AI-assisted output. Code is scanned before it runs. Outside packages are checked against known issues. Secret checks run at every delivery checkpoint so exposed secrets never reach acceptance.
Meaningful changes trigger a security review while the team can still fix findings, not only when someone schedules a final walkthrough.
Security evidence builds milestone by milestone: scan results, review records, and fix logs your team can check without reading every line of AI-generated code. Full code ownership transfers at handoff with that record intact.
Deploy and Handoff: Sign acceptance on proof, not presentation
Week 12
Week twelve closes on the security evidence you commissioned at the start. Handoff delivers clean scan results, a complete component list, documented handling of passwords and keys, and a security test of the live application before you sign acceptance. Who patches known issues after launch, and on what response-time standard, is already named in the contract.
Sixteen years of engineering discipline. More than 2,500 completed projects. A client NPS in the top 1% of B2B services.
If delivery takes longer than the committed timeline, that additional cost is unosquare‘s, not yours. Before you fund that path, check whether the security contract for this build already clears the same bar week twelve will ask for.
Decision aid: Is the security contract ready for this build?
Week twelve signs acceptance on proof. The table below asks whether that proof is already named in the engagement, control by control. Use it whenever vibe coding speed is already in motion and the security bar is still verbal.
| Control | What to verify | Pass condition |
|---|---|---|
| Security-testable scope | Every security outcome is verified pass/fail | Documented security acceptance criteria required in the contract before build |
| Key and password management | No secrets are buried in the code | All sensitive credentials in environment variables or an approved secrets management store, never in version control |
| Automated scanning | Security scanning runs at every delivery checkpoint | Results available before work is accepted |
| Component list | A complete list of software components ships at handoff | Known security issues in those components are monitored |
| Post-delivery accountability | Who patches after launch, and by when, is named | Defined in contract with measurable time to recover |
| Human oversight | Every AI-generated change is reviewed against the security rules before it ships | Review results you can check |
If any row is still open, write that control into the engagement before the next deployment. Week one is where you see those controls on a live workflow before you commit.
Start with a prototype that shows the controls in the contract
When a row in that table is still open, the week-one prototype is where the gap closes. unosquare delivers a working prototype in week one, scoped to your specific workflows, with automated scanning and secret management already in place.
Review the security controls in action, see draft acceptance language on the table, and decide whether to proceed. No commitment required at the end of week one.
The questions leaders ask next usually land on the same five controls.
Frequently asked questions
When the week-one prototype puts scanning, secret handling, and acceptance language on the table, the questions below are usually what leadership asks next.
What does commissioning secure AI-assisted delivery mean for a business leader?
Your teams already use assistants. Commissioning secure AI-assisted development means the contract names the SHARP controls before speed becomes the only metric.
Scope puts security outcomes in pass/fail language. Handover requires proof: secrets stored outside the code, clean scan results, and a full component list. Automated scanning and Running security keep checks ahead of AI-assisted output. Post-delivery names who fixes issues after launch and how fast they must respond.
The demo may look right. The accepted build still needs that proof.
What are the most common security flaws from AI-generated code?
Every common exposure has a clear control. The areas that most often need attention are:
- Hardcoded secrets{3} written into the code instead of an approved store outside the files.
- Outdated libraries and packages with known security issues{6}.
- Logic flaws: the feature runs, but the business rules or permissions are wrong in ways the model does not flag.
- SQL injection{7} (tricking a database query through untrusted input), XSS (cross-site scripting that injects unwanted script into a page), and remote code execution (letting an attacker run code on your system): all reduced when input validation is a pass/fail acceptance item.
- Prompt injection{8}: carefully worded input that tries to override an assistant’s instructions or tool access.
Those patterns are the security gaps vibe coding introduces when speed outruns written controls. Automated scanning and human oversight, written into the contract from day one, handle all of these.
Do I need to understand the technical details to govern this well?
No. Those five controls translate directly into buying requirements, contract language, and internal policy.
You do not need to read code to require that every change passes automated security scanning before it is accepted. You do not need to be technical to require that no passwords and keys sit in the code files. You do not need to configure scanning tools yourself to require a complete list of software components at handoff, plus named response times for fixes.
How does a fixed-fee model handle it if security work takes longer than planned?
If a project runs over on a fixed-fee engagement with unosquare, that additional cost is unosquare‘s, not yours. The fee is set before the build starts and does not change because the estimate was wrong.
That clarity comes from upfront security acceptance language in the contract. When every SHARP control is written as a testable outcome before code starts, “running over” has a clear meaning: the security proof that was agreed has not yet been delivered.
What do we actually get in week one during Discovery?
A working prototype with the security controls visible, not a presentation.
Discovery produces a functional demo of the core workflow you want to build, scoped to your specific business context, with scanning and key-storage expectations already on the table so your leadership team can see how secure AI-assisted delivery will work. It also surfaces scope decisions written specs often miss, so those decisions resolve before price and security acceptance are agreed in week two.
No commitment is required at the end of week one: you evaluate the prototype and the controls, then decide whether to proceed.
If your AI-assisted build needs security controls written into the contract before speed outruns what your team can verify, unosquare‘s outcome-based delivery model writes SHARP into scope and acceptance before code starts. Request a free prototype scoped to your workflow so each SHARP control is visible before you commit.
References
- National Institute of Standards and Technology. (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST CSRC.
https://csrc.nist.gov/pubs/sp/800/218/final - OWASP Foundation. (n.d.). OWASP Application Security Verification Standard (ASVS). OWASP Foundation.
https://owasp.org/www-project-application-security-verification-standard/ - GitHub Docs. (n.d.). Secret scanning. GitHub Docs.
https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning - GitHub Docs. (n.d.). Code scanning. GitHub Docs.
https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning - Cybersecurity and Infrastructure Security Agency. (n.d.). Software Bill of Materials (SBOM). CISA.
https://www.cisa.gov/topics/information-communications-technology-supply-chain-security/sbom - GitHub Docs. (n.d.). Dependency graph. GitHub Docs.
https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph - OWASP Foundation. (n.d.). OWASP Top Ten Web Application Security Risks. OWASP Foundation.
https://owasp.org/www-project-top-ten/ - OWASP Foundation. (n.d.). OWASP Top 10 for Large Language Model Applications. OWASP Foundation.
https://owasp.org/www-project-top-10-for-large-language-model-applications/
Our Editorial Standards
unosquare is committed to providing accurate, well-researched B2B software delivery information. Our editorial team reviews all content for accuracy and relies on reputable sources including industry analysts, technology standards bodies, academic institutions, peer-reviewed research, and established enterprise software providers. All references are verified for accessibility and relevance at the time of publication.
We strive for accuracy in everything we publish, but we recognize that mistakes can occur and information can become outdated as delivery models, pricing benchmarks, and technology standards evolve. If you notice an error or outdated information, please contact us so we can review and update our content.
Important Disclaimer
The information provided on this website is for general informational and educational purposes only. It is not intended as, and should not be interpreted as, professional legal, financial, or technical implementation advice. Always consult with qualified technology advisors, legal counsel, or appropriate professionals before making decisions about software investments, vendor selection, or delivery models. unosquare does not assume liability for actions taken based on the information presented on this site.
