Security audits for software and AI systems
We review how your systems handle data, access, secrets, and AI-specific risk, then hand you a ranked, fixable list, not a generic scan report.
We are an AI consulting and custom software firm in Limassol, working with teams across Cyprus and the wider EMEA region. A security audit here is a hands-on review of how a real system is built: its architecture, its data handling, who can do what, where secrets live, what it depends on, and the risks specific to AI, like prompt injection, data leakage, and answers that are not grounded in your own sources.
This is a review, not a certificate. We do not sell pentests-by-the-hour or compliance badges. We read the system the way the people who built it should have, and we hold it to the same production standard we hold our own product to.
The hole sits quietly until someone finds it
Most security problems in software are not exotic. They are an API key committed to a repo, a database role that can read more than it should, an integration that trusts input it never checks, a dependency three versions behind a known fix. The system works, demos cleanly, and ships. The hole sits quietly until someone finds it.
AI systems add a second layer most reviews miss entirely. A copilot wired to your documents can be talked into ignoring its instructions. A retrieval system can surface a record the asker was never meant to see. A model answer can be confidently wrong with no trace back to a source. These are not edge cases. They are the predictable failure modes of putting a model in front of real data, and they need to be reviewed on purpose.
Five things we hold to a production standard
The AI paths get the same scrutiny as the code around them, because that is where most reviews stop short.
- ARCH
Architecture and data flow
We map how data actually moves through the system, where it is stored, where it crosses a trust boundary, and where it leaves the EU, so the risks are visible instead of assumed.
- ACCESS
Access control and secrets
We check who can do what, whether roles are scoped to the work, and whether keys and credentials live in env and a secret store rather than the codebase or a config file.
- DEPS
Dependencies and supply chain
We review the libraries and services you depend on for known vulnerabilities, unmaintained packages, and the ones pulling in more than they need.
- AI RISK
AI-specific risk
Prompt injection, data leakage through a model, retrieval that returns records the asker should not see, and answers that are not grounded in a citable source, reviewed as their own class of risk.
- EU AI ACT
EU AI Act obligations
We flag where a system carries obligations under the EU AI Act, like logging, human oversight, and transparency, so they are designed in rather than discovered in an audit later.
A ranked list, not a wall of equal warnings
Every finding carries a severity, a plain description, and the fix. You work top down, from the issue most likely to hurt to the one that can wait. These are the shapes of issue we find, not a scanner dump.
- High
API key committed to the repository history
Rotate and move to secret store - High
Retrieval can return records the asker should not see
Scope retrieval to the asker - Medium
Database role reads more tables than the work needs
Tighten to least privilege - Medium
Model answers carry no link back to a source
Ground answers in citations - Low
Dependency three versions behind a known fix
Patch on the next cycle
Audit, rank, fix, hand over
Audit
We read the system: code, architecture, data handling, access, dependencies, and the AI paths. We work from how it really runs, not a questionnaire, and we surface what we find as we find it.
Rank
We turn the findings into a ranked list, each one with its real impact, how likely it is to be hit, and a concrete fix. You get a clear order to work in, not a wall of equal-weight warnings.
Fix
Where you want us to, we make the changes ourselves: close the access gap, move the secret, ground the retrieval, patch the dependency. Each fix is reviewed and tested, the same as any build we ship.
Hand over
You get the report, the fixes, and the reasoning, documented so your team can carry the work forward and catch the same issues next time without us.
What lands on your desk
A ranked findings report
Every issue we found, ordered by impact and likelihood, each with a plain explanation and a concrete fix, not a raw scanner dump.
Fixes, where you want them
We close the issues we are asked to close, reviewed and tested, so the report does not just sit in a drawer as a list of things someone should get to.
An AI risk review
A clear read on the AI-specific exposure: prompt injection, data leakage, retrieval grounding, and how data is handled, with what to change for each.
An EU AI Act and data-residency read
Where the system carries obligations under the EU AI Act, and where your data sits, so the compliance questions have honest answers before someone official asks them.
A handover your team can use
The findings, the fixes, and the reasoning documented, so the next review can start from here instead of from scratch.
We hold your system to the same standard we hold our own product, Pileform, which runs in production across 55 VAT jurisdictions and 11 languages, reading and reconciling finance documents under real data-handling obligations. We have built the auditable, EU-hosted, citation-grounded version of an AI system ourselves, which is the same discipline we bring to your document AI and the systems around it.
See how this connects to our document AI workBefore a security review, answered
Is this a penetration test?
No. A pentest tries to break in from the outside and tells you what worked. We review the system from the inside: its architecture, data handling, access, secrets, dependencies, and AI paths, so you see the structural risks, not just the ones an attacker happened to reach on the day. The two are complementary, and we will say if a pentest is the better next step for your case.
Do you issue a certification or compliance badge?
No, and we will not claim to. We are engineers reviewing how a system is built, not a certifying body. What we give you is an honest, ranked picture of the real risks and the fixes for them. If you need a formal certification, an audit like this is good preparation for one, but it is not a substitute.
What does the AI-specific part actually cover?
Prompt injection, data leakage through a model, retrieval that returns records the asker should not see, answers that are not grounded in a citable source, and how your data is stored and used. These are the predictable failure modes of putting a model in front of real data, and we review each as its own class of risk.
Do you only report problems, or do you fix them?
Both, and the fixing is the point. We rank what we find, then close the issues you want closed, reviewed and tested. A report nobody acts on is worth little, so we are built to act on it with you rather than hand you a list and leave.
Can you review a system you did not build?
Yes. Most of the systems we audit are not ours. We read the code and the architecture as they are, which is why the audit step comes first: we work from how the system really runs, not from documentation that may be out of date.
Where does our data go during the review, and does it stay in the EU?
Your data stays yours and stays where it is. We review against your environment under your access controls, and data residency is one of the things we check rather than something we put at risk. We are a Europe-rooted firm and build for EU data residency by default, including in the document AI work this often connects to.
Tell us what you want reviewed
A custom build going live, an AI system about to touch real data, or a platform you inherited and do not fully trust. We will read it honestly, rank what we find, and fix what you want fixed.
Held to the same production standard as the product we run ourselves.