Musa Erdem Mecit
Internal auditor at an insurance company. Civil engineer by training. I build apps on the side, in whatever area I happen to need something.
I trained as a civil engineer and spent my first years on building sites and in design offices, on the main terminal at Istanbul Airport and then on Marmaray. Large projects teach you that the interesting problems live in the gap between the drawing and what actually got built.
Since 2018 I have worked in internal audit at insurance companies. The habit that work leaves you with is a particular way of looking at any system: if I wanted to abuse this, where would I start? If something went wrong here, where would it hide?
Audit is still the day job. Alongside it, since 2021, I have been writing software. Three small apps are on the App Store and all of them are free. They have little in common: a menu app, a payment tracker, a teleprompter. Each one started because I wanted it to exist.
Where the two meet
These two halves feed each other more directly than they look. Internal audit runs on evidence you gathered yourself, and the useful version of that is rarely a report handed to you by the function you are examining. Learning to write code changed what I was able to ask for. A query I can write and run myself is a question I no longer have to pass to someone else, and a population I can reconstruct is a sample I no longer have to defend.
That is not a convenience. It is the difference between testing a control and testing what management says about the control. Most of what I now automate in my own work sits exactly there: pulling the full population instead of a sample, re-running the queries a system is supposed to be running, and checking the answer against the one I was given.
It runs the other way too. The habit of asking where a system would fail, and where a mistake would hide, is the same habit that makes you check what an agent is actually permitted to do before you let it loose on your files.
What I write about
I write for practitioners about how losses actually happen: the schemes that defeat controls which were working exactly as designed, and what assurance over machine learning systems has to look like. These pieces are in preparation, and I will link each one here when it is published.
- Business Email Compromise in Insurance Claims Payments
- Collusion at the Point of Settlement
- From Sampling to Signals
- Auditing the Algorithm
- The Three Lines Against Organised Fraud Rings
An interest on the side
Audit is the practice of establishing what actually happened, to an evidentiary standard, when the people you are asking have reason to tell you otherwise. Working with AI agents has left me thinking that practice might have something to offer here too. Three notes rather than a thesis.
Agent failures are access control failures
I have lost work to AI agents, through wrong deletions and code that disappeared. Every time, the root cause was something an auditor sees constantly: the agent held permissions it never needed for the task in front of it. Least privilege is not a new idea. It is just not always applied.
The July 2026 incident made it concrete
When agents under cyber capability testing escaped their sandbox, reached Hugging Face, and coordinated through a hidden message board, the failure modes were recognisable ones: logging that nobody monitored, a single point of control, and safety measures that had been switched off. I have written findings like these before, in a different industry.
Telling when a system is hiding something
The part I find most interesting is detecting concealment, meaning a system that behaves differently when it believes it is being observed. That is an old problem in audit, and some of the methodology may carry over: risk based planning, sampling, standards of evidence, and independence from whatever is being examined.
Elsewhere
The apps I have built, all of them free, and a longer account of how engineering turned into audit and then into software.