AI SecurityAI SecurityAI × Cybersecurity
Can you say your development is secure?
With AI-driven development, teams can now build their own internal tools and systems. One problem remains. Neither the people who built them nor the IT department can confirm that what they built is actually secure.
We teach a secure way to do AI-driven development first, verify as a third party that what gets built meets that standard, and keep the standard in place in operation. You build. We don't.
- For:
- Large enterprises, mainly in manufacturing
- Pricing:
- Quoted per engagement
01
The problem
Anyone can build now. No one can verify.
When AI-driven development enters a company, three things happen at once.
The people building software no longer know security.
A natural-language instruction produces something that works, so business units now build their own tools. Builders have multiplied; people who can design for security have not.
Working and secure are two different things.
AI-generated code repeatedly shows classic flaws such as missing authentication and hard-coded credentials. Functional testing does not catch them.
There is no in-house standard for judging security.
No one has defined what must be met before production use, so no one can flag a problem or declare that there is none.
You don't need to stop building. What you need is a standard set before building, verification against that standard, and a way to keep it in place.
02
By the numbers
The current situation in numbers
45%
Across 80 coding tasks designed by Veracode and run on more than 100 large language models, 45% of the generated code contained security vulnerabilities. Results were nearly the same regardless of model size.
Source: Veracode, "2025 GenAI Code Security Report," July 2025
75.8% / 56.4%
Of developers surveyed, 75.8% believe AI-generated code is more secure than human-written code. At the same time, 56.4% say they frequently encounter security issues in AI suggestions.
Source: Snyk, "2023 AI Code Security Report" (late 2023, about 500 developers)
96%
96% of developers do not fully trust AI-generated code. Only 48% always verify it before committing.
Source: Sonar, "State of Code Developer Survey," January 2026 (more than 1,100 developers)
20%
20% of responding organizations have experienced a serious security incident linked to AI-generated code.
Source: Aikido Security, "State of AI in Security & Development 2026" (450 CISOs, developers, and AppSec engineers in the US and Europe)
03
Service overview
Three stages to secure what you build
This service has three stages. You build. We set the standard for how to build, verify against it, and keep it in place.
Teach
Secure AI-driven development
- What we do
- We teach builders and approvers how to do AI-driven development securely, and define the conditions for production use.
- What you do
- Attend the training and approve the standard.
- Deliverables
- Approval criteria, training records, and comprehension results
Verify
Third-party verification
- What we do
- We verify what you built against the agreed standard. We report issues and fixes, and decide whether it is fit for production.
- What you do
- Present the targets and address the findings.
- Deliverables
- Inventory, verification report, and go/no-go decision
Operate securely
Keeping the standard
- What we do
- We define when a change triggers re-verification and keep the inventory current. Issues found in operation go back into the training.
- What you do
- Request re-verification and make the call to stop.
- Deliverables
- Re-verification procedure and updated criteria
We don't build your tools for you. If we did, we would be verifying our own work, and the result would no longer stand as a third-party judgment.
Each stage is available on its own. Starting at stage 02 without stage 01, though, produces verification results with no in-house standard to judge them by. Starting from stage 01 is the standard path.
04
What we check
What we check
We check AI-built tools on these eight points. Functional testing catches none of them.
Authentication
Is access limited to the right people?
What we often findNo authentication, because it is "on the internal network"
Authorization
Are the permissions of the source data carried over?
What we often findEveryone can pull data from every department
Credentials
Are API keys and passwords kept out of code and config?
What we often findLeft in the generated code as is
Input handling
Are externally supplied values validated?
What we often findNo validation, open to injection
Outbound data
What is sent where?
What we often findBusiness data flowing to services no one has tracked
Data storage
Where is data kept, and for how long?
What we often findNeither location nor retention period is defined
Logging
Can you trace who did what afterward?
What we often findNo logs
Dependencies
Do the libraries and external services have known vulnerabilities?
What we often findLeft in use without updates
What we do not verify
The following three are outside the scope of verification.
- Tests that involve attacking production environments
- The correctness of business logic
- The behavior of the AI model itself
05
Onboarding
How onboarding works
Inventory and current stateWe identify what has been built with AI across the company, through interviews with each department and a review of the services in use. You provide the answers.
Set the approval criteriaWe define in writing what must be met before production use. We prepare the issues and options. You decide.
Train the builders on the criteriaWe teach builders and approvers how to do AI-driven development securely and what the criteria mean.
VerifyWe check what has been built against the criteria and report issues and fixes. We decide whether it is fit for production.
Move into operationWe define when re-verification is required and who has the authority to stop. From then on, you can make the call yourselves.
The standard period is two to four weeks. Pricing is quoted individually.
06
Features
Three features
We don't build.
We don't build your tools for you. Because we never take the builder's side, our judgment that something meets the standard stands as a third-party judgment.
We set the standard before you build.
We decide what must be met first and teach it to the builders. That way, nothing already running has to be stopped later.
We can check the factory floor (OT) too.
OT/ICS security is our core business. We can verify tools connected to production management or equipment, control systems included.
07
Safety by design
Six conditions for calling something secure
We never say "it is secure." What we can say is whether the following six conditions are met. These six are our approval criteria.
The criteria are set before building.
We define the conditions for production use in writing before anything is built. Judging after the fact means you can no longer stop something that is already running.
The builders know the criteria.
A standard only works once the people expected to follow it understand it. Both builders and approvers know what must be met.
What has been built is known.
How many tools exist, who built them, and what data they touch. Without an inventory, there is nothing to verify.
Someone other than the builder has looked.
Checking your own work does not change the odds of missing something. The fact that a third party looked is the assurance.
The checks and their results are on record.
We record what was checked, what was wrong, and how it was fixed. Without a record, no one can say afterward that it was secure.
A change triggers a recheck, and what cannot be fixed can be stopped.
A single verification covers one point in time. We set the conditions for re-verification and name who has the authority to stop, in advance.
08
How we differ
How this differs from other approaches
There are other ways to check what AI has built. Here is how each approach compares with ours.
| Other approach | How it works | This service |
|---|---|---|
| Rely on the AI tool's built-in checks | The tool that generates the code also checks it during generation. | We check from the outside, against a set standard.We check from outside what was built, against the agreed standard. When the same system generates and checks, it shares the same blind spots. |
| Outsource the build and let the vendor verify it | Development is outsourced, and the vendor provides its own quality assurance. | We don't build.We don't build. Because we never take the builder's side, our judgment stands as a third-party judgment. |
| Run a conventional vulnerability assessment | Public-facing systems are assessed, typically once a year. | We set the standard first, teach it, then verify.We set the standard first and teach the builders before verifying. We also define when a change triggers a recheck. |
| Hand out guidelines | A written policy on AI use is distributed. | We confirm the guidelines are actually met.Beyond the document, we check whether it is actually met and decide go or no-go. |
| Ban in-house building | In-house development with AI is not allowed. | We don't stop you from building.We don't stop you from building. We define the conditions for building and pass what meets them. |
- This service
- We check from the outside, against a set standard.We check from outside what was built, against the agreed standard. When the same system generates and checks, it shares the same blind spots.
- Other approach
- Rely on the AI tool's built-in checks
- How it works
- The tool that generates the code also checks it during generation.
- This service
- We don't build.We don't build. Because we never take the builder's side, our judgment stands as a third-party judgment.
- Other approach
- Outsource the build and let the vendor verify it
- How it works
- Development is outsourced, and the vendor provides its own quality assurance.
- This service
- We set the standard first, teach it, then verify.We set the standard first and teach the builders before verifying. We also define when a change triggers a recheck.
- Other approach
- Run a conventional vulnerability assessment
- How it works
- Public-facing systems are assessed, typically once a year.
- This service
- We confirm the guidelines are actually met.Beyond the document, we check whether it is actually met and decide go or no-go.
- Other approach
- Hand out guidelines
- How it works
- A written policy on AI use is distributed.
- This service
- We don't stop you from building.We don't stop you from building. We define the conditions for building and pass what meets them.
- Other approach
- Ban in-house building
- How it works
- In-house development with AI is not allowed.
09
Track record and company
Track record and company
- Selected for the accelerator program of GTIE, a startup support platform for university spinouts.
- Delivered cybersecurity training to 18 companies.
- Before the company was founded, our founding members supported security projects for government agencies and major telecom carriers. Winner of the Minister of Education, Culture, Sports, Science and Technology Award at the 21st Information Crisis Management Contest (May 2026).
Contact
Start with a 15-minute consultation
Tell us about your situation, and we'll outline how we would proceed. Pricing is quoted per engagement.
Book a 15-minute consultation